Quick Download: https://github.com/thekevinholman/LogOnAsAServiceRunAsHelperMP
One of the changes in SCOM 2019 is that RunAs accounts now require Log on as a service, instead of Log on locally, which I previously discussed here: https://kevinholman.com/2019/03/14/security-changes-in-scom-2019-log-on-as-a-service/
If you deploy SCOM 2019 agents, and use RunAs accounts, you might see these events:
Log Name: Operations Manager
Source: HealthService
Event ID: 7002
Description:
The Health Service could not log on the RunAs account OPSMGR\testrunas for management group SC2019 because it has not been granted the “Log on as a service” right.
That would generate an alert
Normally, you’d have to manually add this user right on each affected machine, or use GPO. The challenge with Group Policy, is that could wipe out any previous customizations you or other software applications have made here.
I created a management pack which will help automate this change. The MP will watch for the events about RunAs account logon failures, and if they contain an error about Log on As a Service, a script will run, and add the account to enable that user right.
A single alert will be generated each time the event is detected, and the script runs attempting to set this policy:
An Event 7002 was detected with a RunAs account missing the Log on as a service user right on this agent.
A modification attempt was made for Log on as a service.
Result: User (OPSMGR\testrunas) was granted the Log on as a service privilege.
UserName: OPSMGR\testrunasUser right properties before modification: NT SERVICE\MSSQLSERVER S-1-5-80-3880718306-3832830129-1677859214-2598158968-1052248003
NT SERVICE\SQLSERVERAGENT S-1-5-80-344959196-2060754871-2302487193-2804545603-1466107430
NT SERVICE\MSSQLFDLauncher S-1-5-80-3263513310-3392720605-1798839546-683002060-3227631582
NT SERVICE\SQLTELEMETRY S-1-5-80-2652535364-2169709536-2857650723-2622804123-1107741775
NT SERVICE\ALL SERVICES S-1-5-80-0
OPSMGR\om_dwr S-1-5-21-3626055071-1639654894-2113106914-1260
OPSMGR\sqlsvc S-1-5-21-3626055071-1639654894-2113106914-1110
SCSQL1\SQLServer2005SQLBrowserUser$SCSQL1 S-1-5-21-147125434-116438822-401272363-1000
User right properties after modification: NT SERVICE\MSSQLSERVER S-1-5-80-3880718306-3832830129-1677859214-2598158968-1052248003
NT SERVICE\SQLSERVERAGENT S-1-5-80-344959196-2060754871-2302487193-2804545603-1466107430
NT SERVICE\MSSQLFDLauncher S-1-5-80-3263513310-3392720605-1798839546-683002060-3227631582
NT SERVICE\SQLTELEMETRY S-1-5-80-2652535364-2169709536-2857650723-2622804123-1107741775
NT SERVICE\ALL SERVICES S-1-5-80-0
OPSMGR\testrunas S-1-5-21-3626055071-1639654894-2113106914-1281
OPSMGR\om_dwr S-1-5-21-3626055071-1639654894-2113106914-1260
OPSMGR\sqlsvc S-1-5-21-3626055071-1639654894-2113106914-1110
SCSQL1\SQLServer2005SQLBrowserUser$SCSQL1 S-1-5-21-147125434-116438822-401272363-1000Event Description that triggered this response:
The Health Service could not log on the RunAs account OPSMGR\testrunas for management group SC2019 because it has not been granted the “Log on as a service” right.
Would it be possible to adjust this with an override to allow specifying a group/service account to add rather than just adding the service account it is erroring on?
I cannot really just add a group…. but that is something you could add to this example.
What’s the reasoning? You want to add a group every time there is an error, instead of an individual account? Or you want to add a specific group, anytime the account is specific? I’d recommend you just customize yours in the script with that logic.
The reasoning is more that we have a group that we want on all servers to have log on as a service permissions (but for obvious reasons, don’t want to add to a GPO) and we add runas accounts to it as needed, so if the server is kicking back a runas account, it’s more that it needs to add that group than it needs that specific service account (and we prefer to use groups instead of individual service accounts). I have a script that I can run as needed when it pops up that a server doesn’t have the group, but doing it as a response to an alert automatically would be nice.
Then just go into the MP, in the script – and hard code the value for the account to add. It is normally passed in as a parameter to the script from the event, but you can change this easily in powershell with one line.
We have this use case too.
We need to be able to add our DOMAIN\DBA group to the Log on as a service right ONLY on SQL Servers, so that when new SQL Servers are added to SCOM, DBA’s can run the two SQLRunAs MP tasks:
– Enable HealthService SID and Restart Agent Task (I think this task runs without the Log on as a service right)
– Create HealthService Login as SysAdmin Task
We don’t want to add the individual DBA that runs the task to the Log on as a service right, as we prefer to have a consistent setup across the fleet (and don’t want dead SID’s etc. in there, should they leave the organisation).
We would like the ability to add the DOMAIN\DBA group, but only for SQL Servers and not all the other types of servers that we add. If we hard code the GROUP (if this is possible) then that would only work for the SQL Servers. Then we would need to think of the other server types that the DOMAIN\SCOM Admins manage (which is the rest, basically).
We would just change the script to DOMAIN\SCOM Admins instead, however we are not SQL SYSADMINs, so we wouldn’t be able to run the Create HealthService Login as SysAdmin Task.
It appears to be a catch 22 for us…but no doubt there is a solution to this!
Hey Kevin,
Great idea on this management pack!
Got an issue though, when it runs I get this error (username hidden due to security):
Result: Error attempting to grant the Log on as a service privilege to account: (####USERNAME#####).
Error is (Exception calling “AddPrivilege” with “2” argument(s): “Some or all identity references could not be translated.”).
Any ideas?
Thanks
Interesting. Can you run the script manually and does it work?
If you follow the events in the event log – can you tell which line is failing?
Was this issue in regards to adding the DBA group to only SQL Servers resolved?
Pingback:System Center Nisan 2019 Bülten – Sertaç Topal
On domain controllers, the MP reports an error with attempting to grant the Log on as a service right:
============================================
Result: Error attempting to grant the Log on as a service privilege to account: (<>).
Error is (Exception calling “Translate” with “1” argument(s): “Some or all identity references could not be translated.” Exception calling “Translate” with “1” argument(s): “Some or all identity references could not be translated.” Exception calling “Translate” with “1” argument(s): “Some or all identity references could not be translated.”).
UserName: <>
User right properties before modification: <>
User right properties after modification: <>
============================================
However, it is succeeding in adding that account.
Not sure if I tested on DC’s – I will and see if I can fix this.
Any idea why the MP is not triggering on the alerts ?
Event ID 7002 is present in the operationsmanager log, but nothing happens.
When adding the account manually and restart the agent the scom alert disappears.
This MP does not trigger ONLY on a 7002 event.
This MP triggers when
The target is an AGENT (not a MS or GW)
EventID = 7002
Event Source = HealthService
Param3 = The management Group name you have imported the MP into.
Param4 = “Log on as a service”
This script will log 7003 events in the OpsMgr event log on the agent, if it is triggered.
All criterias (log and parameters) are met and correct but no 7003 event.
We rebooted the agents and services and the event 7002 gets updated in the log every 5-15 minutes, but no 7003.
Another idea ?
Great work Kevin, this is working for the whole but I get this response for some of the results
___
Result: Error attempting to grant the Log on as a service privilege to account: (*****\*****).
Error is (Exception calling “Translate” with “1” argument(s): “Some or all identity references could not be translated.”).
___
Any ideas please?
We are also seeing this:
SCOM2019.RunAsHelper.7002EventScript.DS.ps1 :
Error attempting to grant the Log on as a service privilege to account: (Domain\username).
Error is (Exception calling “Translate” with “1” argument(s): “Some or all identity references could not be translated.” Exception calling “Translate” with “1” argument(s): “Some or all identity references could not be translated.”).
SCOM2019.RunAsHelper.7002EventScript.DS.ps1 :
Error attempting to enumerate accounts after modification.
Error is (Exception calling “Translate” with “1” argument(s): “Some or all identity references could not be translated.” Exception calling “Translate” with “1” argument(s): “Some or all identity references could not be translated.”)
Looks like it adds the account though.
Hi Kevin,
Question, does the MP start running the script straight away once its installed as long as it finds the event IDs (which it will as we have loads of them!). Or do you have to manually trigger it as a start (or can you pause or disable it before it runs)
We would like to test the script on a few PCs before distributing it on a network wide scale. We have a test system we can put the VM on and test the pack but if you could let us know that would be easier. As the pack doesn’t include the script separately we cannot test until we install the pack.
I am quite new to SCOM and this new 2019 feature has been a huge pain, some of our servers we cannot reboot so we are stuck with them not being monitored until we can get downtime (which will be difficult). I know there is a work-around but there is no point deploying that as we shouldn’t really be using work-arounds.
Not quite sure how everyone else is dealing with this issue, I imagine there are a few corporations that have servers they cannot just reboot…also we are having the same issue with the DC’s with regards to adding the service account to logon as a service. Even trying to add the service account manually (local gp) to the ‘Logon as a service’ doesn’t work, its greyed out. Similar to a few of our 2K8 servers too.
We cannot add it via GPO as we dont have the option setup (so it would overwrite all of the current configs for logon as a service)
Any help would be appreciated,
Regards,
Clare
Simply open the XML, edit the rule to enabled = false
Then you can override the rule for a handful of test systems to enabled = true
Hi CLare. I’m not sure why you need to reboot at all – it’s not a requirement for this Management Pack in regards to adding users to the Log on as a service right?
Restarting the Health Service is the only thing we have had to do to get this to work – as Patrik mentions below.
Hi Kevin,
thanks a lot for your extremly helpful “Helper”-MP.
On some of our nodes the configuration-scripts produces an error which is written in the alert description of the warning-alert. Excerpt:
[…]
A modification attempt was made for Log on as a service.
Result: Error attempting to enumerate existing accounts.
No modifications were made.
Error is (The variable ‘$lsa’ cannot be retrieved because it has not been set. Cannot find type [PS_LSA.LsaWrapper]: make sure the assembly containing this type is loaded. Cannot add type. There were compilation errors. c:\Windows\Temp\smqwsonl.0.cs(162) : Default parameter specifiers are not permitted
c:\Windows\Temp\smqwsonl.0.cs(161) :
c:\Windows\Temp\smqwsonl.0.cs(162) : >>> public string[] EnumerateAccountsWithUserRight(Rights privilege, bool resolveSid = true)
c:\Windows\Temp\smqwsonl.0.cs(163) : {
)
[…]
Probably some local prerequisites are missing? Can it be executed on Server 2008 or what is the minimum OS-version?
Is it possible to start the script manually for better debugging?
Best regards
Is there a restart of the Healthservice needed before it works ?
Because after the first error and the script running i can see the account in secpol.msc but i still get error for my runas account and when the second error triggers the rule for the second time i can’t see the account in the
“The account list before modification for Log on as a service right:”
After i restart of healthservice my runas account works.
I really don’t know – in my testing I did not see any case where the agent required a restart/reboot. These are standardized commands, nothing SCOM specific, so you should be able to test this manually and repro it on demand. This was published more of an example of how to do it.
I too noticed that I needed to restart the agent after the rule had run and successfully added the account to the machine’s Local policy.
Hi Kevin,
Any reason why you didn’t target the rule to Microsoft.SystemCenter.HealthService? So it would also work for Management Servers (could be useful for Web monitoring Runas accounts for example).
Thanks for the awesome work as always 🙂
Fear.
I was afraid to run it on a MS since a MS will often have so many accounts that it will attempt to use, such as user accounts when doing agent deployment, running tasks, etc. But it works exactly the same and there is nothing wrong with making that change.
We also had this issue, and now get alerts for Unable to Verify Run As Account. Anyone know what the resolution is for this?
Has this been tested with gMSAs? We’re getting ready to make the jump.
Did anyone try this with a gMSA or another service account with “non-interactive” access? What were the results?
Hello Kevin,
This MP worked a treat for us in our organisation. Instead of using our run-as SCOM account we hard coded an AD Group which has several SCOM accounts and we needed this to cover us. The only issue Im having is for “Non-Domain joined servers”. Does anyone know what to do in this case as these servers obviously cannot see AD?
Any help would be greatly appreciated.
I downloaded your Log in as a service mgmt pack and imported it into SCOM, but I am not sure what else I am supposed to do with it.
Well, were you having a problem trying to leverage a RunAs account in SCOM 2019 previously?
I am not able to install SCOM through the SCOM GUI only on our Domain Controllers. The Policy (set by another team) has the Local Security Policy Account (Log on as a Service) properties locked down . I do see our SCOM service account in there, but I have to check out another special DC Admin account from our pw vault in order to do anything on this server (is used to runn install) and this account has most admin rights but not full admin rights. Anyway, so I downlaoded your SCOM2019 Log On as a Service mgmt pack and then imported it into SCOM and then what? is it automatically is supposed to work?
I don’t think so. My solution is not designed as a circumvent to your policy. It simply detects when an account is restricted from being able to log on as a service, and responded by adding that account to the local security policy for Log On As a Service rights. If you have a policy locking that down, it would wipe out any changes made.
We are running SCOM 2019, although I am still using the 1807 GUI.
It fails no matter what method I try (Log on locally, Local System, Domain). It does show up in Pending Mgmt after it fails to Discover. It was giving me the option to approve or reject, which I tried all the methods (Log on locally, Local System, Domain) trying to get this to work, no go. However, now I only get a “reject” option in Pending Mgmt, approve is greyed out. I can’t get the GUI to work on our DCs, it works fine on all of our other servers. I’ve been manually installing SCOM on our DC’s because of this (since we upgraded to 2019).
Thank you Kevin, I was wondering how this mgmt pack would fix my issue when it can’t because of Policy.
Hi Kevin,
Log as service will work for Linux/Unix agents also ?
No. Log on as a service is unique to Windows OS. Unix/Linux agents do not require this and are not affected by it.
Hi. Log on as a Service is required only after upgrade agent to SCOM 2019 ? Or regardless of agent version important is what version is Management Server ?
Based on Agent version, for agents.
Thanks Kevin
Hello Kevin,
As usual, thank you so much for your excellent work. Could you please advise where would I be able to find the log you provided in the original post?
Morning sir, I have installed the MP and have followed the requirements for adding the AD account we use into “Log on as a Service” on our Domain Controllers. Everyday I get a warning in SCOM 2019 UR3 console:
Run As account failed verification.
The HealthService cannot verify the future validity of the RunAs account XXX-svc-xxxxx for Management Group SCOMP. The error is logon Failure: the user has not been granted the requested logon type at this computer.(1385L)
Also, I was looking at this this morning, my SCOM 2019 UR3 Console does not have the “Agents” listed under Operations Manager Products?
https://learn.microsoft.com/en-us/system-center/scom/enable-service-logon?view=sc-om-2019
Thanks as always,
Tony
That should have been “XXX\svc-xxxxx for Management Group SCOMP.”
Is there a new version of this MP for 2022, I’m getting runas alerts ever since my upgrade from 2019