This post has originally been published to my other / ‘archive’ website in 2014, first as a PDF, later converted to a HTML article. I am publishing it here on my WordPress blog in April 2022, using its original publication date – as it predates most of the other articles in my PKI UPN AD Hack series.

Contents

1. Scope
2. A Really Powerful Active Directory User
3. Super Admin does not have any certificates published to the directory
4. Web application configured for SSL and client certificates
   4.1. Client Certificate Required – this is not yet authentication
   4.2. Certificate to be used for authentication
   4.3. Test: Logon without any certificate
5. External CA
6. Creating that dangerous client certificate at an ‘external CA’
7. Using this certificate for logging on to the web application
   7.1. Certificate chain validated by the web server, does not work yet
   7.2. Fixing NTAuth
   7.3. And now it finally works!
8. Summary

1. Scope

This demo is about the ‘native’ logon against Active Directory, based on mapping certificates against User Principal Names – and why Microsoft recommends to utilize this feature and related PKI functions with caution:
Security best practices for allowing SANs in certificates

In general, the use of user-defined SANs can increase the risk of impersonation attacks because it allows a user to specify arbitrary names in a certificate request. Because user input can be abused by persons with malicious intent, precautions should be taken to mitigate the risks associated with the use of user-defined SANs and protect the integrity of your public key infrastructure (PKI).

It does not apply to applications that map users against binary certificates Microsoft’s 1:1 mapping for Internet Information Server (not involving AD) or maybe – this type of mapping used in SAP. From this explanation it is not clear to me if the SAP mappings do finally include the binary certificate or if certificates are only analyzed initially to construct a name / string mapping – this probably illustrates why the very nature of certificate mappings can easily be misunderstood.  Microsoft’s Whitepapers on Smartcard Architecture explain(s) in detail how certificate processing and related name mapping works for logon against Active Directory. ‘Routing’ the UPN to a user also holds for HTTP authentication against a web server (shown in this article.)

2. A Really Powerful Active Directory User

This is the user in Active Directory (LDAP). Yes, he really is a Super Admin:

(WOP is a weird reference to Hitchhiker’s Guide to the Galaxy)

3. Super Admin does not have any certificates published to the directory

Here applications requiring encryption certificates would search for those – such as Outlook would do when Alice would try to send encrypted mail to Super Admin Bob: The friendly GUI shows the contents of the attribute userCertificate, the LDAP viewer shows some more attributes that might hold certificates. All are empty. But he has a User Principal Name – the e-mail-style logon name.

4. Web application configured for SSL and client certificates

This is an IIS web server living in the same Active Directory forest (Kerberos realm) as Super Admin. Thus it can be configured to authenticate Super Admin by mapping a certificate of his onto his user. There are two distinct configuration steps, often confused:

4.1. Client Certificate Required – this is not yet authentication

This is just to protect the handshake. The web server will accept any certificate whose chain and revocation list (CRL) it can validate.

4.2. Certificate to be used for authentication

So called Active Directory based certificate mapping authentication is enabled. This ‘module’ is not installed by default, so the web server admin has to add it on explicitly:

Needs to be enabled for the server and for the application:

All other authentication methods are disabled, so there is no chance the browser will use an existing Kerberos ticket accidentally:

4.3. Test: Logon without any certificate

As expected, logon fails (with IE, no prompt is displayed if there is no certificate in the store)

5. External CA

The Root CA is to be used is not integrated in any way with Active Directory, but its certificate is distributed as a Trusted Root CA and it is made sure that servers and clients can access CRLs. This is similar to any public CA distributed in Microsoft’s Root Program whose CDP URLs are not blocked. This is the local store of the web server who trusts this Innocuous Standalone Test CA now:

6 Creating that dangerous client certificate at an ‘external CA’

The only field that matters is the Subject Alternative Name: It needs to contain the UPN. The request is generated with the Certificates MMC, and the UPN matches the one of Super Admin. The Subject CN does not matter.

7. Using this certificate for logging on to the web application

7.1. Certificate chain validated by the web, does not work yet.

(If it would this would be rather scary)

So-called CAPI2 logging – showing all of CryptoAPI’s activities in validating chains – proves that chain building, CRL fetching etc. works, but the chain / certificate fortunately fails the final test – NTAuth policy. That is, the validating server (Domain Controller) expects to see the issuing CA’s certificates in a particular LDAP object – where it has not yet been published.

7.2. Fixing NTAuth

An Enterprise Admin needs to put the CA certificate of Innocuous Standalone Test CA into the following multi-valued LDAP object. This object is located in the Configuration container (directory partition) of Active Directory that per Default is only accessible by Enterprise Admins (= AD Gods).

7.3 And now it finally works!

The default page of the web app used an ASP server variable to display the name of the logged on user. If certificate mapping has worked this is the Active Directory user the certificate had been mapped to.

Turning on popups in the browser to see which client cert. is picked:

The certificate has obviously been mapped to Super Admin.

8. Summary

If you can create a client authentication certificate request and if you are permitted add arbitrary naming attributes to it, you may be able to escalate your privileges.

•  Active Directory based mapping does not require any binary user certificate being published to AD.
• Mapping is based on comparing the string in the certificate’s SAN with the userPrincipalName attribute in AD.
• Security hinges on the population on an LDAP object (NTAuth) that tells AD which CAs are trustworthy for issuing logon certificates.

Further reading: Specification of Microsoft – Remote Certificate Mapping Protocol Protocol details, example: web server and DC (as in this demo).