ADFS HTTP 400 Bad Request with SSO/Windows Integrated Authentication

by

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
To rule out any Relying party issue’s i tested the SSO with the ADFS signin page domain.com/adfs/ls/IdpInitiatedSignon.aspx. In this case the users logged in with there domainB\username account to the RDS environment in domainA.local. Every login attempt i made presented me one login prompt which shouldn’t be there if Windows Integrated Authentication was working, but ok, i will play along and provide username and password which wil result in a HTTP 400 error.
Unfortunately no clear error messages from the ADFS servers. But there was on error on the client’s RDS server that pointed me in the right direction:
===================================
Log Name:      System
Source:        Microsoft-Windows-Security-Kerberos
Date:          21/01/2016 8:55:23
Event ID:      4
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      rdshost.domainA.local
Description:
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.
spn

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.

Good Luck!
Pascal Slijkerman

 

3 thoughts on “ADFS HTTP 400 Bad Request with SSO/Windows Integrated Authentication”

  3. We had same issue with the same resolution. Someone added ADFS SPN (http/adfs.domain.com) to some other account to delegate adfs services but not sure why. we removed those from the account and it started working.

    How we found it
    setspn -q */adfs.domain.com
    for entire forest it showed account

    Reply

Leave a Comment