Duplicate SPN found - Troubleshooting Duplicate SPNs

Symptoms

After running a SETSPN -S command you may see Duplicate SPN found, aborting operation!

The Kerberos script may fail with the message Found duplicate SPNs (see Troubleshooting Kerberos).

Overview

SPNs must be unique, so if an SPN already exists for a service on a server then you must delete the SPN that is is already registered to one account and recreate the SPN registered to the correct account.

This often occurs if the SquaredUp DS application pool account or Data Access Service run as account has changed. For example, if the SquaredUp DS application pool account is changed from Network Service to a domain service account, then the SPN registered to the SquaredUp server computer account will need to be deleted and then SETSPN -S run to set the SPN to the domain service account. Or if the Data Access Service run as account is changed from local system to a service account, then the SPN registered to the SCOM server will need to be deleted and then SETSPN -S run to set the SPN to the service account.

Procedure

1. First, look at the output of the SETSPN -S command to identify the account that the SPN is already registered to and make a note of the account name.
   For example, in the screenshot below, the user has run SETSPN -S to create a new SPN on the SquaredUp server SQUP-Test-CA01 for the domain service account TestAppPool which as been set as the new application pool identity.

   

   In the screenshot above the red box highlights the account that is already registered to the SPN is the computer account SQUP-Test-CA01. In this case the SquaredUp DS application pool was previously Network Service, which is why the SPN is already registered to the SquaredUp computer account SQUP-Test-CA01. So the user needs to delete the SPN for the computer account (SETSPN -D HTTP/SQUP-Test-CA01 SQUP-Test-CA01) and then set it for the service account (SETSPN -S HTTP/SQUP-Test-CA01 sales\TestAppPool) as described in the next steps.
2. Decide if the account shown is the correct account.
   If the account shown is the correct account, then you do not need to do anything, as the SPN that already exists is correct.
   If the SPN is for the HTTP service for SquaredUp:
   The account should be the SquaredUpAccount. If the SquaredUp DS application pool is configured to use NetworkService, then the account should be the computer account for the web server. For example webserver1. If you have configured SquaredUp DS to use a domain service account then the account should be this domain service account. For example, svc-squaredup. See How to check and modify the application pool identity.
   If the SPN is for the MSOMSdkSvc service for SCOM:
   The account should be the System Center Data Access Service run as account. If the System Center Data Access Service is running as Local System, then the account should be the computer account for the SCOM server. If the System Center Data Access Service is running as a service account then the account should be that service account. See Checking the System Center Data Access Service run as account.
3. If the account shown is not the correct account, then you need to delete the existing SPN and create a new one, as described below.
4. Delete the old SPN for the short server name by running the relevant command:
   SETSPN -D HTTP/SquaredUpServer domain\OldSquaredUpAccount
   For example:
   SETSPN -D HTTP/SQUP-Test-CA01 SQUP-Test-CA01
   (domain is not required for a computer account)
   or
   SETSPN -D MSOMSdkSvc/SCOMServer domain\OldSCOMAccount
   Where OldSquaredUpAccount or OldSCOMAccount are the user or computer accounts identified in the previous step as the incorrect user or computer account that the SPN is already registered to. In step 1 this is the account shown in the red box in the screenshot after running the SETSPN -S command.
   The commands above show the short server name, but you should use the fully qualified domain name (FQDN) of the server is that is what you were using when you received the duplicate SPN message.
5. Check that it shows Updated Object.
6. Re-run the original SETSPN -S command:
   SETSPN -S HTTP/SquaredUpServer domain\SquaredUpAccount
   For example:
   SETSPN -S HTTP/SQUP-Test-CA01 sales\TestAppPool
   or
   SETSPN -S MSOMSdkSvc/SCOMServer domain\SCOMAccount
7. Check that it shows Updated Object.
8. Repeat these steps for the fully qualified domain name (FQDN) of the server.
   For example:
   SETSPN -D HTTP/SquaredUpServer.domain.tld domain\OldSquaredUpAccount
   or
   SETSPN -D MSOMSdkSvc/SCOMServer.domain.tld domain\OldSCOMAccount
   Followed by the fully qualified SPN for the SETSPN -S command:
   SETSPN -S HTTP/SquaredUpServer.domain.tld domain\SquaredUpAccount
   or
   SETSPN -S MSOMSdkSvc/SCOMServer.domain.tld domain\SCOMAccount
9. Run the SquaredUp DS Kerberos script to see if any further problems are reported (seeCollecting diagnostic information).

For more information see Troubleshooting Kerberos.