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.
Only set the PAC_EXTRA_LOGON_INFO_FLAGS_UPN_DEFAULTED flag in the
UPN_DNS_INFO_EX PAC buffer, if the provided UPN matches the cname.
This is a NOOP at present, as no UPN is provided by the Heimdal KDC.
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.
If the UPN_DNS_INFO buffer in the Windows PAC contains a canonical principal
name, use it in lieu of the ticket client name to determine the GSS-API
initiator name.
See `asn1: Add --decorate=... for internal bookkeeping`, which adds an
option to `asn1_compile` for decorating SET/SEQUENCE types with fields
that are neither encoded nor decoded, but which _are_ copied and freed.
We'll use this to add name attributes to the `Principal` type (which is
used to represent Kerberos principal names in the krb5 GSS mechanism)
without having to rototill the GSS krb5 mechanism nor the krb5 library,
and without affecting the encodings of HDB entries (which happen to use
the `Principal` type).
This option, `--decorate=TYPE-NAME:FIELD-TYPE:field-name[?]` allows one to add
a field to any struct generated by the ASN.1 compiler for any SET or SEQUENCE
type such that:
- the field will be freed by the `free_TYPE_NAME()` function
- the field will be copied by the `copy_TYPE_NAME()` function
- the field will not be printed by the `print_TYPE_NAME()` function
- the field will NOT be encoded or decoded
This is useful for internal bookkeeping.
The first use of this may well be for adding an optional field to
`Principal` where information about name attributes will be stored,
which will then allow us to have GSS name attributes for the krb5
mechanism w/o having to refactor the mechanism to use a different
structure for representing `gss_name_t` mechnames than the one currently
used (`Principal`; `krb5_principal` happens to be a typedef alias of
`Principal *`).
So w/o massive rototilling of the GSS krb5 mechanism we can have name
attributes, _and_ we'll also be able to have those in the krb5 API as
well w/o any massive rototilling there either.
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>
add HDB_CAP_F_HANDLE_ENTERPRISE_PRINCIPAL to the capability flags for the
SQLite backend, as it uses the common _hdb_fetch_kvno() helper which supports
enterprise principals.
Failure to set this flag resulted in hdb_fetch_kvno() incorrectly returning
HDB_ERR_WRONG_REALM when enterprise principals were being used, as the
enterprise name translation was instead done by _kdc_db_fetch(), thereby
squashing the enterprise name type (which otherwise would have set the
force_canonicalize option).
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.
