AD FS Troubleshooting - Integrated Windows Authentication
Integrated Windows authentication enables users to log in with their Windows credentials and experience single-sign on (SSO), using Kerberos or NTLM.
Reason integrated windows authentication fails
There are three main reasons why integrated windows authentication will fail. They are: - Service Principal Name(SPN) misconfiguration - Channel Binding Token - Internet Explorer configuration
SPN misconfiguration
A service principal name (SPN) is a unique identifier of a service instance. SPNs are used by Kerberos authentication to associate a service instance with a service logon account. This allows a client application to request that the service authenticate an account even if the client doesn't have the account name.
An example of an how an SPN is used with AD FS is as follows:
- A web browser queries Active Directory to determine which service account is running sts.contoso.com
- Active Directory tells the browser that it's the AD FS service account.
- The browser will get a Kerberos ticket for the AD FS service account.
If the AD FS service account has a misconfigured or the wrong SPN then this can cause issues. Looking at network traces, you may see errors such as KRB Error: KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN.
Using network traces (such as Wireshark) you can determine what SPN the browser is trying to resolve and then using the command line tool, setspn - Q <spn>, you can do a lookup on that SPN. It may not be found or it may be assigned to another account other than the AD FS service account.
You can verify the SPN by looking at the properties of the AD FS service account.
Channel Binding Token
Currently, when a client application authenticates itself to the server using Kerberos, Digest, or NTLM using HTTPS, a Transport Level Security (TLS) channel is first established and authentication takes place using this channel.
The Channel Binding Token is a property of the TLS-secured outer channel, and is used to bind the outer channel to a conversation over the client-authenticated inner channel.
If there's a "man-in-the-middle" attack occurring and they're decrypting and re-encrypting the SSL traffic, then the key won't match. AD FS will determine that there's something sitting in the middle between the web browser and itself. This will cause the Kerberos authentication to fail and the user will be prompted with a 401 dialog instead of an SSO experience.
This can be caused by:
- Anything sitting in between the browser and AD FS
- Fiddler
- Reverse proxies performing SSL bridging
By default, AD FS has this set to "Allow". You can change this setting using the PowerShell cmdlet Set-ADFSProperties -ExtendedProtectionTokenCheck None
For more information on this, see Best Practices for Secure Planning and Deployment of AD FS.
Internet Explorer configuration
Note
If you are using Chrome, add it to the WIA supported user agents list.
By default, Internet explorer will behave the following way:
- Internet explorer will receive a 401 response from AD FS with the word NEGOTIATE in the header.
- This tells the web browser to get a Kerberos or NTLM ticket to send back to AD FS.
- By default IE will try to do this (SPNEGO) without user interaction if the word NEGOTIATE is in the header. It will only work for intranet sites.
There are two main things that can prevent this from happening.
Enable Integrated Windows Authentication isn't checked in the properties of IE. This located under Internet Options -> Advanced -> Security.
Security zones aren't configured properly
FQDNs aren't in the intranet zone
AD FS URL isn't in the intranet zone.
