chpass_principal_with_key_hook_cb added by 57c25d9828 must be
KRB5_LIB_CALL for 32-bit Windows builds.
Change-Id: Ifd61caeee76f9d048bb13f93e226b99ce7e8b75c
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
the code generated by asn1_compile.exe includes a large number
of unreferenced local variables. The resulting warnings drown
out other potentially more serious warnings.
This change suppresses the C4101 warnings in the generated
source files.
Change-Id: I17642ff427f457c885b1eb0e62436f3bc9057ee1
Heimdal declares functions that never return as non-void. Suppress
the following warnings now that functions are labeled 'noreturn'.
4646 - function declared with __declspec(noreturn) has non-void return type
4716 - 'function' must return a value
Change-Id: Id85cc435e99688bae7326a723a5a80d828859bf2
The 'plugin_prefix' variable was declared 'const' which generates
a warning because the C string is freed.
This change removes the 'const' designation.
Change-Id: I6f3838d6dbf1bb496f286c96aea96bae8948930d
gss_acquire_cred_from() is an exported function and therefore
must be tagged with GSSAPI_LIB_FUNCTION and GSSAPI_LIB_CALL.
Change-Id: I80918cb8083eaeac2d0eba5347f7b428e997cfaa
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).
