Add a hook for changing a password with a key. This hook should be consolidated
into one shared with randkey and setkey, but for now I have continued to have
the hooks follow the kadm5 APIs themselves in both signature and quantity.
(This means the randkey one isn't actually very useful because it doesn't
provide the hook with the keys.)
Now that we always enforce password quality policies, ktutil get fails
because it uses "x" as a password when creating a principal.
Of course, it's probably a misfeature that ktutil get creates principals when
they don't exist...
If the salt for the AS-REP client key matches the default password salt for the
client principal in the AS-REQ, then it can be omitted from the PA-ETYPE-INFO,
PA-ETYPE-INFO2 (RFC4120) as the client will assume the default salt in its
absence.
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.
Heimdal's current behavior regarding the generation of PA-ETYPE-INFO2
and PA-ETYPE-INFO violates RFC4120 in two ways:
1. when generating responding both PA-ETYPE-INFO2 and PA-ETYPE-INFO
the hints returned in the inverse order: INFO then INFO2 instead
of INFO2 then INFO.
2. the determination that both PA-ETYPE-INFO2 and PA-ETYPE-INFO is
currently based upon the KDC selected enctype when it should be
determine based upon examining the entire enctype list specified
by the requesting client.
This change corrects the behavior to follow the RFC4120 guidance.
Change-Id: I6ebda8a813c25f9296f10314e32e93a22380ca72
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.)
windc doesn't link against libkdc, so it doesn't need to check its instance;
however, we will continue to export kdc_get_instance() from libkdc in case
other windc plugins do link against it.
warning: incompatible pointer types passing 'int *' to parameter
of type 'size_t *' (aka 'unsigned long *') [-Wincompatible-pointer-types]
Change-Id: Id75b1b1c9b46b63ab61134f4f91b7c2909d87077
Implementation of gss_set_neg_mechs() and gss_get_neg_mechs() as defined in RFC
4178. New gss_release_cred_by_mech() API for dropping a credential from a
mechanism glue credential.
SPNEGO uses the callback function acceptor_approved() in order to determine
which mechanisms to advertise to the initiator in the case that the initiator
sent an empty initial context token. Prior to this commit, that function was
not passed in the acceptor credential (if present), so always uses a default
credential. For correctness, we should only advertise the availability of
mechanisms for which we have a credential.
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).
Apple's Heimdal impelmentation uses a number of utility functions for
allocating names and credentials, to avoid calling malloc or calloc directly.
Import them.
Implement the GSS-API credential store API extensions defined by MIT here:
https://k5wiki.kerberos.org/wiki/Projects/Credential_Store_extensions
Note: we kill off gss_acquire_cred_ext() here. This was never a public API,
although mechanisms could have implemented it and I briefly used it in my
BrowserID prototype mechanism. gss_acquire_cred_ext_from() occupies the place
in the dispatch table where gss_acquire_cred_ext() used to, but this structure
was never visible outside Heimdal (i.e. it is only used by internal
mechanisms);
(Mechanisms that need to accept arbitrary key/value dictionaries from
applications should now implement gss_acquire_cred_from().)
SPNEGO uses the callback function initiator_approved() in order to determine
mechanism availability. Prior to this commit, is not passed in the initiator
credential, so it always uses a default credential. This breaks SPNEGO if a
non-default credential (such as one acquired with
gss_acquire_cred_with_password()) is used. This commit addresses this.
gss_krb5_set_allowable_enctypes() was declared with an array of int32_t types
representing the enctype list, but the definition had an array of krb5_enctype.
Whilst these are likely the same size, they may not be. On the receiving end,
allocate an array of krb5_enctype.
* check `ctx->gc_ctx` in `gss_inquire_context()`
* check `gm_inquire_cred != NULL` in `gss_inquire_context()`
* check `min_lifetime` in `gss_inquire_cred()`
* check `gm_inquire_cred_by_mech != NULL` in `gss_inquire_cred_by_mech()`
* set mech error in `gss_inquire_cred_by_oid()`
* don't clobber error in `gss_inquire_cred_by_oid()`
* don't pass NULL minor_status to `gss_krb5_free_lucid_sec_context()`
* allow NULL ccache in `gss_krb5_ccache_name()`
* NULL names OK in `_gss_find_mn()`
* allow empty names in `gss_import_name()` (removes `input_name_buffer` length
check). to support ANONYMOUS. in `gss_import_name()`, ignore mech name
import failure as long as it's possible to import the name in some other
mechanism
* better argument validation in `gss_export_sec_context()`
* in `gss_compare_name()`, check `mn2 != NULL`
* check `gss_add_oid_set_member()` return code in `gss_indicate_mechs()`
* in `gss_destroy_cred()`, set output cred handle to `GSS_C_NO_CREDENTIAL`
* cast size_t to OM_uint32 where required
