SCSM 2012 use the Kerberos protocol to authenticate clients and servers and encrypt data inside of communication channel. The of main concept of the Kerberos protocol regarding Windows services is a Service Principal Names (SPN) records. If your SPN records absent or configured for wrong account\service name then you can except what some function will be work with issues or doesn’t work at all.

Regarding to SCSM the misconfiguration of the SPN records can affect:

• Active Directory connector. It will run but nothing happened after that.
• DW process. Data from ServiceManager DB will not import to DW DB
• High memory consumption by SCSM’s services

and few other issues.

Also as result of misconfiguration of the SPN records can be event like this:

Log Name:      System
Source:        Microsoft-Windows-Security-Kerberos
Date:          01.10.2012 14:10:04
Event ID:      4
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      scsm12.syscenter.local
Description:
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server SCSMService. The target name used was MSOMSdkSvc/scsm12.syscenter.local. 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. Please ensure that the target SPN is registered on, and only registered on, the account used by the server. This error can also happen when the target service is using a different password for the target service account than what the Kerberos Key Distribution Center (KDC) has for the target service account. Please ensure that the service on the server and the KDC are both updated to use the current password. If the server name is not fully qualified, and the target domain (SYSCENTER.LOCAL) is different from the client domain (SYSCENTER.LOCAL), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

Which SPN records used by SCSM 2012?

The SCSM 2012 use the SPN with he service class “MSOMSdkSvc”. SPN must be registered to service account (or run as account for  System Center Data Access Service).

There is a two options can exist. First if your service account is Local System (this is extremely bad idea). In this case the SPN record must be registered to account of the SCSM server(s). This account named as server name with $ sign at the end (SERVER$).

Second option if your service account is a domain account. In this case SPN record must be registered to this domain account

When I should configure the SPN records for SCSM 2012?

Always. The bad news is what during setup process SPN records aren’t registered even if your setup account have permission to do that. Instead of this the SDK service(System Center Data Access Service) check the SPN records each time when it started. And trying to create SPN records if they doesn’t exist. But by default only domain administrators can modify the SPN records and your SCSM’s service account must never have this rights. The second issue is a bug inside of SCSM itself. It always try to register SPN records for server’s account even if SDK service running under domain account. You can find events like this in Operations Manager log each time when SDK service stared:

Log Name:      Operations Manager
Source:        OpsMgr SDK Service
Date:          04.11.2012 13:07:26
Event ID:      26371
Task Category: None
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      scsm.syscenter.local
Description:
The System Center Data Access service failed to register an SPN. A domain admin needs to add MSOMSdkSvc/scsm and MSOMSdkSvc/scsm.syscenter.local to the servicePrincipalName of CN=SCSM,OU=SCSM,OU=ServiceAccount,DC=syscenter,DC=local

In my case the SCSM is a server and my SDK service running under SCSMService domain account.

So even if you grant permissions for service account to modify the SPN records the wrong SPN records will be created.

How to check SPN records for SCSM 2012

To check SPN records you must run next commands:

setspn –L YOURDOMAIN\SCSMSERVER$
setspn –L YOURDOMAIN\ServiceAccount

where SCSMSERVER$ is a server account of your management server. First command must be repeated for all of your management servers (and DW too).

To check the result of the each command see in table below.

Command	Service Account is Local System	Service Account is Domain account
setspn –L YOURDOMAIN\SCSMSERVER$	The result must contains two strings: MSOMSdkSvc/SCSMSERVER MSOMSdkSvc/SCSMSERVER.fqdn.name	The result must NOT contains any strings with MSOMSdkSvc class
setspn –L YOURDOMAIN\ServiceAccount	–	The result must contains two strings: MSOMSdkSvc/SCSMSERVER MSOMSdkSvc/SCSMSERVER.fqdn.name

Here is example of the right result of setpsn -L for my test environment:

I have a two SCSM servers named SCSM12 and SCSM. Both of them use SCSMService account as service account.

Another issue can be a duplicated SPN records. To check this run command

setspn -X

How to add SPN records

If your service account is Local System:

setspn –A  MSOMSdkSvc/SCSMSERVER YOURDOMAIN\SCSMSERVER$
setspn –A  MSOMSdkSvc/SCSMSERVER.fqdn.name YOURDOMAIN\SCSMSERVER$

If your service account is domain account:

setspn –A  MSOMSdkSvc/SCSMSERVER YOURDOMAIN\ServiceAccount
setspn –A  MSOMSdkSvc/SCSMSERVER.fqdn.name YOURDOMAIN\ServiceAccount

You must repeat this commands for each of your management servers (DW too).

Also you must restart SDK Service to take effect.

How to remove wrong SPN records

setspn –D  MSOMSdkSvc/SCSMSERVER YOURDOMAIN\SCSMSERVER$
setspn –D  MSOMSdkSvc/SCSMSERVER.fqdn.name YOURDOMAIN\SCSMSERVER$

Appendix. Active Directory configuration for Kerberos delegation.

The second of main concepts of the Kerberos protocol is a delegation. Kerberos Delegation is a feature that allows an application to reuse the end-user credentials to access recourses hosted on a different server. SCSM use the delegation so it must be properly configured.

Delegation requirements is:

Active Directory domain and forest level must be “Windows Server 2003” or above
Server must be trusted for delegation
For service account must not be turn on option “Account is sensitive and cannot be delegated”.

To check your forest level you must run the “Active Directory Domains and Trusts” snapin, select root of the tree, call the context menu and press “Raise Forest Functional Level…”:

Here you can find level of your forest:

To check your domain level you must run the “Active Directory Users and Computers” snapin, select your domain, call the context menu and press “Raise domain Functional level…”:

Here you can find level of your domain:

To check “trusted for delegation” option find your server in “Active Directory Users and Computers” snapin and open Properties. On Delegation tab must be selected option “Trust this computer tor delegation to any service (Kerberos only)”:

To check the service account option find your account in “Active Directory Users and Computers” snapin and open Properties. On Account tab find the “Account is sensitive and cannot be delegated” and check what it NOT enabled.