SCOM Alert: MSSQL 2014: SQL Server cannot authenticate using Kerberos

  • iLearnSQL

    Say Hey Kid

    Points: 675

    Comments posted to this topic are about the item SCOM Alert: MSSQL 2014: SQL Server cannot authenticate using Kerberos

  • OSpi


    Points: 2

    Could you please start this with a brief explanation of what SCOM is?

    This could help... at least me!

  • Mark Dalley


    Points: 2697

    I had the same question, but found the following :

    It is a bit sales-y, but has enough technical detail to serve as a starting point.

    Disclosure: I have no connection, commercial or otherwise, with SquaredUp.


  • adelia


    Points: 7

    I believe that SCOM stand for System Center Operation Manager, a Microsoft centralized operation and administration suite.

    If it is the case, why tend to be bloated by our SCOM, misconfigured with a lot (lot) of false alarms due to just thrown in the default templates for SQL Server. The second parragraf made a lot of sense to me (check if it is something wrong with SCOM, no with the alarm)







  • Thomas Franz

    Hall of Fame

    Points: 3715

    at you can download the Kerberos Configuration Manager for SQL Server. It helped me a lot with all this SPN stuff, since it finds out by itself, which entries has to added and which should be removed.

    BTW: to run the SPN commands you'll need to have some domain admin permissions. If you don't have them (which would be a good sign, except you are working for a very small shop) you can either give the tool to your co-workers or just copy out the necessary commands.

    • This reply was modified 1 month, 1 week ago by  Thomas Franz.
    • This reply was modified 1 month, 1 week ago by  Thomas Franz.

    God is real, unless declared integer.

  • GulaschBaronen

    SSC Rookie

    Points: 29


    [NT AUTHORITY\SYSTEM] should not be sysadmin. You can use a specific account for the SCOM healtservice with just the permissions needed for the specific SCOM managementpack for SQLServer.

    There should be a scripted action prepared for it that can be run from inside the SCOM console.

    The SCOM team will need your help as they need an user with sysadmin permissions to execute the action that creates the lovpriv account.


  • Rich Weissler

    Hall of Fame

    Points: 3286

    You'll want to go thru the SCOM Management Pack for SQL guide and probably configure a 'run as' profile.  (And you can configure that profile to only be distributed to your SQL servers.)

  • chuck.hamilton

    Default port

    Points: 1408

    So why did 90% of the SPNs need to be re-registered? Do you have a network with a lot of domain controllers? If so we've seen a problem where it's caused by SQL automatically deleting the SPN when it shuts down and recreates it when it starts up. That causes a problem if not all the domain controllers process those requests in the right order. Sometimes they get the create SPN command first  (which obviously fails), followed by the delete which leaves you with no SPN!

    The solution is to not grant the SQL Service account permission in active directory to create/drop SPNs. When you install SQL just manually register them once. Problem solved.

  • Andy sql

    SSCrazy Eights

    Points: 9406

    As already mentioned, SCOM can be configured to use a service account to connect to MSSQL instances; not a good idea to use the (default) SYSTEM account.

    In SCOM, you need to configure the Agent, the Subscriber, the Subscription, the Authoring Group, and finally the service account.

    Then, in each MSSQL instance you want SCOM to monitor, create the Login, and grant the required permissions (such as VIEW SERVER STATE in [master] database).

    The entire setup can be scripted, and is part of our installation process. Let's stop using the local SYSTEM account, please!

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic. Login to reply