Test that we can dump an HDB w/o blocking write transactions.
This currently works for different processes (both backends), but not
for threads (for either backend), and it's not yet clear why.
Do not allow a change in build configuration time default HDB backend
selection cause existing default HDBs to not be possible to open.
Otherwise such a change will cause a KDC configured to use the default
HDB (i.e., without setting it in the "database" stanza in the "[kdc]"
section of krb5.conf) to not start.
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.
This is the second of two commits in a series that must be picked together.
This series of two commits moves parts of lib/krb5/ infrastructure
functionality to lib/base/, leaving behind wrappers.
Some parts of libkrb5 are entirely generic or easily made so, and could
be useful in various parts of Heimdal that are not specific to the krb5
API, such as:
- lib/gssapi/ (especially since the integration of NegoEx)
- lib/hx509/
- bx509d (which should really move out of kdc/)
For the above we need to move these bits of lib/krb5/:
- lib/krb5/config_file.c (all of it, leaving forwardings behind)
- lib/krb5/config_reg.c (all of it)
- lib/krb5/plugin.c (all of it, leaving forwardings behind)
- lib/krb5/log.c (all of it, ditto)
- lib/krb5/heim_err.et (all of it)
And because of those two, these too must also move:
- lib/krb5/expand_path.c (all of it, leaving forwardings behind)
- lib/krb5/warn.c (just the warning functions, ditto)
The changes to the moved files are mostly quite straightforward and are
best reviewed with --word-diff=color.
We're also creating a heim_context and a heim API to go with it. But
it's as thin as possible, with as little state as necessary to enable
this move. Functions for dealing with error messages use callbacks.
Moving plugin.c does have one knock-on effect on all users of the old
krb5 plugin API (which remains), which is that a global search and
replace of struct krb5_plugin_data to struct heim_plugin_data was
needed, though the layout and size of that structure doesn't change, so
the ABI doesn't either.
As well, we now build lib/vers/ and lib/com_err/ before lib/base/ so as
to be able to move lib/krb5/heim_err.et to lib/base/ so that we can make
use of HEIM_ERR_* in lib/base/, specifically in the files that moved.
Once this is all done we'll be able to use config files and plugins in
lib/hx509/, we'll be able to move bx509d out of kdc/, and so on.
Most if not all of the new functions in lib/base/ are Heimdal-private,
thus calling conventions for them are not declared.
Status:
- builds and passes CIs (Travis, Appveyor)
- ran make check-valgrind and no new leaks or other memory errors
- ready for review
HOW TO REVIEW:
$ # Review file moves:
$ git log --stat -n1 HEAD^
$
$ # Review changes to moved files using --word-diff=color
$ git log -p -b -w --word-diff=color HEAD^..HEAD \
lib/base/config_file.c \
lib/base/config_reg.c \
lib/base/expand_path.c \
lib/base/warn.c \
lib/krb5/config_file.c \
lib/krb5/config_reg.c \
lib/krb5/expand_path.c \
lib/krb5/warn.c
$
$ # Review the whole thing, possibly adding -b and/or -w, and
$ # maybe --word-diff=color:
$ git log -p origin/master..HEAD
$ git log -p -b -w origin/master..HEAD
$ git log -p -b -w --word-diff=color origin/master..HEAD
TBD (future commits):
- make lib/gssapi use the new heimbase functions
- move kx509/bx509d common code to lib/hx509/ or other approp. location
- move bx509d out of kdc/
On 32-bit Windows Intel builds the __cdecl and __stdcall calling
conventions are different so labeling the functions that are
exported or assigned to function pointers matters.
Change-Id: I03b6f34baeb9ffb2e683fd979f12f27a5078a4da
Older databases may lack explicitly stored salts where the salt is the default
one. When fetching a client entry for an AS-REQ, add default salts to keys that
lack one.
Whilst Windows does not canonicalize enterprise principal names if the
canonicalize flag is unset, the original specification in
draft-ietf-krb-wg-kerberos-referrals-03.txt says we should. Non-Windows
deployments of Heimdals are unlikely to understand enterprise principal names
in tickets, and are also unlikely to set the canonicalize flag, so this makes
sense. (It was also the behavior prior to moving the name canonicalization
logic into the KDC.)
This reverts commit 1b7e196e66.
It turns out that, contrary to the referrals draft, Windows does not
canonicalize enterprise principal names if the canonicalize KDC option is
unset.
Enterprise principal client names in AS-REQs should always be canonicalized
irrespective of the setting the canonicalize KDC option. Perform this check in
the KDC rather than HDB.
Do not set the HDB_F_GET_KRBTGT flag unless the client actually requested a TGS
principal.
Mirroring the logic recently introduced in the TGS, this patch modifies the KDC
to perform client and server canonicalization itself rather than relying on the
backend to do so. Per RFC 6806, the behavior is slightly different for the AS
in that the setting of the canonicalize flag in the AS-REQ does impact the
returned names in the ticket. In order to support realm canonicalization or
other custom behavior, we allow the backend to force the KDC to canonicalize by
setting the force-canonicalize flag in the returned client or server entries.
e11abf41 added support in libhdb for always dereferencing principal aliases
during an AS-REQ (where dereferencing refers to enabling alias lookups, and
rewriting the returned entry with the alias name unless canonicalization was
enabled).
Due to the KDC setting HDB_F_FOR_AS_REQ for all lookups from the AS, this
allowed aliases on the TGS itself to be dereferenced during an AS-REQ; however,
on presenting the TGT, the TGS would fail to resolve. Creating an explicit TGS
principal for the aliased realm would work (at least prior to c555ed6a), but
this could be confusing to deploy.
This commit changes enables alias dereferencing when HDB_F_GET_ANY is set,
which essentially means dereference whenever the request is coming from the KDC
(as opposed to, say, kadmin).
We also backout c555ed6a, which changed the TGS to always canonicalize the
server realm, as this breaks serving multiple realms from a single KDC, where
server principals in different realms share a single canonical entry.
HDB_F_CANON is now passed to the backend as a hint only, and per RFC 6806 the
principal name is never changed in TGS replies. (However, for Samba interop,
backends can override this by setting the force-canonicalize HDB flag.)
Refactor plugin framework to use a single list of loaded plugins; add a new
plugin API where DSOs export a load function that can declare dependencies and
export multiple plugins; refactor kadm5 hook API to use krb5 plugin framework.
More information in krb5-plugin(7).
Adds support for "hard" aliases when initially authenticating, that is,
allowing a client or server principal to be known by many names without
requiring that the client support name canonicalization.
In order to avoid changing the behavior for other backends such as Samba, this
is implemented in the HDB backend rather than the KDC.
To use, add an alias for both the client and TGS ("krbtgt") principals using
kadmin. This behavior is unchanged if name canonicalization is enabled.
Heimdal will refuse to create new entries when an entry already exists even
if said entry has no kerberos info and is a new entry.
This patch fixes this issue by allowing object modifications even if the
flags disallow them when we are inserting a new principal on the database.
Signed-off-by: Francisco Blas Izquierdo Riera (klondike) <klondike@gentoo.org>
Must export hdb_generate_key_set_password_with_ks_tuple() on Windows
which was introduced in 4303174a49.
Change-Id: Iea2993a17aba44c7cb0360716138c26239254e05
The change to the signature of hdb_generate_key_set_password() in
Heimdal 7.1 broke API/ABI compatibility with previous releases. We
fix this by renaming it hdb_generate_key_set_password_with_ks_tuple()
and creating a new hdb_generate_key_set_password() which calls our
new function with zeroes for the added arguments.
Issue #246https://github.com/heimdal/heimdal/issues/246
If some external library lives in a directory in which Heimdal is
already installed, we may pick up LD_LIBRARY_PATH Heimdal objects
from a different release. Move the external deps to the end, to
ensure a more appropriate LD_LIBRARY_PATH.
Commit 4b6bd40106 made hdb_ldap_create and
hdb_ldapi_create static in the OPENLDAP_MODULE case. However, by
failing to leave a blank line between the static and the function
declaration the perl program that produces the hdb-protos.h file
skips the functions.
Add appropriate spacing.
Change-Id: I9ad24176fc31a0bce92b51f7adab141e8fa70fa3
read_master_keytab() should always return with *mkey == NULL on
failure. Doing otherwise can result in memory leaks or use of
an uninitialized pointer.
Change-Id: Ice1fd504ca573d73bb51dd3b01770c3f8bc59fd4
