ADFS Service Principal Names

ADFS prompts for credentials and successfully authenticates, but you receive HTTP 400 bad request or page not found with the address https://adfs.domina.com/adfs/ls/wia.

This is usually because someone tempered With the Service Principal Names, and that can be for multiple reasons.

The ADFS Service Account, either a regular domain user or the Group managed service account uses two Service Principal Names in ADFS 3.0/Server 2012 R2:

host/adfs.domain.com – this is used for WS federation, where the service provider doesn’t authentication on behalf of the user.
http/adfs.domain.com – this is used for SAML federation, where the user is redirected to ADFS (typical for web browsers) and for modern authentication that supports https redirect.

Bought SPN needs to be on the same service account, and these are unique values in AD, which is checked by AD, so we cannot save the setting if it exists anywhere else.

But what if it does exist anywhere else, and you don’t have a clue where? Let’s search for it:

setspn -q http/adfs.domain.com
setspn -q host/adfs.domain.com

These are built into Windows Server 2008 and newer, and will show the user having that service principal name:

PS C:\Users\demo> setspn -q host/fs.johana30.sg-host.com
Checking domain DC=itiscloudy,DC=com
CN=demo,CN=Users,DC=itiscloudy,DC=com
        http/demo-ndes01.johana30.sg-host.com
        host/fs.johana30.sg-host.com
Existing SPN found!
PS C:\Users\demo>