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 avoids these compiler warnings on Ubuntu 18.04
gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)
expand_path.c: In function ‘expand_token’:
expand_path.c:493:17: warning: ignoring return value of ‘asprintf’, declared with attribute warn_unused_result [-Wunused-result]
asprintf(&arg, "%.*s", (int)(token_end - colon - 1), colon + 1);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
log.c: In function ‘fmtkv’:
log.c:646:5: warning: ignoring return value of ‘vasprintf’, declared with attribute warn_unused_result [-Wunused-result]
vasprintf(&buf1, fmt, ap);
^~~~~~~~~~~~~~~~~~~~~~~~~
mech/context.c: In function ‘gss_mg_set_error_string’:
mech/context.c:212:5: warning: ignoring return value of ‘vasprintf’, declared with attribute warn_unused_result [-Wunused-result]
(void) vasprintf(&str, fmt, ap);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mech/context.c: In function ‘_gss_mg_log_name’:
mech/context.c:319:6: warning: ignoring return value of ‘vasprintf’, declared with attribute warn_unused_result [-Wunused-result]
(void) vasprintf(&str, fmt, ap);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mech/context.c: In function ‘_gss_mg_log_cred’:
mech/context.c:346:5: warning: ignoring return value of ‘vasprintf’, declared with attribute warn_unused_result [-Wunused-result]
(void) vasprintf(&str, fmt, ap);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kerberos5.c: In function ‘_kdc_set_e_text’:
kerberos5.c:338:5: warning: ignoring return value of ‘vasprintf’, declared with attribute warn_unused_result [-Wunused-result]
vasprintf(&e_text, fmt, ap);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Now we'll put the "reason=..." last in the log lines and we won't escape
spaces -- just newlines and other control characters. This makes
reading log lines much easier without complicating parsing of log lines
because interior key=value pairs do get whitespace escaped or removed.
krb5_kdc_process_request() must return 0 when it produces a reply, and only
return non-zero when it could not construct any kind of reply (e.g., ENOMEM, or
-1 if no handler claimed responsibility for the request).
We take all of the kdc_log() and _kdc_r_log() calls in AS and TGS
and move their log levels down to debugging on the assumption that
our new log line subsumes the "informational" requirements. We
collect some additional information in the kv-pair "pe-text" which
is like e-text except it is not returned to the client.
We refactor the code a bit to extend kdc_request_t which until now
was only used for the AS. We make the structure extensible and
start using it for the TGS as well. We leave digest and kx509
alone for the time being.
We also define the concept of kv-pairs in our audit trail which
allows us to define a rigorous but extensible format:
type error from-addr client server key1=val1 key2=val2 ...
We define the meaning of the various log levels in the man page
for krb5_openlog(3). If logging configured and levels are not
specified, we change the default levels to 0-3 which should exclude
debugging messages which are generally only desired in exceptional
circumstances.
We also go through the KDC and adjust the levels to be appropriate.
* Anonymous pkinit responses from the KDC where the name
type is not well-known (as issued by 7.5 KDCs and earlier)
are accepted by the client. There is no need for the client
to strictly enforce the name type.
* With historical_anon_pkinit = true, the kinit(1) client's
"--anonymous" option only performs anon pkinit, and does
not require an '@' prefix for the realm argument.
* With historical_anon_realm = true, the KDC issues anon
pkinit tickets with the legacy pre-7.0 "real" realm.
Drafts 0 through 10 of the Kerberos anonymity internet draft,
https://tools.ietf.org/html/draft-ietf-krb-wg-anon, specified the
TicketFlags.anonymous flag as bit 14 and the KDCOptions.anonymous
flag as bit 14. These were changed to bit 16 by MIT after it was
discovered that Microsoft used KDCOptions bit 14 for S4U2Proxy
cname-in-addl-tkt.
(Feb 2007) Heimdal added constrained delegation support prior to
1.0 but named the KDCOptions flag constrained_delegation instead of
cname-in-addl-tkt as per MS-SFU. It also assigned bit 16 instead
of bit 14. Perhaps this was done in the hope that the conflict
with Microsoft would be resolved in favor of the IETF internet
draft instead of the proprietary protocol extension.
adf9121822 ("Add PA-ClientCanonicalized
and friends.") introduced the KDCOptions.constrained_delegation flag
as bit 16.
(June 2007) In order to make Heimdal's constrained delegation work
with Microsoft's implementation Heimdal began to set both KDCOptions
bits 14 and 16 when requesting constrained delegation.
d5bb7a7c56 ("(krb5_get_creds): if
KRB5_GC_CONSTRAINED_DELEGATION is set, set both") set both the
anonymous and constrained_delegation TicketFlags when issuing a
S4U2Proxy request.
(June 2010) MIT reassigned the KDCOption.anonymous and
TicketFlags.anonymous flags to bit 16. draft-ietf-krb-anon-11
was published with this change.
(July 2014) After the release of Heimdal 1.5.0 and prior to 1.5.1
it was noticed that Heimdal's anonymous TGT support did not
interoperate with MIT.
86554f5a7f ("Use correct value for
anonymous flags") swapped the bit assignments for request_anonymous
and constrained_delegation but failed to remove the setting of
KDCOptions bit 16 ("anonymous") when requesting constrained
delegation.
(May 2019) Prior to the 7.6 release many corrections to Heimdal's
anonymity support were introduced to bring it into compliance
with RFC8062. This included support for requesting anonymous
tickets via the TGS service. Because not all KDC can satisfy
anonymous requests the client must verify if the response was
anonymized. This check wasn't added until after 7.6 was
released.
014e318d6b ("krb5: check KDC
supports anonymous if requested").
The combination of setting KDCOption.anonymous when requesting
constrained delegation and the anonymized ticket validation
broke S4U2Proxy requests to Windows KDCs. Windows KDCs ignore
the KDCOption.anonymous flag when processing a TGS request
with KDCOption.cname-in-addl-tkt set.
ea7615ade3 ("Do not set
anonymous flag in S4U2Proxy request") removed the behavior
of setting the KDCOption.anonymous flag that should have
been removed in July 2014.
(June 2019) The Heimdal KDC includes fallback logic to handle
Heimdal clients from 1.0 to 1.5.0, inclusive, that set the
KDCOptions.anonymous flag as bit 14. Prior to the 7.7 release
this logic only handled AS request but failed to handle the
constrained delegation request case where both bits 14 and 16
were set in the TGS request.
cdd0b70d37 ("kdc: don't misidentify
constrained delegation requests as anonymous") added the TGS
request validation to distinguish anonymous requests from
constrained delegation requests.
This change documents the history in the commit message and
updates some in-tree comments.
Change-Id: I625cd012e2e6c263c71948c6021cc2fad4d2e53a
Earlier (pre-7.6) Heimdal clients would send both the request-anonymous and
cname-in-addl-tkt flags for constrained delegation requests. A true anonymous
TGS request will only have the former flag set. Do not treat TGS requests with
both flags set as anonymous requests.
_kdc_is_anon_request() is only used by the AS, so make it static.
Centralize anonymous poilcy checks shared between AS and TGS into a shared
function, _kdc_check_anon_policy().
When issuing an anonymous ticket, set the ticket flag early and test that
rather than re-testing the request.
When generating KRB5SignedPath in the AS, use the reply client name rather than
the one from the request, so validation will work correctly in the TGS.
_krb5_principal_is_anonymous() is used outside lib/krb5 and
therefore it needs to be properly exported and its flag macros
need to be in a public header: krb5.h not krb5_locl.h.
Including krb5_locl.h from within kuser_locl.h for instance
results in build failures on Solaris.
This change renames the function and makes it part of the public
api.
Change-Id: I130d1698b10bdbd150b95e8c7d32dfc362889ce6
Add _krb5_principal_is_anonymous() private API for checking if a principal is
anonymous or not. The third argument determines whether to match authenticated
anonymous, unauthenticated anonymous, or both types of principal.
Allow non-anonymous tickets to be used to obtain an anonymous service ticket,
by setting the anonymous KDC option. Do not include Win2K PAC in anonymous
service tickets. Validate anonymous flags per RFC 8062.
RFC8062 section 4.1 allows clients with long-term KDC keys to set the anonymous
flag; in this case their identity is authenticated but the returned ticket
contains the anonymous principal name as the client name.
kdc: allow authenticated anonymous PKINIT
The KDC PKINIT code conflated the checks for authenticated and unauthenticated
anonymous by only looking at the anonymous KDC request option.
The utility function _kdc_make_anonymous_principalname() previously returned a
principal of "anonymous" rather than "WELLKNOWN/ANONYMOUS", as specified by
RFC8062. This is not used by the AS-REQ code.
The PAC will typically contain information that may reveal the identity of a
principal. Do not include it for anonymous requests, at least until such time
as the PAC plugin API supports indicating that the request was anonymous.
RFC 8062 states that if the client in the AS request is anonymous, the
anonymous KDC option must be set in the request; otherwise, KDC_ERR_BADOPTION
must be returned. We were previously returning KDC_ERR_C_PRINCIPAL_UNKNOWN.
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.
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
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
