Samba includes the user's long-term credentials (encrypted in the AS reply key)
to allow legacy authentication protocols such as NTLM to work even if the
pre-authentication mechanism replaced the reply key (as PKINIT does).
Samba also needs to know whether the client explicitly requested a PAC be
included (or excluded), in order to defer PAC exclusion until a service ticket
is issued (thereby avoiding a name binding attack if the user is renamed
between TGT and service ticket issuance).
References:
https://bugzilla.samba.org/show_bug.cgi?id=11441https://bugzilla.samba.org/show_bug.cgi?id=14561Closes: #864
Original authors:
- Joseph Sutton <josephsutton@catalyst.net.nz>
- Andrew Bartlett <abartlet@samba.org>
- Stefan Metzmacher <metze@samba.org>
Import KDC FAST from Apple's Heimdal-597.121.1, adding support for:
- PA-ENC-CHALLENGE
- reply key strengthening
- FAST authentication in TGS
kuser: Apple sync (squash)
krb5_init_creds_store_config/krb5_init_creds_warn_user in kinit
We were losing and leaking the reason for which kdc_check_flags() was
rejecting any S4U requests, yielding incomplete error messages.
The issue is that kdc_check_flags() wants to check the client and server
principals in the input state structure, but doesn't know about
impersonated principal name, and so we want to pass it a state structure
that has the impersonated instead of the impersonator client name. This
is a bad design, but I'm ignoring that for now and just fixing this one
leak.
When generating an AS-REQ, the TGS signature was incorrectly generated using
the server key, which would fail to validate if the server was not also the
TGS. Fix this.
Patch from Isaac Bourkis <iboukris@gmail.com>.
The principal in the PAC_LOGON_NAME buffer is expected to match the client name
in the ticket. Previously we were setting this to the canonical client name,
which would have broken PAC validation if the client did not request name
canonicalization
Split Windows PAC signing and verification logic, as the signing has to be when
the ticket is ready.
Create sign and verify the PAC KDC signature if the plugin did not, allowing
for S4U2Proxy to work, instead of KRB5SignedPath.
Use the header key to verify PAC server signature, as the same key used to
encrypt/decrypt the ticket should be used for PAC server signature, like U2U
tickets are signed witht the tgt session-key and not with the longterm key,
and so krbtgt should be no different and the header key should be used.
Lookup the delegated client in DB instead of passing the delegator DB entry.
Add PAC ticket-signatures and related functions.
Note: due to the change from KRB5SignedPath to PAC, S4U2Proxy requests
against new KDC will not work if the evidence ticket was acquired from
an old KDC, and vide versa.
Closes: #767
KRB5SignedPath was a Heimdal-specific authorization data element used to
protect the authenticity of evidence tickets when used in constrained
delegation (without a Windows PAC).
Remove this, to be replaced with the Windows PAC which itself now supports
signing the entire ticket in the TGS key.
If GSS_Accept_sec_context() returns an error status and error token, ensure we
include the error token in the PA-GSS padata in the KRB-ERROR reply, rather
than bailing out early.
Add support for GSS-API pre-authentication to the KDC, using a simplified
variation of draft-perez-krb-wg-gss-preauth-02 that encodes GSS-API context
tokens directly in PADATA, and uses FX-COOKIE for state management.
More information on the protocol and implementation may be found in
lib/gssapi/preauth/README.md.
RFC 6113 5.4.2 says that when hiding client names in the outer reply of a FAST
response, the wellknown anonymous principal MUST be used.
The previous implementation returned an empty client name and realm, which may
not be expected by some clients.
This is to match the Windows KDC behaviour, optionally.
Samba will use this mode, as Samba has tests that show
the difference and is keen for bug-for-bug/byte-for-byte
rather than strict RFC compliance where there is a
reasonable choice.
The Samba test (for reference) is
samba.tests.krb5.as_canonicalization_tests
The behaviour was changed in:
commit de1f37a6aa
Author: Luke Howard <lukeh@padl.com>
Date: Mon Jan 7 15:45:36 2019 +1100
kdc: omit default salt from PA-ETYPE-INFO[2]
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.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Windows does not check the password on an account that has been locked.
Heimdal does not implement locked_out, however the Samba hdb
backend does, and needs this checked before passwords (for bad
password lockout), not after in kdc_check_access().
Based on work to update Samba to current Heimdal by
Gary Lockyer <gary@catalyst.net.nz> and including cherry-pick of
Samba commit 580a705b83014e94556b9d5a8877406816e02190 which noted
that we need to return KRB5KDC_ERR_CLIENT_REVOKED to match Windows.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
According to #788, Windows clients expect a revoked error to be returned if the
client or service is locked out, rather than a generic policy error. This
should not affect non-Windows paths as the locked_out HDB entry flag is
otherwise not used by Heimdal.
On Ubuntu 20.04 with gcc version 9.3.0 in a Samba compile
using -Wdiscarded-qualifiers and -Werror we get:
../../source4/heimdal/kdc/kerberos5.c:2516:21: warning: passing argument 2 of ‘_kdc_set_e_text’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
2516 | _kdc_set_e_text(r, "Client have no reply key");
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
../../source4/heimdal/kdc/kerberos5.c:428:42: note: expected ‘char *’ but argument is of type ‘const char *’
428 | _kdc_set_e_text(astgs_request_t r, char *fmt, ...)
| ~~~~~~^~~
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
- Don't log "Request from wrong address (ignoring)".
- Add "wrongaddr=yes" kv to final log message.
- Add request and ticket addresses (up to 3) to final log message.
This adds support for using a Heimdal-specific PKIX extension to derive
a maximum Kerberos ticket lifetime from a client's PKINIT certificate.
KDC configuration parameters:
- pkinit_max_life_from_cert_extension
- pkinit_max_life_bound
If `pkinit_max_life_from_cert_extension` is set to true then the
certificate extension or EKU will be checked.
If `pkinit_max_life_bound` is set to a positive relative time, then that
will be the upper bound of maximum Kerberos ticket lifetime derived from
these extensions.
The KDC config `pkinit_ticket_max_life_from_cert` that was added earlier
has been renamed to `pkinit_max_life_from_cert`.
See lib/hx509 and lib/krb5/krb5.conf.5.
This adds a KDC configuration parameter that can be used to indicate
that a PKINIT client's certificate's notAfter overrides the client
principal's HDB entry's max_life. This parameter is a relative time
parameter, and it enables this only if set to a non-zero value (defaults
to zero). The value of this parameter caps the max_life inferred from
the certificate.
Status:
- And it works!
- We have an extensive test based on decoding a rich EK certficate.
This test exercises all of:
- decoding
- encoding with and without decoded open types
- copying of decoded values with decoded open types
- freeing of decoded values with decoded open types
Valgrind finds no memory errors.
- Added a manual page for the compiler.
- rfc2459.asn1 now has all three primary PKIX types that we care about
defined as in RFC5912, with IOS constraints and parameterization:
- `Extension` (embeds open type in an `OCTET STRING`)
- `OtherName` (embeds open type in an `ANY`-like type)
- `SingleAttribute` (embeds open type in an `ANY`-like type)
- `AttributeSet` (embeds open type in a `SET OF ANY`-like type)
All of these use OIDs as the open type type ID field, but integer
open type type ID fields are also supported (and needed, for
Kerberos).
That will cover every typed hole pattern in all our ASN.1 modules.
With this we'll be able to automatically and recursively decode
through all subject DN attributes even when the subject DN is a
directoryName SAN, and subjectDirectoryAttributes, and all
extensions, and all SANs, and all authorization-data elements, and
PA-data, and...
We're not really using `SingleAttribute` and `AttributeSet` yet
because various changes are needed in `lib/hx509` for that.
- `asn1_compile` builds and recognizes the subset of X.681/682/683 that
we need for, and now use in, rfc2459.asn1. It builds the necessary
AST, generates the correct C types, and generates templating for
object sets and open types!
- See READMEs for details.
- Codegen backend not tested; I won't make it implement automatic open
type handling, but it should at least not crash by substituting
`heim_any` for open types not embedded in `OCTET STRING`.
- We're _really_ starting to have problems with the ITU-T ASN.1
grammar and our version of it...
Type names have to start with upper-case, value names with
lower-case, but it's not enough to disambiguate.
The fact the we've allowed value and type names to violate their
respective start-with case rules is causing us trouble now that we're
adding grammar from X.681/682/683, and we're going to have to undo
that.
In preparation for that I'm capitalizing the `heim_any` and
`heim_any_set` types, and doing some additional cleanup, which
requires changes to other parts of Heimdal (all in this same commit
for now).
Problems we have because of this:
- We cannot IMPORT values into modules because we have no idea if a
symbol being imported refers to a value or a type because the only
clue we would have is the symbol's name, so we assume IMPORTed
symbols are for types.
This means we can't import OIDs, for example, which is super
annoying.
One thing we might be able to do here is mark imported symbols as
being of an undetermined-but-not-undefined type, then coerce the
symbol's type the first time it's used in a context where its type
is inferred as type, value, object, object set, or class. (Though
since we don't generate C symbols for objects or classes, we won't
be able to import them, especially since we need to know them at
compile time and cannot defer their handling to link- or
run-time.)
- The `NULL` type name, and the `NULL` value name now cause two
reduce/reduce conflicts via the `FieldSetting` production.
- Various shift/reduce conflicts involving `NULL` values in
non-top-level contexts (in constraints, for example).
- Currently I have a bug where to disambiguate the grammar I have a
CLASS_IDENTIFIER token that is all caps, while TYPE_IDENTIFIER must
start with a capital but not be all caps, but this breaks Kerberos
since all its types are all capitalized -- oof!
To fix this I made it so class names have to be all caps and
start with an underscore (ick).
TBD:
- Check all the XXX comments and address them
- Apply this treatment to Kerberos! Automatic handling of authz-data
sounds useful :)
- Apply this treatment to PKCS#10 (CSRs) and other ASN.1 modules too.
- Replace various bits of code in `lib/hx509/` with uses of this
feature.
- Add JER.
- Enhance `hxtool` and `asn1_print`.
Getting there!
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
