Normally when FAST is used with a TGS-REQ, the armor key is implicitly
derived from the TGT rather than armor being explicitly present, as for
AS-REQs. However, Windows allows a TGS-REQ to be explicitly armored with
a computer's TGT, so that the armor key also depends on the ticket
session key.
This is used for compound identity, where the computer's group
membership and claims are added to the PAC of the resulting ticket.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
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>
This lets us call it from Samba.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
[abartlet@samba.org Similar to Samba commit 3bdce12789af1e7a7aba56691f184625a432410d
but also fixed for caller in Heimdal windc plugin tests]
Previously, if left==right==A1_HEADER_LEN(tos), this would read past the
end of the template array. Now we treat [left, right) as a half-open
interval and no longer try to read from 'right'.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Always require a strengthen key to be used if GSS pre-authentication is used
within FAST. TRhis avoids a MITM attack that could result in unintended
privilege escalation, should a KDC add additional positive authorization data
from the armor ticket to the issued ticket.
An upcoming revision of the draft will reflect this.
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
Sync with most changes in AS/TGS client from Apple's Heimdal-597.121.1
(opensource.apple.com).
Changes include:
- FAST support in TGS client
- Refactored pre-auth client to be more easily extensible
- Pin KDC host and AD site name in API calls
Note the completely refactored TGS client loop is not imported as that was
considered too intrusive.
This reverts commit 24a7a82e82.
After further discussion in #863, the alignment (which differs according to
info buffer type) should be handled by the caller.
Decoding a FAST request will only give us the FastOptions flags that are
explicitly declared in the ASN1 source. This meant that the check for
unsupported mandatory options would never succeed, and an unsupported
option would go undetected.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
The reply structure was not being zero-initialised in all cases, leading
to crashes or possible heap corruption on error paths when we later
freed it.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Setting `dns_lookup_realm = false` in `[libdefaults]` and setting name
canon rules that force the empty realm causes destination-TGT delegation
to break because the client doesn't know the service's realm.
Because MIT and Heimdal check that the (unauthenticated plaintext)
sname/realm of the Ticket in the KDC reply matches the sname/srealm in
the enc-part of the KDC reply, we know we can trust the realm of the
ticket found in the ccache. So use that.
Setting `dns_lookup_realm = false` in `[libdefaults]` and setting name
canon rules that force the empty realm causes destination-TGT delegation
to break because the client doesn't know the service's realm.
Because MIT and Heimdal check that the (unauthenticated plaintext)
sname/realm of the Ticket in the KDC reply matches the sname/srealm in
the enc-part of the KDC reply, we know we can trust the realm of the
ticket found in the ccache. So use that.
Samba3 sends an AP-REQ, rather than 8003, checksum in a Kerberos inital context
token. This regressed in #835 as we forgot to set the
KRB5_CRYPTO_FLAG_ALLOW_UNKEYED_CHECKSUM flag before processing the AP-REQ
checksum in this path.
SQLite3 defaults to 0644 unless overridden, relying on the process'
umask to make that tighter.
Our in-tree SQLite3 uses 0600 as the permissions for DB files it
creates.
Out-of-tree builds of SQLite3 probably get the 0644 default.
We can't change the umask in libraries -- it's not thread-safe.
So this commit changes the SCC ccache type's default ccname to include
an intermediate directory which is created with `mkdir(2)` with
permissions set to 0700, then it chmods the DB file to 0644.
The in-tree SQLite3 is used for HDB and ccache -- these should have
0600 permissions.
Of course, if we're using an out-of-tree SQLite3, then we need to rely
on the process' umask, but we use SQLite3 in libraries, where we can't
set the umask...
What to do?
TBD:
- On Windows: nothing to do.
- On Unix: if SQLite3 is out of tree then [v]fork() to create the
connection then close, then connect again after??
Or... maybe make sure to create an intermediate directory with 0700
permissions?
