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.
Without it, Windows clients will perform an
extra AS-REQ, causing password lockout count
to increase by two instead of one.
This is an alternative to Samba commit:
978bc8681e74ffa17f96fd5d4355094c4a26691c
One difference however, it doesn't return
ENC_TIMESTAMP in PREAUTH_REQUIRED, only the
necessary ETYPE_INFO{,2} (same as Windows).
Signed-off-by: Isaac Boukris <iboukris@gmail.com>
This can happen in the error path when processing malformed AS
requests with a NULL client name. Bug originally introduced on
Fri Feb 13 09:26:01 2015 +0100 in commit:
a873e21d7c
kdc: base _kdc_fast_mk_error() on krb5_mk_error_ext()
Original patch by Jeffrey Altman <jaltman@secure-endpoints.com>
The ASN.1 functions copy_Realm(), copy_PrincipalName() and
copy_EncryptionKey() can fail. Check the return and perform error
handling as appropriate.
Change-Id: I2b3629d19db96eb41d1cd554cef1dca99745e753
The _kdc_is_anonymous() helper function must take into account
that principals of type NT-UNKNOWN can match any other principal
type including NT-WELLKNOWN.
Change-Id: I6085b9471f6f1d662119e359491bbdce629ef048
A backend can return this if asked with HDB_F_GET_CLIENT|HDB_F_FOR_AS_REQ
for a KRB5_NT_ENTERPRISE_PRINCIPAL record or for HDB_F_GET_SERVER | HDB_F_FOR_TGS_REQ.
entry_ex->entry.principal->realm needs to return the real realm of the principal
(or at least a the realm of the next cross-realm trust hop).
This is needed to route enterprise principals between AD domain trusts.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
This got removed between draft-ietf-krb-wg-kerberos-referrals-11.txt
and the final rfc6806.txt.
The number 133 was reassigned to PA-FX-COOKIE in rfc6113.txt.
(Samba commit 9ebd10b3432c271625db9fbc1987759c02b23f83 forward-ported
to Heimdal master by Andrew Bartlett)
This is required to ensure the client still gets errors like KRB5KDC_ERR_PREAUTH_FAILED, rather than
KRB5KDC_ERR_PREAUTH_REQUIRED, which become a confusing KRB5_GET_IN_TKT_LOOP.
Andrew Bartlett
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Pair-programmed-with: Garming Sam <garming@catalyst.net.nz>
Signed-off-by: Garming Sam <garming@catalyst.net.nz>
rfc6112 requires kdcs implementing anonymous PKINIT to include an
empty PKINIT-KX padata in PREAUTH_REQUIRED messages.
Including this improves compatibility with MIT kerberos.
if the query is "preauth" and the caller is seeking a Key, search
try to find a Key that has the default salt but do not exclude keys
that have a non-default salt.
Move the assignment of 'ret' and 'enctype' before the preauth
default salt test. If the only key of the given type is the non-default
salt key, it should be used.
If the caller is not seeking a Key, do not bother with the preauth
test at all since the Key itself doesn't matter and we are simply
seeking an enctype.
Change-Id: I7cd37c579c0bfdd88bccfbc9eb5e5f55cd1910cb
If _kdc_find_etype() is being called with 'ret_key' != NULL, the
caller is attempting to find an actual principal key. If 'ret_key'
is NULL then it is seeking a session key type. Only return an enctype
that is not in the principal key list unless 'ret_key' is NULL.
As part of this change remove 'clientbest' and the associated
logic as it is both unnecessary and can produce an enctype for
which the key cannot be returned.
Change-Id: Iba319e95fc1eac139f00b0cce20e1249482d2c6f
The 'use_strongest_session_key' block and its alternate should
have similar behavior except for the order in which the enctype
lists are processed. This patchset attempts to consolidate the
exit processing and ensure that the inner loop enctype and key
validation is the same.
Bugs fixed:
1. In the 'use_strongest_session_key' case, the _kdc_is_weak_exception()
test was applied during the client enctype loop which is only
processed for acceptable enctypes. This test is moved to the
local supported enctypes loop so as not to filter out weak keys
when the service principal has an explicit exception.
2. In the 'use_strongest_session_key' case, the possibility of an
enctype having keys with more than one salt was excluded.
3. In the 'use_strongest_session_key' case, the 'key' variable was
not reset to NULL within each loop of the client enctype list.
4. In the '!use_strongest_session_key' case, the default salt test
and is_preauth was inconsistent with the 'use_strongest_session_key'
block.
With this consolidation, if no enctype is selected and the service
principal is permitted to use 1DES, then 1DES is selected. It doesn't
matter whether 'use_strongest_session_key' is in use or not.
Change-Id: Ib57264fc8bc23df64c70d39b4f6de48beeb54739
Different ticket session key enctype selection options should
distinguish between target principal type (krbtgt vs. not), not
between KDC request types.
AD issues x-realm TGTs with kvno 0. On key x-realm trust key change
we need to be able to try current and previous keys for trust, else
we will have some failures.
