17 minute readApplies to: v4

Troubleshooting Kerberos

Squared Up Kerberos script

The Squared Up Kerberos script Debug-SquaredUpKerberos.ps1 queries the Kerberos configuration.

To download and run the Kerberos script see Collecting Diagnostic Information

The results are shown on screen and when an issue is identified a message is displayed which you can use to resolve the issue, using the information in this article.

For assistance resolving Kerberos issues please send a screenshot of the script results to Squared Up Support.

If the Kerberos script doesn't identify any issues but you are still prompted by the browser for a username and password, see the end of this article.

SPN 'HTTP/SquaredUpServer' exists but it is not registered to identity 'domain\SquaredUpAccount'

The script has identified an SPN for the Squared Up server but it is not registered to the Squared Up application pool identity. This may be because the Squared Up application pool identity has been changed. Follow the steps below to reconfigure the SPNs for the new Squared Up application pool identity.

Configuring SPNs for Squared Up

HTTP service SPNs need to be configured for each Squared Up server. It is important to know the Squared Up application pool identity as this determines the account the SPN is registered to.

  1. On a domain controller, click on the Start button and type:

    command prompt

  2. Right-click on the Command Prompt icon and click Run as administrator.

  3. Type:

    SETSPN -S HTTP/SquaredUpServer domain\SquaredUpAccount

    SquaredUpServer should be replaced by the name of the server where Squared Up is installed, and domain by your domain name.

    SquaredUpAccount should be replaced by the Squared Up application pool identity.

    If the Squared Up application pool is configured to use NetworkService, then the SquaredUpAccount is the computer account for the web server. For example, if Squared Up is running on server webserver1.domain.local then use domain\webserver1.

    If you have configured Squared Up to use a domain service account then this account should be used. For example, if your domain service account is domain\svc-squaredup then use domain\svc-squaredup.

    If you are unsure which account Squared Up is configured to use, check the Squared Up application pool configuration.

  4. This may report Duplicate SPN found, aborting operation!. The output also very usefully shows the account that is already registered to the SPN. See Duplicate SPN found, aborting operation! below to delete the existing SPN and recreate it.

  5. Repeat these steps for the fully qualified domain name (FQDN) of the Squared Up server:

    SETSPN -S HTTP/SquaredUpServer.domain.tld domain\SquaredUpAccount

    Where tld is the top level domain.

  6. Run the Squared Up Kerberos script to see if any further problems are reported.

If you have another address that you use to browse to Squared Up, for example in your bindings or in DNS Manager, you should create two further SPNs, one for the the shorter address and another for the fully qualified domain name (FQDN). See Accessing Squared Up via an address that is not the Squared Up server name

SPN 'MSOMSdkSvc/SCOMServer' exists but it is not registered to identity 'domain\SCOMIdentity'

The script has identified an SPN for the SCOM server but it is not registered to the System Center Data Access Service run as account. This may be because the System Center Data Access Service run as account has changed. Follow the steps below to reconfigure the SPNs for the new System Center Data Access Service run as account.

Configuring SPNs for SCOM

MSOMSdkSvc service SPNs need to be configured for the SCOM server. It is important to know the System Center Data Access Service run as account as this determines the account the SPN is registered to. For more information see OpsMgr 2012: What should the SPN’s look like?

When load balancing SCOM (whether using Network Load Balancing or a hardware load balancer) all the SCOM servers must have their System Center Data Access service running as the same service account See the Service Principal Names section at the end of this Technet article.

  1. On a domain controller, click on the Start button and type:

    command prompt

  2. Right-click on the Command Prompt icon and click Run as administrator.

  3. Type the following to set the SPN for the server short address:

    SETSPN -S MSOMSdkSvc/SCOMServer domain\SCOMIdentity

    SCOMServer should be replaced by the name of the SCOM server, and domain by your domain name.

    SCOMIdentity should be replaced by 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

  4. This may report Duplicate SPN found, aborting operation!. The output also very usefully shows the account that is already registered to the SPN. See Duplicate SPN found, aborting operation! below to delete the existing SPN and recreate it.

  5. Repeat these steps for the fully qualified domain name (FQDN) of the SCOM server:

    SETSPN -S MSOMSdkSvc/SCOMServer.domain.tld domain\SCOMIdentity

    Where tld is the top level domain.

  6. Run the Squared Up Kerberos script to see if any further problems are reported.

Troubleshooting Duplicate SPNs

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

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 Squared Up application pool account or Data Access Service run as account has changed. For example, if the Squared Up application pool account is changed from Network Service to a domain service account, then the SPN registered to the Squared Up 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.

  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 Squared Up server SQUP-Test-CA01 for the domain service account TestAppPool which as been set as the new application pool identity.

    Duplicate SPN found, aborting operation!

    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 Squared Up application pool was previously Network Service, which is why the SPN is already registered to the Squared Up 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 Squared Up:

    The account should be the SquaredUpAccount. If the Squared Up 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 Squared Up 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 for example:

    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 Squared Up Kerberos script to see if any further problems are reported.

Accessing Squared Up via an address that is not the Squared Up server name

If you have another address you use to access Squared Up, for example a DNS alias or alternative binding, you should create two additional SPNs for this address, the shorter address and the fully qualified domain name (FQDN).

If you use a load balancer there are other steps to consider, see How to configure Windows authentication when Squared Up is installed on load balanced servers

  1. On a domain controller click on the Start button type:

    Command Prompt

  2. Right-click on the Command Prompt icon and click Run as administrator

  3. Type:

    SETSPN -S HTTP/Hostname domain\SquaredUpAccount

    Where Hostname is the address you specified in DNS Manager,domain is your domain, and SquaredUpAccount is the domain service account that you set as the Squared Up application pool identity.

  4. Check that it shows Updated Object. If it shows Duplicate SPN found, aborting operation! see Troubleshooting Duplicate SPNs

  5. Once complete, type the following for the fully qualified domain name (FQDN):

    SETSPN -S HTTP/Hostname.domain.tld domain\SquaredUpAccount

    Where tld is the top level domain.

  6. Check that it shows Updated Object. If it shows Duplicate SPN found, aborting operation! see Troubleshooting Duplicate SPNs

