Share via

SCOM is trying to connect to SQL on a DB server using the SCOM Action Account

Fadil Ck 381 Reputation points
2022-08-31T05:35:49.363+00:00

Hi All,

In one of our sql agent server SCOM is trying to connect SQL using SCOM Action Account instead of default SQL Run as account. Is this a normal thing or any specific reason?

Looking forward to hear from you.

Thanks in advance

Regards
Fadil CK

Operations Manager
Operations Manager
A family of System Center products that provide infrastructure monitoring, help ensure the predictable performance and availability of vital applications, and offer comprehensive monitoring for datacenters and cloud, both private and public.
1,419 questions
0 comments
Accepted answer
  1. SChalakov 10,271 Reputation points MVP
    2022-08-31T08:54:33.023+00:00

    Hi Fadil CK (@Fadil Ck ),

    so the cause is clear - The agent is running under Local System, but Local System has no SQL permissions by default (I think since SQL 2012 if I am not mistaken).
    So, the solution here is: distribute your SQL Monitoring account to the respective agent health service.

    Now to your question: "SQL run as account not distributed to this agent. can we choose the Less secure option, so that it can distribute to all sql servers? any major impact if we give this option?"
    Yes, you can chose the "less secure" option and "Yes" there will be some impact idf you do so - all the servers, which do not have this account (cannot leverage it) will start generating alerts, beause they are getting the account. So, you will need to do some grouping and overriding if you chose "Less Secure".

    There is one more thing, it is described in the office documentation here:

    Comparing more secure and less secure distribution
    https://learn.microsoft.com/en-us/system-center/scom/manage-security-dist-target-runas-profiles?view=sc-om-2022#comparing-more-secure-and-less-secure-distribution

    If Operations Manager automatically distributed the Runs As account according to discovery a security risk would be introduced into your environment as illustrated in the following example. This is why an automatic distribution option was not included in Operations Manager.

    and the risk is (again from the same article):

    For example, Operations Manager identifies a computer as hosting SQL Server 2014 based on the presence of a registry key. It is possible to create that same registry key on a computer that is not actually running an instance of SQL Server 2014. If Operations Manager were to automatically distribute the credentials to all agent managed computers that have been identified as SQL Server 2014 computers, then the credentials would be sent to the imposter SQL Server and they would be available to someone with administrator rights on that server.

    Last, but not least, many security auditors are labeling this also as a Security Risk:

    Manually configured SCOM Run As accounts must be set to More Secure distribution.
    https://www.stigviewer.com/stig/microsoft_scom/2021-03-15/finding/V-237424

    So, my recommendation would be to chose "More Secure" and distribute the account to the systems that need it. But if you decide to chose "Less Secure" you will also solve the original problem of this post.

    A small tip: You can also go the other way - monitorwithout service accounts. This is something i do in most oof the environments. This is very easily done with the help of Kevin Holmans MP:

    SQL MP Run As Accounts – NO LONGER REQUIRED
    https://kevinholman.com/2016/08/25/sql-mp-run-as-accounts-no-longer-required/

    Take five minutes to read it and then you can deciode if this somethng for you or not.

    I hope I could be of help!

    ----------

    (If the reply was helpful please don't forget to upvote and/or accept as answer, thank you)
    Regards
    Stoyan Chalakov

3 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Fadil Ck 381 Reputation points
    2022-09-16T11:05:02.717+00:00

    Hi Stoyan,

    We have resolved the issue.

    When we distributed the SQL Run as account and added the affected server to More secure, we received the below alert on the agent.

    "Run as account does not have requested logon type".

    We then removed from the distribution and alert got closed.

    The main issue was the SCOM agent action account accessing SQL, which was not alerted in SCOM, but generated from other SQL Monitoring Tool "Red-gate" which also was setup in our environment. The alert was generating every 4 hours in the Tool.

    We finally found out that Event ID: 4221 generated in the management server which is also generating every 4 hrs, in the event id it was clear that the one of the management pack was accessing the SQL of the affected server using Agent Action account.

    Description:
    Management Group: "xxxx"
    Module: Microsoft.SQLServer.Replication.Core.Module.Discovery.Discoveries.ReplicationDBHealthDiscovery
    Version: 7.0.28.0

    The monitors of this MP was only detecting the affected server, we have disabled the MP to the affected server, thereby events and the alerts in Red-gate stopped triggering.241827-4221-eid.png

    Regards
    Fadil CK

    1 person found this answer helpful.
  2. SChalakov 10,271 Reputation points MVP
    2022-08-31T06:56:58.057+00:00

    Hi @Fadil Ck ,

    I find that pretty odd indeed. In theory if a SQL Run As Account has not been assigned to the agent doing SQL monitoring, the agent wiill use the default Action Account (usually "NT Authority\SYSTEM", but not necessarily) to run the workflows (discoveries, monitors, rule, etc.).

    Can you please check if the SQL Run As Account that you are using is distributed to this agent? (Accountss -> Account Properties -> Distribution)
    What account is the agent operating under? Is it Local System or a dedicated Agent Action Account?
    Can you please filter the errors and warnings from the event log of the agent and check whether there is anything strange there?
    can you please also go to "Administraion", then to "Profiles" and check the Defualt Acction Account list there, find the agent in questions and check what account is running under?

    Hope somewhere on the way you will get a clearer picture on what is going on.

    ----------

    (If the reply was helpful please don't forget to upvote and/or accept as answer, thank you)
    Regards
    Stoyan Chalakov

  3. SChalakov 10,271 Reputation points MVP
    2022-09-01T07:25:42.853+00:00

    Hi Fadil,

    this is exactly the alert I referred to... This alert is logged when an account is distributed in the less secure way and also if the account is configured within a profile, that is targeted to systems, which do not have the account.
    So, in your case:

    • Pease make sure your SQL account is distributed only to the SQL Servers, that have a matching login (More secure).
      -Go over all your SQL related Profiles and make sure that every profiles targets either a group or a class (the best way would be to target groups with SQL computers).
      If the profile targets a group for example, the memberss of which do not have the SQL account configured on the SQL instance, then thosse system will generate this exact alert.

    I was able to find the article, which is great example of targeting and is about the SQL MP. Please read the whole article and you will understand exactly what happens:

    Configuring Run As Accounts and Profiles in OpsMgr – A SQL Management Pack Example
    https://kevinholman.com/2010/09/08/configuring-run-as-accounts-and-profiles-in-opsmgr-a-sql-management-pack-example/

    Hope this was helpful.

    ----------

    (If the reply was helpful please don't forget to upvote and/or accept as answer, thank you)
    Regards
    Stoyan Chalakov