With this change it's possible to bootstrap a KDC using a client
certificate with a PKINIT SAN for iprop/fqdn. Given such a certificate
one could run ipropd-slave via kinit to pull down the initial copy of
the HDB, then start the KDC services using the HDBGET: keytab.
That should make bootstrapping new secondary KDCs very easy.
One could bootstrap the KDC with such a certificate using, e.g.,
Safeboot (https://github.com/osresearch/safeboot), enrolling the host as
a KDC.
We meant to clear only the UF_SMARTCARD_REQUIRED bit, but we were
instead clearing all bits excepting it.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
The online LIST interrupt message is a NOP, but it's expected to not
have a reply (the server doesn't send one if it receives it before the
LIST finishes).
However, if the interrupt message arrives after the LIST finished, then
it does get a reply, and this causes the client to get out of step with
the server.
Fixes include:
1) flavor the interrupt NOP to make sure it never gets a reply,
2) introduce a new kadm_list_interrtupt message that is like a NOP that
produces no reply
3) always consume -after the LIST ends- a reply to any list interrupt
NOP on the client side.
This implements (1).
kadm5_get_principals() is not online. If you have... many principals,
it will be slow. At least it's no longer quadratic, but it, it's still
slow. Time to add a version that uses a callback:
kadm5_ret_t
kadm5_iter_principals(void *server_handle,
const char *expression,
int (*cb)(void *, const char *),
void *cbdata)
The callback gets called with the given callback data and one principal
name (unparsed).
Note that the callback MUST NOT re-enter the kadm5 library with the
*same* kadm handle. For example, the kadmin protocol doesn't really
multiplex requests well, though it could pipeline them, but it can't
pipeline when LIST is running, not with the protocol implemented here,
so a separate connection is needed, and that requires a separate kadm
handle. We add kadm5_dup_context() to deal with this.
kadm5_ad_destroy() frees the contents of the kadm5_ad_context
but not the kadm5_ad_context itself.
Change-Id: I70dc1fc0236166ed9725f681dfeb935f449e38cb
If the cache principal name cannot be determined free the client
principal created from the input client name.
Change-Id: I75f96ef9f490bd9eb761a900e7a26250f1ac2b9c
warning: ‘ver’ may be used uninitialized in this function [-Wmaybe-uninitialized]
'ver' can be uninitialized if get_right() fails.
Change-Id: If6019cc3c491b8be321ff3e08f3d27292f0f1f95
When an unsigned char is shifted << 24 bits its type will be
promoted to signed 32-bits. If the value is then assigned to
an unsigned 64-bit value sign extension will occur.
Prevent the unwanted sign extension by explicitly casting the
value to unsigned long before shifting.
Change-Id: Iabeac0f17dc3229a2dc89abe71960a8ffbf523f8
Remove hdb_entry_ex and revert to the original design of hdb_entry (except with
an additional context member in hdb_entry which is managed by the free_entry
method in HDB).
Decorate HDB_entry with context and move free_entry callback into HDB structure
itself. Requires updating hdb_free_entry() signature to include HDB parameter.
A follow-up commit will consolidate hdb_entry_ex (which has a single hdb_entry
member) into hdb_entry.
Although not required to address bad code generation in
some versions of gcc 9 and 10, a coding style that requires
explicit comparison of the result to zero before use is
both clearer and would have avoided the generation of bad
code.
This change converts all use of cmp function usage from
```
if (strcmp(a, b) || !strcmp(c, d)) ...
```
to
```
if (strcmp(a, b) != 0 || strcmp(c, d)) == 0
```
for all C library cmp functions and related:
- strcmp(), strncmp()
- strcasecmp(), strncasecmp()
- stricmp(), strnicmp()
- memcmp()
Change-Id: Ic60c15e1e3a07e4faaf10648eefe3adae2543188
Sort of. It already knew.
We have a mess where new things get sent to the server as
KRB5_TL_EXTENSION, but old things get sent to the client as whatever
appropriate KRB5_TL we have, and... we call perform_tl_data() on all TL,
but we don't remove unmodified TL on the client side, and...
Anyways. This commit is a band-aid, but it works.
This is useful for services that need not be clients. For example, an
untrusted service that need only accept authentication from clients,
but not initiate authentication to other services.
If a DB does not already exist, ipropd-slave will use the compiled
default, which is not necessarily what is desired or configured in
`[kdc]`.
This change makes `hdb_default_db()` return the first dbanme in the
`[kdc]` configuration, falling back on `HDB_DEFAULT_DB`.
Also, this adds a `--database` option to `ipropd-slave`.
tests/kdc/check-iprop.in tends to wait for a log message then it reads a
status file. Well, we shouldn't write the log message before writing
the status file then!
Running ipropd-slave on a system whose hostname's realm is not the
requested realm breaks. Since the iprop client principal should really
be in the same realm as the master, we now force it after calling
krb5_sname_to_principal().
The new [hdb] new_service_key_delay parameter should not apply to
principal entries when used as clients. Otherwise new passwords would
not take effect immediately, and that would be very confusing.
This is a large commit that adds several features:
- Revamps and moves virtual host-based service principal functionality
from kdc/ to lib/hdb/ so that it may be automatically visible to
lib/kadm5/, as well as kadmin(1)/kadmind(8) and ktutil(1).
The changes are backwards-incompatible.
- Completes support for documenting a service principal's supported
enctypes in its HDB entry independently of its long-term keys. This
will reduce HDB bloat by not requiring that service principals have
more long-term keys than they need just to document the service's
supported enctypes.
- Adds support for storing krb5.conf content in principals' HDB
entries. This may eventually be used for causing Heimdal KDC
services to reconfigure primary/secondary roles automatically by
discovering the configured primary in an HDB entry for the realm.
For now this will be used to help reduce the amount of configuration
needed by clients of an upcoming HTTP binding of the kadmin service.
