1

TL;DR: What kind of KRB5 AS-REQ ticket requests would a home-brew Kerberos client create when asked to use AltSecurityIdentities certificate fields for ticket requests?

But why?

I have a set of custom Java classes that knows how to extract a UPN from the SAN in a certificate and request a ticket from a KDC using that certificate material.

Historically, this results in a cname/principal of some simple strings representing the "login.name" and a realm. With these two pieces of information an AS-REQ to a Windows Server KDC initiates getting a ticket and handles the pre-auth using the account and key details associated with the correct user in the AD tree.

With some sites moving away from UPN principals and adopting AltSecurityIdentities I'm looking at augmenting how we do this for sites where UPNs are deprecated. (In this case, "deprecated" means that UPNs will not be used to map to AD users, and in some cases SANs on tokens may not have UPNs present.)

The problem I'm running into is that there is a lot of info about configuring AltSecurityIdentities on the server or enabling (say) Subject and Issuer mapping for some or all users. But it isn't clear to me how to provide this information to the KDC so it can find the user in the AD tree and go down the path of pre-auth, etc. There isn't a lot of information on how KRB5 clients would explicitly use any AltSecurityIdentities strings they build from certificates when requesting tickets from a Windows KDC.

Plainly put, is the "X509:<I>IssuerName<S>SubjectName" String expected to be used such that it would show up (say, in a Wireshark capture) as the "cname-string" now?

If I were to sniff the network traffic between the KRB5 client and the KDC, what might the AS-REQ req-body look like?

(I cheerfully admit I don't really understand the semi-recent KB articles suggesting "explicit" mappings to accounts as a workaround for some broken behaviour, and if this affects me or not. Perhaps cert-based mappings require implicit mappings?)

At the end of the day, none of the generic RFCs or Microsoft whitepapers shows what the cname might be for an example explicit mapping.

fa447916-e9f4-4f4d-8e23-0345dd
  • 11
  • 5

1 Answers1

0

I have not heard of UPNs being 'deprecated' before, but what you're describing sounds like PKINIT using an X.509 certificate for Kerberos pre-auth. According to [MS-PKCA] (3.1.5.2.1 Certificate Mapping), the client can specify either a traditional Kerberos principal name if it wants, or an NT-X500-PRINCIPAL name otherwise, with the latter triggering an altSecurityIdentities lookup.

But even with PKINIT, the actual Kerberos tickets continue using the same name – the user's Kerberos principal, which is already not the same as a UPN in the first place and always consists of samaccount@REALM. (For example, although AS-REQ can provide an "Enterprise name" (NT-ENTERPRISE) containing a UPN, the AS-REP will have it canonicalized to the principal name, e.g. foo\@example.com@EXAMPLE.COM becomes foo@EXAMPLE.COM. Similarly, even if the request uses NT-X500-PRINCIPAL, the returned tickets still have an NT-PRINCIPAL name.)

user1686
  • 13,155
  • 2
  • 35
  • 54
  • For the purposes of account mapping, UPNs can be deprecated in some higher security contexts. Some tokens may be issued without a UPN, as well. – fa447916-e9f4-4f4d-8e23-0345dd Apr 10 '23 at 13:41
  • This is my entire point, though. The "X509:..." string doesn't seem to be accepted in the request. I almost don't care what is in the ticket I get back, but rather what I, as the client, need to send to the KDC to give it the Subject and Issuer (for example) it needs to map the user to a realm account so the KDC can do the work of validating the request and go down the path of getting a TGT. – fa447916-e9f4-4f4d-8e23-0345dd Apr 10 '23 at 13:45
  • (i.e., no one is using any MIT commands to do any of this. This is 100% hand-crafted code that knows how to have a chat with the Windows [only] KDC.) – fa447916-e9f4-4f4d-8e23-0345dd Apr 10 '23 at 13:48
  • However, the link to that "how we differ from the standard" doc which I have not found up to now may shed some light on the necessary fields that should be provided to the KDC for the initial mapping so the account can be found before starting all the ticket stuff. – fa447916-e9f4-4f4d-8e23-0345dd Apr 10 '23 at 14:07
  • If NT-X500-PRINCIPAL is the name-type and the cname is more or less an RFC 2253 DN, what does it look like as a plain String? Because the same syntax used for the explicit mappings does not work. I don't understand why MSFT makes this so hard. – fa447916-e9f4-4f4d-8e23-0345dd Apr 13 '23 at 14:18