Поделиться через

OpsMgr 2012: What should the SPN’s look like?

  • Статья

<!--[if lt IE 9]>

<![endif]-->

Comments

  • Anonymous
    January 01, 2003
    Hi Leau -

    You didn't spot that because I just added it. I realized my article must not be complete enough because there remains confusion, so I added more context to clarify it. :-)

    You should remove SDK SPN's from the computer accounts because they are wrong, and should be on the domain account running the DAS service. You should NOT ever have duplicate SPN's, the AD people will get angry about that. As to if you need them? These are used for Kerberos authentication for the SDK. However, in most cases they aren't necessary as console authentications will fall back to NTLM. They become more critical when you do things like place a web console server on a non-management server, or ever need to set up constrained delegation for multiple-hop Kerberos authentications.... such as when using windows auth to the web console when it isn't running on a local management server.

  • Anonymous
    January 01, 2003
    Hi Kevin,

    Please correct me if I am mistaken the concept, do we still need to register SPNs for a SCOM environment which has 1 MS?

  • Anonymous
    January 01, 2003
    Yes - from what I can tell - the event/alert is a bug, and is incorrect.  The SPN's are the same as they were in OpsMgr 2007 - the SDK SPN for the DAS account should be attached to the domain user account, not the Computer account in the domain.  The only difference between OpsMgr 2007 and OM12 is that there will be multiple SDK SPN's on the domain user account that runs the SDK service, one for each management server since all run the SDK service.

  • Anonymous
    January 01, 2003
    Thanks Kevin! -Tom

  • Anonymous
    January 01, 2003
    @LeaUK -
    That is a the worst thing you could do. The alert in SCOM is a bug and wrong. When you use a domain account for the SDK/DAS account, the SPN's should be written to the domain account and not the computer account. When you made the service account a domain admin, it now had rights to write the SPN, which it wrote to the computer account.... and should not have done so.

  • Anonymous
    January 01, 2003
    very very very good info, thanks Kevin

  • Anonymous
    January 01, 2003
    @Tom Slik -

    The article states what the SPN's should be. The Computer accounts should only have healthservice SPN. The domainsdk account should have the SDK SPN, when you use a domain account for the SDK services. No exceptions, and no duplicate SPN's are allowed.

  • Anonymous
    January 01, 2003
    You should DELETE it from the Computer object, and ADD it to the account that runs the DAS service. The only time the SPN should exist on the computer object, is if you are using Local System as your SDK/DAS account.

  • Anonymous
    January 01, 2003
    The alert is in error and should be disabled.

  • Anonymous
    January 01, 2003
    No - there is no service outage caused by writing a SPN. It is a simple attribute of an AD object.

  • Anonymous
    May 17, 2012
    Can you confirm this is correct for OM12?  We are still seeing the errors in the Operations Manager log and alerts generated in OM12 regarding SPN's.  Apparently the SDK wants us to add the SPN to each MS computer, rather than the SDK domain account...

  • Anonymous
    July 10, 2012
    We setup our SPN's correctly registering the MSOMSdkSvc/<mgmtSvr> SPN's to the SDK service account and removing from the Ops Manager Server computer accounts. However everytime we restart a managment server or just restart the SDK service a duplicate MSOMSdkSvc/mgmtSvr gets registered against the ops manager server account.

  • Anonymous
    October 26, 2012
    Kevin, I have new setup of SCOM 2012 sdk service is running under a user account when i go to ADSIEDIT and check spn's under the user account it does not show any spn registered for MSOMSDKSVC i see the spn registered for MSOMSDKSVC under the management server computer account i have not edited the spn's manually is this alright? i do not see any errors in event log whenever the services are restarted...kindly validate

  • Anonymous
    February 17, 2013
    I have a small confusion. Is SPN registration to done at SCOM management server or domain controller?

  • Anonymous
    May 03, 2013
    Anil - SPN's are registered in AD, so i doesn't matter where you do it from, so long as the account you're using has Domain Admin privileges. The SPN for the MSOMHSvc entry should point to your management server. (e.g.  MSOMHSvc/ManagementServerName)

  • Anonymous
    October 29, 2013
    Surprised this was not fixed in 2012 R2...

  • Anonymous
    December 02, 2013
    The comment has been removed

  • Anonymous
    December 15, 2013
    I dont understand why you couldn't just put the correct spn commands that I need to add my domain account spns, That would have been much easier since anytime I use the domain account setspn -L (domainuseraccount) I get no spns. I will look elsewhere for this info.

  • Anonymous
    March 19, 2014
    setspm -L fails for our 2012 servers also. When I ran setspn -l SPN MSOMHSvc where missing. I simply elevated

    On boot SCOM console complained that the svc account/SPNs are not configured. To resolve I simply temporarily raised the svcDAS account up to Domain Admin, rebooted both MS machines, removed Domain Admin privileges and checked for the presence of MSOMHSvc using setspn -l both had been created correctly and no more errors in console at boot.

  • Anonymous
    March 19, 2014
    Hi Kevin, thanks for the reply. What are the consequences - do I need to remove these incorrect SPNs? Or can they be left without impact? I'm not sure why but I didn't spot your advice from: 'Now, how do we add the SPN’s in the right place?....' and your following guidance :-(

    I assume I still need to follow this to configure the SPNs and link them to the domain account?

    I've also spotted why setspn -l kept failing for me, I copied/pasted the command from above and the format of the minus/dash (-) symbol must get changed. Typing the command in manually resolved!

    I appreciate your help and your Blog has been absolutely essential in assisting with our deployment. Thank you.

  • Anonymous
    March 19, 2014
    The comment has been removed

  • Anonymous
    May 08, 2014
    A customer has 3 management servers, SCOM01 SCOM02 and SCOM03. You create the 6 SPN's for the 3 servers. You then run SETSPN -X and it comes back with duplicate SPN's for the MOMDAS account. This would show up on an AD Audit. Is this expected behavior?

  • Anonymous
    June 13, 2014
    Pingback from SCOM 2012: error "Data Access Service SPN Not Registered" | Fair Technologies

  • Anonymous
    September 02, 2014
    Hi Kevin,

    I am troubleshooting a gateway server connectivity problem, the gateway server shows as not monitored under the management servers, when the monitoring service is restarted on the gateway server event ids 20057 21001 and 20071 are showing in the operations manager event log. I ran through these steps to verify the the single managment server and everything checked out ok, the gateway server is in a seperate non-trusted domain what should I see for the spn configuration on the gateway server?

  • Anonymous
    December 03, 2014
    Hi Kevin

    I have SCOM 2102 r2 and did not get this error with UR3. Since upgrading to UR4 I am now seeing this "bug"

    Please can you if this bug still exist?

    Thanks

    John.

  • Anonymous
    February 19, 2015
    When changing these SPN's is there a service outage associated when writing them to the domain account? We have an environment where they were written to the computer account and now want to follow this procedure to write them to the domain account.

    Thanks!

  • Anonymous
    March 01, 2015
    Hi All

    I don't get it. When I run: setspn -L RITSCMEOMDAS

    The output is:-

    Registered ServicePrincipalNames for CN=OMDAS,OU=Service Accounts,OU=CME,DC=RITSCME,DC=local:



    So when I run: setspn -S MSOMSdkSvc/RITSCME-SCOM-01 RITSCMEOMDAS

    The output is:-

    Checking domain DC=RITSCME,DC=local
    CN=RITSCME-SCOM-01,OU=Servers,OU=CME,DC=RITSCME,DC=local
    MSOMSdkSvc/RITSCME-SCOM-01
    MSOMSdkSvc/RITSCME-SCOM-01.RITSCME.local
    SMTPSVC/RITSCME-SCOM-01
    SMTPSVC/RITSCME-SCOM-01.RITSCME.local
    MSOMHSvc/RITSCME-SCOM-01
    MSOMHSvc/RITSCME-SCOM-01.RITSCME.local
    TERMSRV/RITSCME-SCOM-01
    TERMSRV/RITSCME-SCOM-01.RITSCME.local
    WSMAN/RITSCME-SCOM-01
    WSMAN/RITSCME-SCOM-01.RITSCME.local
    RestrictedKrbHost/RITSCME-SCOM-01
    HOST/RITSCME-SCOM-01
    RestrictedKrbHost/RITSCME-SCOM-01.RITSCME.local
    HOST/RITSCME-SCOM-01.RITSCME.local

    Duplicate SPN found, aborting operation!


    So the SPN is set on my SCOM Computer AD Object name - but not on my Domain Data Access (OMDAS) account. Is this correct or should the SPN be on BOTH the computer AND account objects?
    thanks

  • Anonymous
    March 18, 2015
    Can and should an override be placed computer SPN accounts, it is my understanding that once this is done, no issues with SPN will be alerted. However once the user account has permission for SPN registration it should be an issue.

  • Anonymous
    March 18, 2015
    Yes, SPN permissions are set for the scomsvc service account, that is fine. The issue is the alerts are being triggered as you explained due to the computer account not having SPN rights. The question is - Do we override the alert? Thanks

  • Anonymous
    March 26, 2015
    A bit related to this. Why would you not use local system for SDK/Config? I can't seem to find why i need to run the SDK with another user then local system. I think i remember it's best practice to do when SQL isn't installed on the same server as the management server (which is basically always). But the official documentation clearly state it can be a domain account or local system and don't make any distinction in how the mg setup is.https://technet.microsoft.com/en-us/library/hh212808.aspx. You mention in the quickstart guide to use a domain account as well. Could you clarify this a bit more?

  • Anonymous
    October 20, 2015
    thank you.it worked for me.I have two SCOM servers so I Added four SPN' and walaaa the management console loaded succesfully.

  • Anonymous
    November 04, 2015
    The comment has been removed

  • Anonymous
    November 17, 2015
    Hi Kevin,
    Could you please suggest a solution for below issue. I am not able to connect to MS while installing reporter server. Though I have configured SPN for data access account as per your blog.
    https://social.technet.microsoft.com/Forums/systemcenter/en-US/9d01dba7-e07f-43fc-a787-9768f7762777/spn-not-registered?forum=operationsmanagerdeployment

    Thanks in advance

  • Anonymous
    May 23, 2016
    Hi KevinPlease advise how to deal with duplicate SPNs. (SCOM 2012 R2 on Windows 2012 R2, single management server and single management group).

    • Anonymous
      May 23, 2016
      If you have supplicate SPN's - simply delete the wrong ones.

  • Anonymous
    June 14, 2016
    On my system I noticed that the management server has the form MOMSdkSvc/SVPW-SC-OMMS1 and the account has the form MSOMSdkSvc/SVPW-SC-OMMS1, not the additional 'S' in the account SPN. Whats up with that? Everything has been working normally this way for years.

  • Anonymous
    September 09, 2016
    Hi Kevin,We have run SCOM 2012 R2 successfully for years now, but today, our two gateway servers started throwing errors saying they can't communicate with our management server due to mutual authentication issues, and to verify the SPN's are correct. According to everything in your post above, it's all correct. Both of our gateway servers show greyed out and are reporting all the servers they manage as grey as well. I know this article is from 5 years ago, but it seems like interesting timing that I noticed you responding to people today, the day we started having issues, with some answers, so I figured I'd give it a shot and ask. Has something changed in configurations that we may have to do differently? I'm stumped here :(

  • Anonymous
    September 09, 2016
    Actually, ignore the part in my comment about you responding today. For some reason the top 10 comments below all show the time the page was displayed instead of the time they happened...

    • Anonymous
      September 09, 2016
      You were right - I was responding today - but yes - our post times are always "now" for some silly reason.On your issue - normally GW's dont care about SPN's - because GW's are in a remote forest and use certs.My guess is your certs expired or something changed in your trusted CA config, and this is why SCOM tried to use Kerberos which needs SPN's. Or - if you never used certs - then this is a remote trusted forest that has a forest level trust that supports kerberos - and something is wrong with the trust.

  • Anonymous
    October 10, 2016
    Low and behold -- the alert bug still exists in SCOM 2016 RTM. I'm shocked.

    • Anonymous
      October 10, 2016
      I'm not. :-)

  • Anonymous
    December 05, 2016
    fyi, we have installed scom2016 ur1 today (fresh, no update), and it has the same issue.

    • Anonymous
      December 05, 2016
      Yep. I have no idea why they don't fix this. It has been a bug since SCOM shipped in 2007. The alert should be disabled because it does not work.

  • Anonymous
    February 09, 2017
    Afternoon, so now I am confused:so in the case of a SQL server, an error I see currently shows:In Health Explorer under column Operational State shows SPN IncorrectIn Context field at bottom:HasIssue: TrueMissingSPNList: MSSQLSvc/SQL2012Servername:portWhen I attempt to add this to the SPN attribute for the server object in AD, I get an error that basically tells me I cannot have a duplicate SPN in AD.AD servers are 2012.Would appreciate some clarification if at all possible...Thank you,Tony

    • Anonymous
      February 09, 2017
      A SQL SPN is different than what this blog post is about. This blog post is about SCOM special SPN's.SQL SPN's are very standardized for SQL based kerberos authentication. That error you are referring to is from the SQL management pack. You'd need to address that with your SQL team. Not all customers use Kerberos auth for SQL, so many customers just disable that monitor in the SQL MP. If you get an error about dupe SPN - that means you already have an SPN created in AD. It is either wrong, or the management pack monitor is wrong. Don't know which without understanding your design.... something best left to the SQL administrators.

  • Anonymous
    March 02, 2017
    The comment has been removed

  • Anonymous
    June 27, 2017
    Hi Kevin,It looks this is not even fixed/changed in SCOM 2016. So you should update the article with this remains too in SCOM 2016.Cheers

  • Anonymous
    September 07, 2017
    Is this important even? I have never registered the spn's (in serveral different domains) and SCOM seems to operate just fine.That the below error is not fixed in SCOM 2016 on Windows2016/SQL2016 seems to indicate that it is not important.If the SPN's are NOT registered, what harm does this do to SCOM?......Just asking. The System Center Data Access service failed to register an SPN. A domain admin needs to add MSOMSdkSvc/SCOM03 and MSOMSdkSvc/SCOM03.opsmgr.net to the servicePrincipalName of CN=SCOM03,CN=Computers,DC=opsmgr,DC=net

    • Anonymous
      September 08, 2017
      Not really.First - the alert doesn't work. It never has worked and never has been addressed. It should always be disabled.Second - how important are SPN's? They are critical where Kerberos authentication is a requirement, or when authentications occur across multiple hops, like when a web console is hosted on a non-management server (not having a local SDK service) but we want to use single sign-on windows authentication. When using forms based auth, this becomes far less of a concern.

  • Anonymous
    December 12, 2017
    I currently have an issue with my Gateway server not communicating with the Operations Management Console. After digging into countless articles I run into the possibility of duplicate SPNs. I hoping y'all could assist.Before I went any further, I wanted to verify that I am on the right track. Listed below are the results of running command: ldifde -f domain.txt. I scrolled through the text file I find this entry.servicePrincipalName: MSOMHSvc/SYSOPMGRservicePrincipalName: MSOMHSvc/SysOpMgr.domain.localservicePrincipalName: MSOMSdkSvc/SYSOPMGRservicePrincipalName: MSOMSdkSvc/SysOpMgr.domain.localIf I am correct and these are duplicate SPNs, I've read that I'm suppose to search for the account in ADSI Edit and under Properties\servicePrincipleName and delete the duplicate entries.Can someone verify that these are in fact duplicates and that I am of the correct path?

    • Anonymous
      December 14, 2017
      Those are not duplicate SPN's. Those are the Healthservice SPN and the SDK SPN. There is no duplicate there.Duplicate SPN's occur when the SAME SPN is set on two different OBJECTS.For instance, if your SDK SPN was set on the management server computer account, AND it was set on the domain service account that your DAS/SDK service runs under. That would be a duplicate. In general - you should not have the SDK SPN set to your management server computer account, unless you are using Local System for your SDK account, which I do not recommend. What happens, is that customers often do this, then realize their mistake, and change or reinstall.... however, the SPN was already set, and trying to set the SPN manually on the domain account at this point produces a duplicate. SETSPN has been updated now to check for duplicates before allowing a new one to be set.
      • Anonymous
        December 14, 2017
        OK thanks Kevin. I think my next step is to look into the certificates. Should the certificate numbers from the Operations Server and the Gateway Server match for communication?

  • Anonymous
    December 20, 2017
    The comment has been removed