Add a new method for issuing referrals for entire namespaces of hostnames.
An alias of the form WELLKNOWN/HOSTBASED-NAMESPACE/service/namespace-fqdn@REALM
will cause all requests for host-based principals in the given namespace to be
referred to the given realm.
Add support for GSS-API pre-authentication to the KDC, using a simplified
variation of draft-perez-krb-wg-gss-preauth-02 that encodes GSS-API context
tokens directly in PADATA, and uses FX-COOKIE for state management.
More information on the protocol and implementation may be found in
lib/gssapi/preauth/README.md.
Sorting the units fixes a bug introduced in:
ae8908bf8 kadmin: Add disallow-client attribute
that I had fixed via:
f6ac4ee86 roken: Fix parse flags bug
which wasn't a bug at all.
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.
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.
backends
When running with verify-password-quality and a back-end that stores
history (such as heimdal-history) this command can cause an update to
the database meaning the password can no longer be used with this
principal in the future
At one point in time, the configuration option was named
"password-quality" but this was later changed to
"verify-password-quality". Update the kadmin(1) man page to reflect
this change.
warning: incompatible pointer types passing 'int *' to parameter
of type 'size_t *' (aka 'unsigned long *') [-Wincompatible-pointer-types]
Change-Id: Id75b1b1c9b46b63ab61134f4f91b7c2909d87077
Coverity determined that a NULL pointer segmentation fault could occur
if krb5_storage_emem() fails. Use krb5_enomem() to set an error message
on the context and do not perform further krb5_storage operations.
Change-Id: I9587208e46c184bb061443a44581a32dd722de33
- Add --keepold/keepallold/pruneall options to various kadmin/ktutil
commands. Default behavior to "prune old keys".
- When setting keys for a service, we need to specify enctypes for it:
- Always use kadm5_randkey_principal_3() instead of the older
kadm5_randkey_principal().
- Add krb5_string_to_keysalts2(), like MIT's krb5_string_to_keysalts(),
but with a context, and simpler.
- Add --enctypes options to various kadmin/ktutil commands.
- Add [libdefaults] supported_enctypes param with enctype[:salttype]
list.
- Add [realms] realm supported_enctypes param with enctype[:salttype]
list.
Default to aes128-cts-hmac-sha1-96:normal.
Since c6bf100b password quality checks have been moved out of kadmindd and into
libkadm5. This means that all password changes are subject to quality checks,
if enforce_on_admin_set is true (the default). In rare instances it could be
possible for realm initialization to fail because the randomly generated
passwords do not pass the password quality test. Fix this by creating
principals with no password or key, rather than with a random password.
Random *keys* continue to be set immediately after the principal is created,
and before DISALLOW_ALL_TIX is unset, so there should be no functionality or
security implications from this change. It is safe to call a server-side API
such as kadm5_s_create_principal_with_key() as local_flag is asserted to be
true.
Since c6bf100b password quality checks have been moved out of kadmindd and into
libkadm5. This means that all password changes are subject to quality checks,
if enforce_on_admin_set is true (the default). In rare instances it could be
possible for realm initialization to fail because the randomly generated
passwords do not pass the password quality test. Fix this by creating
principals with no password or key, rather than with a random password.
Random *keys* continue to be set immediately after the principal is created,
and before DISALLOW_ALL_TIX is unset, so there should be no functionality or
security implications from this change. It is safe to call a server-side API
such as kadm5_s_create_principal_with_key() as local_flag is asserted to be
true.
Note that this has a slight behavior change to c89d3f3b in order to continue
allow kadmin in local mode to bypass password quality checks. Password quality
checks are always bypassed if the *client* kadmin principal is kadmin/admin,
i.e. that of the kadmin service itself. This is the case when running kadmin in
local mode. As this is the equivalent of a superuser account, one would
anticipate that deployments would use specific administrator instances for
appropriate ACLs for day-to-day administration; operations by these will be
subject to password quality checks if enforce_on_admin_set is TRUE, or if the
user is changing their own password.
This patch adds the "enforce_on_admin_set" configuration knob in the
[password_quality] section. When this is enabled, administrative password
changes via the kadmin or kpasswd protocols will be subject to password quality
checks. (An administrative password change is one where the authenticating
principal is different to the principal whose password is being changed.)
Note that kadmin running in local mode (-l) is unaffected by this patch.
Using non-reentrant getpwuid() (or getpwnam(), or getspnam()) can be
dangerous. We had a report of a login application / PAM that calls
those, and Heimdal, by calling them too, clobbered the cached struct
passwd used by the login app / PAM.
Adding a principal with a random key or password did not respect non-default
password expiration times, because the act of setting the key or password would
clobber it with the default. As we update the principal anyway after setting
the keys, use this opportunity to restore the requested password expiration
time. (There are other ways to solve this, but this is the least intrusive.)