The MSOMSdkSvc service is not listed when carrying out delegation

  1. First, check that you have opened the correct account:

    If the Squared Up application pool is configured to use NetworkService, then navigate to the computer account for the web server. For example domain\webserver1. If you have configured Squared Up to use a domain service account then navigate to this domain service account. For example, domain\svc-squaredup. See How to check and modify the Application Pool Identity

  2. Secondly, when you're on the Delegation tab, check that you're adding the correct account:

    If the System Center Data Access Service is running as Local System, locate the SCOM server. If the System Center Data Access Service is running as a service account locate that service account. See Checking the System Center Data Access Service run as account

  3. If the MSOMSdkSvc service is not listed for this account, then the SPN has not been set. Normally the SPNs are created automatically, but if they could not be created initially or the account running the System Center Data Access Service has changed, then the SPNs need to be created now.

    See Configuring SPNs for SCOM

    Once the SPNs are set correctly the MSOMSdkSvc service will be listed when carrying out delegation.

Checking the System Center Data Access Service run as account

  1. To check the System Center Data Access Service run as account on the SCOM server click on the Start button and type services.

  2. Locate the System Center Data Access Service and check the Log On As column to see whether the server is running as Local System or as a specific service account.

Still presented with the browser logon box

If the Kerberos script does not show any errors please check the following:

  1. Restart the Squared Up server(s).

  2. Re-run the squaredup4 windows command on the Squared Up server(s). See the relevant article linked from How to configure Windows authentication.

  3. Check the browsers are configured to use Windows authentication. See the relevant article linked from How to configure Windows authentication.

  4. Check Windows authentication 'Providers'

  5. Enable Kerberos event logging

Check Windows authentication 'Providers'

If the Squared Up Kerberos script finds all settings correct, but you are still seeing the browser login box, and entering the logon details of a SCOM user does not allow you access to Squared Up, then you should check the Windows authentication 'Providers' as described below.

  1. On the Squared Up server, open IIS, click on SquaredUpv4, then open Authentication from the middle pane. Right-click on Windows Authentication and select Providers.

  2. Check the list of Enabled Providers. It should show Negotiate, NOT Negotiate:Kerberos.

  3. If Negotiate:Kerberos is listed please remove this, and add Negotiate.

  4. Click OK.

  5. Before testing, you'll need to close and reopen your browser.

How to enable Kerberos event logging

If it is proving difficult to narrow down the issue, enabling Kerberos event logging may help.

  1. Enable Kerberos event logging on the Squared Up server, as described in the following Microsoft article, by setting the LogLevel value to 1:

    How to enable Kerberos event logging

  2. Once Kerberos logging is enabled on the Squared Up server, go to a client and log out and in again and attempt to open Squared Up.

  3. On the Squared Up server open Event Viewer, then go to Windows logs > System, and look for any Kerberos errors.

  4. Email a screenshot of any Kerberos errors to Squared Up Support for assistance.

You should remove Kerberos event logging once Kerberos is configured correctly.

Check that delegation has been set up

We can run a PowerShell command to check how delegation has been configured.

You will need to know:

  • Whether the Squared Up application pool is running as Network Service, or a domain service account.

  • Whether the System Center Data Access Service on the SCOM server is running as local system or a service account.

  • The relevant Distinguished Name (DN). If the Squared Up application pool is running as Network Service then you will need the DN for the Squared Up server name. If it is using a domain service account you will need the DN of that user account.

We will be running the next command on a domain controller, and you can find the Distinguished Name using PowerShell on a domain controller. For Network Service use Get-ADComputer SquaredUpServer, for a domain service account useGet-ADUser SquaredUpAccount. Alternatively, you can get the DN on a non-domain controller by running the relevant SETSPN command, either SETSPN -L SquaredUpServer or SETSPN -L SquaredUpAccount.

  1. On a domain controller click on the Start button type:

    powershell

  2. Right-click on the PowerShell icon and click Run as administrator.

    Get-ADObject "CN=SquaredUpServer,OU=organizational unit,DC=domain,DC=tld" -Properties msDS-AllowedToDelegateTo

    Where CN=SquaredUpServer,OU=organizational unit,DC=domain,DC=tld is the Distinguished Name (DN)

    You should have an output similar to the following:

    DistinguishedName : CN=SquaredUpServer,OU=organizational unit,DC=domain,DC=tld
    msDS-AllowedToDelegateTo : {MSOMSdkSvc/SCOMServerName.domain.tld, MSOMSdkSvc/SCOMServerName}
    Name : SquaredUpServer
    ObjectClass : computer
    ObjectGUID : f044abee-7ea2-49c6-8704-de379fecd1d4
  3. Check the msDS-AllowedToDelegateTo line.

If the System Center Data Access Service on the SCOM server is running as local system then msDS-AllowedToDelegateTo should show the correct SCOM server.

If the System Center Data Access Service is running as a service account then msDS-AllowedToDelegateTo should show the service account.

This information maps to the Trust this user for delegation to specified services only checkbox.

How to configure Windows authentication when Squared Up is installed on a SCOM Management Server

How to configure Windows authentication on a single dedicated server

How to configure Windows authentication when Squared Up is installed on load balanced servers

How to configure Windows authentication

How to check and modify the application pool identity

How to configure high availability

Squared Up Ltd. (c) 2018Report an issue with this article