Remove the outpadata field from astgs_request_t, because it's not something we
wish to expose publically (yet it is something that Samba needs in the
client_access plugin API, to add Windows error information).
Instead, allocate rep->padata at the start of AS/TGS request handling, and
ensure it is valid for the lifetime of the request until it is encoded (at
which point it will be freed and set to NULL if zero length, to avoid sending a
zero length METHOD-DATA to the client).
(The previous approach of setting rep->padata to point to &r->outpadata was
fragile, because it required clearing the pointer before freeing the KDC-REP.)
Make client_access plugin API take a single argument, astgs_request_t. Note: in
order to avoid making r->outpadata public (it's an internal buffer), but allow
Samba to modify the reply pa data, some pointer magic is required.
Add a helper function that returns TRUE if a PAC should be included in ticket
authorization data, that can be called from both AS and TGS paths.
Per [MS-KILE] 3.3.5.3, PACs are always included for TGTs; for service
tickets, policy is governed by whether the client explicitly requested
a PAC be omitted when requesting a TGT, or if the no-auth-data-reqd
flag is set on the service principal entry.
Remove the unwieldy pac_attributes_present field from the request structure.
Instead, if PAC attributes are not present in the TGT, the default is to assume
they were set to KRB5_PAC_WAS_GIVEN_IMPLICITLY.
Distinguish pre-authentication mechanisms that replace the reply key from those
that use the client's long-term key. In the general case, one is the inverse of
the other, however KRB5_PADATA_ENCRYPTED_CHALLENGE replaces the reply-key with
one derived from the long-term key.
PA_REPLACE_REPLY_KEY indicates that the kvno should be set to zero in the
reply; the absence of PA_USES_LONG_TERM_KEY indicates that the client's
long-term key may be included in the PAC (PAC_CREDENTIAL_INFO with Samba only).
Corrects e8984871.
Distinguish pre-authentication mechanisms that replace the reply key from those
that use the client's long-term key. In the general case, one is the inverse of
the other, however KRB5_PADATA_ENCRYPTED_CHALLENGE replaces the reply-key with
one derived from the long-term key.
PA_REPLACE_REPLY_KEY indicates that the kvno should be set to zero in the
reply; the absence of PA_USES_LONG_TERM_KEY indicates that the client's
long-term key may be included in the PAC (PAC_CREDENTIAL_INFO with Samba only).
PACs are included when issuing TGTs, if there is no PAC_ATTRIBUTES buffer
(legacy behavior) or if the attributes buffer indicates the AS client requested
one.
Only include the PAC_ATTRIBUTES PAC info buffer if we are issuing a TGT, as its
contents are not relevant to application services. (The buffer contains a bit
indicating whether the client explicitly or implicitly requested a PAC.)
In the altsecid GSS pre-authentication authorizer plugin, don't add the
REQUESTOR_SID PAC info buffer unless the client requested a TGT. It is not
relevant to application services.
Update the sample GSS pre-authentication authorizer plugin to allow the PAC to
be pinned to the authenticating user's SID.
There is still a race condition between the time the user authenticates and the
time the SID is looked up via LDAP, but it should be sufficient as an example;
if more security is required, then users should be enrolled with their SIDs.
Note the selected pre-authentication mechanism, and add a callback to allow the
pre-authentication mechanism to update the PAC immediately prior to signing.
Add PAC_ATTRIBUTES_INFO to the PAC. This info buffer indicates whether the user
explicitly requested a PAC be present or absent.
Note: this changes the windc plugin ABI.
Use the UPN_DNS_INFO buffer of the PAC to include the canonical principal name.
Arguably we should use AD-LOGIN-ALIAS as defined in RFC6806, but we may not
always know all the principal's aliases, and this approach allows us to share
application service logic with Windows.
r->client_princ and r->server_princ are only set in the AS-REQ case, but
we perform the PAC check in the TGS-REQ case, so calling
krb5_unparse_name() will dereference a NULL pointer. Instead, use
r->cname and r->sname.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
08e0305b introduced a patch to validate armor ticket PACs, but required that
the armor client principal was in the local realm (as it did not allow
_kdc_db_fetch() to fail).
Allow cross-realm FAST armor clients by using the same logic to look up the
client principal as the TGS itself does, i.e. use db_fetch_client() which
handles the case where the client is not local to the KDC.
Note: the armor PAC is only required to be validated when issuing a final,
non-referral service ticket, as this is the only point upon which device claims
should be inserted (according to my understanding).
Closes: #901
Add a new authorization data type to indicate a synthetic principal was used,
to allow synthetic clients acquired outside of PKINIT (e.g. with GSS-API
pre-authentication) to use the TGS.
Note: we continue to honor KRB5_AUTHDATA_INITIAL_VERIFIED_CAS to indicate that
it is OK for the client to be synthetic, even though it is only an indication
that the client *may* have been synthetic.
This reverts commit 6f81e4c93b.
This patch may have originated in Samba from before force_canonicalize was
supported. Because the server_principal argument to tgs_make_reply() is
canonicalized prior to calling (if the server entry has force_canonicalize
set), honoring it again in tgs_make_reply() is superfluous.
Look up the client name of the armor TGT in the database, and check that
the PAC is valid.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Closes: #891
This allows Samba to have a behaviour where
even if canonicalize flag is not set, the canonical realm
is returned, allowing a HDB module to require behaviour
that is the same as Windows.
Regression (for a HDB module wanting AD behaviour) was
introduced by commit:
378f34b4be
Signed-off-by: Isaac Boukris <iboukris@gmail.com>
[abartlet@samba.org Similar to Samba commit a9e6119ca0c2a78ef314c3162122539ee834aa04
but made conditional on server->entry.flags.force_canonicalize to
allow upstream submission]
If the pre-authentication mechanism replaced the reply key, then the kvno in
the KDC-REP should be zero, as the reply is not encrypted in the client's
(versioned) long-term key.
Closes: #899
We now pass on the original client name and the client address to allow
consistent audit logging in Samba across multiple protocols.
We also log the authentication duration.
This is not a general purpose profiling solution, but in Smaba
these JSON logs are already being generated and stored, so this
is worth adding.
Some administrators are very keen to know how long authentication
takes, particularly due to long replication transactions in other
Samba processes.
We use config->db[0] to find the first database to record incorrect
users.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
(Similar to Samba commit f498ba77df2313e78863e5f2706840c43e232a96 and
bb2a1c6b3eaccf114ac3f3b5b51f57828a04996)
[metze@samba.org: improved for heimdal upstream]
Signed-off-by: Stefan Metzmacher <metze@samba.org>
[abartlet@samba.org: improved again for Heimdal based on feedback]
AES256 and AES128 are newer enctypes because they are officially
specified in RFC4120 and RFC8009, while enctypes not officially
specified since RFC4120 are considered older. This function differs from
older_enctype() in that it does not report unknown or non-existent
enctypes as being 'newer'.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Assists Samba to address CVE-2020-25719
It is critical to ensure that the name in the U2U TGT is still associated with
the account was issued to, so we must check the PAC to verify the SID.
Otherwise the SPN check via the S4U2Self hook might be mislead.
Samba BUG: https://bugzilla.samba.org/show_bug.cgi?id=14873
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
(Similar to Samba commit 49a13f0fc942d1cfb767d5b6bf49d62241d52046)
Assists Samba to address CVE-2020-25719
Again, this may be contary to RFC4120 3.3.3
https://datatracker.ietf.org/doc/html/rfc4120/#section-3.3.3
(clearer at the GSS spec here:
https://datatracker.ietf.org/doc/html/draft-swift-win2k-krb-user2user-03 )
as server-name is decribed as optional, however Windows AD and Samba
both require that the server-name exist and be a valid SPN matching
the provided TGT.
The lookup of SPN -> entry ensures that the SPN the client thought it
was connecting to was held by the target server. it could be the
typical user principal, or a service principal, but needs to be checked
for the client not to be fooled into connecting to the wrong service.
The check is the same as needed for S4U2Self so the same HDB hook is re-used.
Samba BUG: https://bugzilla.samba.org/show_bug.cgi?id=14873
(Similar to Samba commit f08e6ac86226dcd939fd0e40b6f7dc80c5c00e79)
Assists Samba to address CVE-2020-25719
This may be contary to RFC4120 3.3.3 at
https://datatracker.ietf.org/doc/html/rfc4120/#section-3.3.3
(clearer in the GSS mechanism here:
https://datatracker.ietf.org/doc/html/draft-swift-win2k-krb-user2user-03 )
as server-name is decribed as optional, however Windows AD and Samba
both require that the server-name exist and be a valid SPN matching
the provided TGT.
The lookup of SPN -> entry ensures that the SPN the client thought it
was connecting to was held by the target server. it could be the
typical user principal, or a service principal, but needs to be checked
for the client not to be fooled into connecting to the wrong service.
Samba BUG: https://bugzilla.samba.org/show_bug.cgi?id=14873
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
(Similar to Samba commit fd50fecbe99ae4fc63843c796d0a516731a1fe6a)
Assists Samba to address CVE-2020-25719
Passing in target_server as a string principal means that for
an alias we must looking up the DB twice.
This is subject to a race and is a poor use of resources,
so instead just pass in the record we
already got when trying to confirm that the server in
S4U2Self is the same as the requesting client.
We also avoid doing a name comparison if the HDB plugin provides
a validation hook, this allows the HDB layer more freedom
to choose how to handle things.
In Samba AD the client record has already been bound to the the
original client by the SID check in the PAC, so the record is
known to match the ticket.
Likewise by looking up server only once we ensure that the
keys looked up originally (to decrypt) are in the record
we confirm the SID for here.
Samba BUG: https://bugzilla.samba.org/show_bug.cgi?id=14686
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
(Based on Samba commit 05898cfb139ae0674c8251acc9d64c4c3d4c8376)
