Another challenging ADFS issue came to me this week. Here the problem was that internal user were not able to authenticate. They receive a login prompt and after providing credentials they received a “HTTP 400 bad request” error message. When users were external and use FBA they were able to login successfully. Also wen internal and the users used a different browser then Internet Explorer the were also presented with FBA and were able to login. Clearly only the login with Windows Integrated Authentication failed. And of course al was working just fine and stopped working about a week ago.
In this environment the ADFS and resource servers were in a different domain than the user accounts were. For more detail see the picture below. Beware it’s only a part of the authentication process to illustrate the topology.
After some research i ruled out serveral known issue’s like:
- DNS records were ok and was able to resolve the right IPs
- The ADFS Service account had the correct SPN
- No duplicated SPN’s
- No CName was used
- Time between domains was in sync
- The Kerberos token was not near a known limit
Date: 21/01/2016 8:55:23
Event ID: 4
Task Category: None
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server svc-ADFS. The target name used was HOST/sts.publicdomain.com. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (DOMAINA.LOCAL) is different from the client domain (DOMAINB.LOCAL), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.
The last part got me thinking maybe there are accounts in DomainB that mess up the ADFS environment. Well it turned out that a little more the a week ago somebody added another ADFS service account with a different name, but with the same SPN in DomainB.local. That was not discovered by me when i search for duplicate SPN’s with SETSPN -Q HOST/sts.publicdomain.com in domainA.local.
When we changed the SPN of the ADFS Service account in domainB.local to something else (because the new account was not yet in use), the Windows Integrated Authentication started working immediately and the error HTTP 400 was gone.
So my lesson learned, when there are multiple domains we need to check in all the domains were the authentication process goes through, to verify there are no duplicated usernames and SPN’s.