G'Day Microsoft,

I would like assistance working out if we could improve the AD KDC to remove an attack on NON-WINDOWS Kerberos targets.

Active Directory is an awesome Kerberos KDC, and I think is significantly responsible for bringing Kerberos from academic backwaters into the central role it still plays on modern networks.

A key element of that success is that the features Microsoft added are mostly able to be safely ignored by Unix-like target servers using the traditional Kerberos libraries (eg MIT and Heimdal).

As you know, in traditional Kerberos, authorization is not well addressed, and is typically done by a name-based lookup based on the principal name in the returned ticket.

Active directory extended this notion to add the PAC, which contains the final, certain identity of the user encoded in the PAC_LOGON_INFO, and so Windows servers can of course rely on the PAC, AND ARE NOT IMPACTED BY THE ISSUES I DISCUSS HERE.

This name based authorization would not normally be a major issue, except that Active Directory also supports name aliases.  

MS-KILE 3.3.5.6.1 Client Principal Lookup)

In AD, for a canonical principal of samAccountName@REALM 

there are four main aliases for a principal:
 - case-wise changes
 - userPrincipalName
 - machineName-without-dollar
 - username@NETBIOS-DOMAIN (seems to be resolved via referrals not printed into the ticket, except when 'enterprise' is set). 

The aliases from COMPUTERNAME (in the ticket) -> COMPUTERNAME$ (in the directory) (case #2 in MS-KILE 3.3.5.6.1 Client Principal Lookup) is the most dangerous, as many AD installations allow the creation of new computer accounts with arbitrary names. 

As well as principal aliases, Active Directory introduced 'name canonicalisation'.  This was added as a Kerberos protocol feature, and the net result of it is that for Windows clients (which request it by default) the target server will always get sAMAccountName@REALM.  

Many applications are therefore coded with this expectation.

However, clients are not required to request this, and so the original name as supplied by the attacker can be printed into the ticket.

It is well established that Kerberos aliases can break name-based authorisation, if name canonicalisation is not requested: 
https://k5wiki.kerberos.org/wiki/Projects/Aliases#Client_principals_2 

The reason this mail is maked [SECURITY] is that for Samba - in attempting to be open to non-AD Kerberos realms we allow Samba to be tricked into accepting tickets without a PAC, and so trust the attacker-controlled name.

Samba has extensive tests for the name canonicalisation and sadly we know that in the presence of implicit or explicit aliases, if the AS-REQ does not request canonicalisation then the eventual ticket given by the AS-REQ and subsequent TGS-REQ will match the attacker-controlled name exactly.

We know this is a real-world issue as we have demonstrated that where Samba, as a Kerberos target, fails to find the user in Active Directory, it will fallback to the local user.  The most obvious mapping to be concerned about is root -> root$ (allowing a ticket with root@REALM).  

I'm quite concerned that Samba may not be the only application that did not expect this:  'nsswitch' ID mapping via getpwnam() seems quite common in NFSv4 for example.  In other spaces, mod_auth_kerb for Apache is well-known to be named-based, as is OpenSSH (via the krb5 auth_to_local mapping).

My request is this, given this issue only impacts on non-Microsoft products that do not strictly require a Kerberos PAC:  Is Microsoft willing to assist in protecting the industry at the source (KDC of the AD DC).

I've asked Kerberos industry veterans and the best ideas are:
 - adopting a design like this from FreeIPA:
https://www.freeipa.org/page/V4/Kerberos_principal_aliases#Design
(require canonicalisatoin flag in the AS-REQ to use any alias)
 - the same but allow case-wise mis-match
 - require canonicalisation in the AS-REQ to use a machine -> machine$ alias
 - remove the check of the principal RFC 4120 3.2.3 "The name and realm
   of the client from the ticket are compared against the same fields in the authenticator.  If they don't match, the KRB_AP_ERR_BADMATCH
   error is returned; normally this is caused by a client error or an
   attempted attack. " and always issue tickets with the canonicalised name: sAMAccountName@REALM?

(for canonicalisation restrictions, the challenge is that canonicalisation is very often not requested by unix clients (the default is off in many default krb5.conf files).

If so, could you please help us work with the security and product teams to seriously consider if this raises to a level where we should have a coordinated process?

Otherwise, Samba would like to go ahead independently (a bit like what we did with NETLOGON secure channel and LDAP integrity).  We also need to work with other implementers to always require the PAC and to always request canonicalisation when in AD domains

If you could help make enquiries in this area this would be most valuable.

Andrew Bartlett