SCOM 2007 R2 what should my SPN registrations look like?

Posted on 26 August, 2009. Filed under: SCOM 2007 |

Still a lot of people seem to have problems with Service Principal Names (SPN) and where and how to set them. So with this post I want to clarify a few things and get some basic understanding of the SPN for SCOM 2007 R2 and what the configuration should look like for the most common scenarios.

A service principal name (SPN) is the name by which a client uniquely identifies an instance of a service. If you install multiple instances of a service on computers throughout a forest, each instance must have its own SPN. A given service instance can have multiple SPNs if there are multiple names that clients might use for authentication. For example, an SPN always includes the name of the host computer on which the service instance is running, so a service instance might register an SPN for each name or alias of its host. For more information about SPN format and composing a unique SPN, see Name Formats for Unique SPNs.

Before the Kerberos authentication service can use an SPN to authenticate a service, the SPN must be registered on the account object that the service instance uses to log on. A given SPN can be registered on only one account. For Win32 services, a service installer specifies the logon account when an instance of the service is installed. The installer then composes the SPNs and writes them as a property of the account object in Active Directory Domain Services. If the logon account of a service instance changes, the SPNs must be re-registered under the new account. For more information, see How a Service Registers its SPNs.

When a client wants to connect to a service, it locates an instance of the service, composes an SPN for that instance, connects to the service, and presents the SPN for the service to authenticate. For more information, see How Clients Compose a Service’s SPN.

With that in mind where the important parts are “a client uniquely identifies” meaning you can’t have multiple SPN’s for the same instance or service and “SPN must be registered on the account object that the service instance uses to log on” where the object is always an account object what means user account or computer account within Active Directory.

Now getting to the SCOM 2007 R2 scenarios.

When you have build you SCOM 2007 R2 environment and your running the OpsMgr services on your RMS with the following credential:

  • System Center Data Access running a domain based service account 
  • System Center Management running Local System
  • System Center Management Configuration running a domain based service account 

You can check your SPN settings on the computer account with

SetSPN –L computername

and they should look like this:

  • MSOMHSvc/Computername.domain.com
  • MSOMHSvc/Computername

Because the health Service (System Center Management Service) is running local system the SPN get published to the computer account object.

Now we have to check the domain account SPN to see if it’s configured correctly. You can check your SPN settings on the domain based service account with

SetSPN –L domain/serviceaccountname 

and they should look like this:

  • MSOMSdkSvc/Computername.domain.com
  • MSOMSdkSvc/Computername

This is one of the most used configuration so a lot of people should see the above settings.

In a other SCOM 2007 R2 scenario, when SCOM 2007 R2 is used for eg. Forefront “Stirling”, all service run as Local System. In case of all OpsMgr services running Local System you can check you SPN registration using:

SetSPN –L computername

and should look like this:

  • MSOMHSvc/Computername.domain.com
  • MSOMHSvc/Computername
  • MSOMSdkSvc/Computername.domain.com
  • MSOMSdkSvc/Computername
  • FfsService/Computername.domain.com (Stirling SPN not for OpsMgr)
  • FfsService/Computername (Stirling SPN not for OpsMgr)

In case when your running into double SPN registration you should remove wrongly registered SPN’s. For example in scenario one where the MSOMSdkSvc/Computername.domain.com and the MSOMSdkSvc/Computername are registered to the Computername account object and the SdkService account object you will have run into issues. To fix is to remove the MSOMSdkSvc  SPN from the computer account object running the following commands:

SetSPN –D MSOMSdkSvc/Computername.domain.com

SetSPN –D MSOMSdkSvc/Computername

Hopefully this gives you some insights on how SPN’s work and should be configured for OpsMgr.

Instead of using SetSPN for troubleshooting SPN registrations you can use ADSIEdit to set, add and remove SPN’s to account objects and see which SPN’s are already in place. To use SPN’s setting in ADSIedit follow the next steps:

  • Open a new MMC and add ADSIEDIT to the MMC
  • Connect to the domain and navigate to the SCOM computer account object
  • Find the OU=Servername in the correct OU and right click the SCOM computer object account and select properties
  • In the attribute field look and select the “servicePrincipalName” and click “Edit”
  • You can do the same for service account objects!

Now you can check, add and delete SPN’s on account objects using ADSIedit.

For those who didn’t figured the SPN names out yet:

  • MSOMHSvc = Microsoft Operations Manager Health Service (System Center Management)
  • MSOMSdkSvc = Microsoft Operations Manager SDK Service (System Center Management Configuration)

If you can’t get enough of SCOM 2007 related SPN errors and settings here are some good blog posts:

Regards,
Walter Eikenboom
http://weblogwally.spaces.live.com

About these ads

Make a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

3 Responses to “SCOM 2007 R2 what should my SPN registrations look like?”

RSS Feed for System Center Dynamics by wwwally Comments RSS Feed

Great blog post walter. Question, if the SPS\’s are correctly set as above, is there any need to configure delegation in a scenario where there are multiple MS\’s and all the roles are in separate servers?Also, any ideas as to why I would see the following getting logged in my RMS server continually:?Event ID 5The Health Server was unable to publish its public key to management group <MG> and will be unable to receive secure messages until this key is published. Attempts to publish the key will continue.Thanks,Dave

Hello Walter,In a situation where RMS is running on a Windows 2008 2 node Cluster I can\’t see registred SPNs on the cluster name. How can I manually add these two SPN using my virtual cluster name?MSOMHSvc/MYRMSCLUSTERNAME.domain.com MSOMHSvc/MYRMSCLUSTERNAMEThanksMurad


Where's The Comment Form?

Liked it here?
Why not try sites on the blogroll...

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: