Summary: How to set a ServicePrincipalName.
Date: Around 2013
Refactor: 6 April 2025: Checked links and formatting.

While doing an AD migration from AD 2003 to AD 2008 I came across an issue with an application. This application was already installed on a server in the new domain, however, before the migration the users would use their accounts from the old domain. After the migration we found it was impossible to log on from a client server. Only if we would install the client on the application server itself logging using the new accounts would work.

Eventually we found the error in one of the logfiles, and with that, the solution as well.

Just for reference sake, the name of the application was Algo Collateral 5.2.1

The error we found was located in the trace file in the client directory, and when logging in with an account from the new domain the error would be:

Message : Security Support Provider Interface (SSPI) authentication failed. The server may not be running in an account with identity 'host/algosrv01'. If the server is running in a service account (Network Service for example), specify the account's ServicePrincipalName as the identity in the EndpointAddress for the server. If the server is running in a user account, specify the account's UserPrincipalName as the identity in the EndpointAddress for the server.

We ran the application with a service account, so we had to run this command:

setspn -A host/algosrv01 SHIFT\SRV-ALGOSRV01-APL

After running this command users could logon using their new accounts.

So why did it work without running this in the old domain? The old domain has a lower security level so didn't require these settings to be set.

Note that with these commands you can get some additional info about UPNs:

• List ServicePrincipalNames for an account:
  • setspn -L SHIFT\SRV-ALGOSRV01-APL
• Query for duplicates:
  • setspn -X