In this post I want to shine some light on Kerberos authentication in combination with DNS CNAME records and what service principal names (SPN) effectively have to be set to work correctly. In a Windows environment a misconfiguration of Kerberos might be easily overlooked by an admin because Windows integrated authentication (WIA) simply switches to the NTLM (NT LAN Manager) protocol if Kerberos was not successfull and the single sign-on is transparent to the user. Only a network trace reveals what happened behind the scenes.
Setup test environment
To demonstrate the problem I will setup a test environment using a faulty configuration that gets analyzed and then corrected using the correct configuration. The service I will test against is Active Directory Federation Services (ADFS) and for the network capture I am going to use the well known Tool Wireshark.
DNS records
First of all we need some DNS records. The scenario I want to represent consists of an A record that belongs to a DNS based load balancer and a CNAME record that points to the load balancers DNS record. This is how my DNS records will look like:
| Type | Name | Content |
|---|---|---|
| A | adfs-lb.lab.irbe.ch | 192.168.3.120 |
| CNAME | adfs.lab.irbe.ch | adfs-lb |
ADFS installation
Installation of the ADFS role is done using a group managed serviec account (gmsa-adfs$) and for the federation service name I used adfs.lab.irbe.ch (the CNAME). After the installation I checked the service principal names that were registered on the gmsa account using powershell:
|
|
Because the ADFS setup only registered a SPN for the host service class, I manually add the SPN for the http service class for the url the users are accessing.
|
|
Additionally I needed to update the WIASupportedUserAgents property on the ADFS Server to include the newest Edge user agent string.
|
|
Authentication tracing
The next step was to test the Windows integrated authentication with the help of Wireshark to see what happens behind the scenes. The easiest way of testing Windows integrated authentication in ADFS is to perform an IdP initiated sign on because then we don’t have to register a relying party. This special page has to be enabled first using powershell.
|
|
WIA not working
If you are inside the corporate network and ADFS presents you the login form insted of performing single sign-on, check the following three settings which are the most common mistakes. There are tons of documents that go in depth to the topics, therefore I only point to the directions.
- Internet options is Windows integrated authentication enabled for the local intranet zone?
- Local intranet zone is the ADFS FQDN in the list of urls for the local intranet zone?
- WIASupportedUserAgents does the ADFS configuration include your user agent string?
Now lets login using the IdP initiated sign on page and have a look at Wireshark whats happening using the filter kerberos.
And voila in the frame 1119 we see the Kerberos error KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN which means that we fall back to NTLM authentication! This is totally transparent for the user because the single sign-on experience works. But this is a problem for an administrator who wants to get rid of NTLM in his/her company.
Luckily we already see the solution in the Wireshark trace in frame 1114. In the TGS-REQ (Ticket granting service request) there is the hint that the service principal name equals to HTTP/adfs-lb.lab.irbe.ch instead of the URL I called HTTP/adfs.lab.irbe.ch. That means the service principal name always has to be registered on the target of the canonical name, the DNS A record.
Fixing the configuration
So lets fix that by adding the service principal name for the A record to the group managed service account for ADFS and check again the results.
|
|
Aaaaannnd we get a TGS-REP which indicates the successfull Kerberos authentication 🥳
