In OpsMgr – deploying a SCOM agent to a DC often presents companies with a bit of a challenge. The reason is – in order to install software to a DC and manage it – we need rights on the DC to accomplish this. These rights are needed, anytime we are going to deploy an agent, hotfix an agent, or run a repair on a broken agent to keep the agent healthy.
When we push agents from the console, the default account used to perform the push is the Management Server Action Account. If this account does not have Domain Admin rights – the push will fail to a DC, with an Access Denied. We do allow the option to type in temporary (encrypted) credentials, which are used to deploy the agent, one time, and then are discarded. See the image below:
Here is a list of the most common options I have observed, in place at customer sites… and potential custom options that can be developed. I’d be interested in any community feedback on any options you are using, that I dont cover or haven’t seen before.
1. Grant the Management Server Action account Domain Admin or Builtin\Administrators.
a. Not recommended as a best practice, this gives rights to the MSAA that are not required for day to day activities.
b. Con – SCOM Admins now control a domain admin account.
2. Grant a SCOM Administrator a special domain account, for this purpose, that is a domain admin.
a. This allows us to track the actions of that SCOM admin, when he/she uses that special privileged account.
b. That SCOM admin will be able to do repairs, hotfixes, and deployments for DC’s.
c. Con – Domain Admin teams often wont delegate these rights as they are tightly controlled.
3. The SCOM admin team delegates console based agent management to a Domain Administrator for DC agent health.
a. The domain admin must become a SCOM Admin, and therefore could potentially hurt the SCOM environment.
b. Pro – the admins in charge of the DC’s now have full responsibility to keep the agents healthy.
c. Con – the Domain Admins might not understand components of SCOM, and create something that impacts the monitoring environment.
4. The SCOM admin team must partner with the Domain Admin team, and have the Domain Administrator type in his credentials any time the SCOM administrator needs to deploy/hotfix/repair an agent on a domain controller.
a. This is a bit more labor intensive… because the SCOM admin must wait for a domain admin to be available to work on DC agents, but tight security boundaries are maintained.
5. All DC based agents will be manually installed/updated/repaired.
a. This is very common, when the two teams do not trust each other. The Domain Admin team is now required to manually deploy agents to domain controllers, and keep them up to date, and healthy.
6. Use a software deployment tool already in place to deploy/update/repair agents.
a. If a software deployment tool is already in place on DC’s, like SMS/SCCM, you can create packages to deploy, hotfix, and repair agents, similar to your patching of the OS today.
7. Customized solution: Create a Run-As account that is a domain admin, one time, for use in agent deployment/repair.
a. This involves the domain admin typing in credentials ONCE, into a RUN-AS account, which is stored securely and encrypted in the SCOM database.
b. This run-as account can be associated with a run-as profile, which is used by a custom task, which will remotely deploy the agent to the domain controller. This task will execute under the security context of the privileged run-as account.
c. The benefit is that the domain admin gets to control the password for this account, the SCOM admin does not need to know the account credentials.
d. The downside, is that this run-as account could potentially be leveraged by some other workflow, if a SCOM admin intentionally misused it…. Similar to solution #2 above.
e. This is just an idea I had – curious if anyone has already developed a solution like this?
HI Kevin,
I work in an environment where they do not want the domain admin permissions granted to anyone and ideally do not want a scom agent on the DC . We found that if I run the DC Health service under local system the health service is granted essentially ‘domain admin’ rights ultimately meaning any scom admin can execute admin level commands on a domain controller (i.e. : create a local user and assign them to a certain group).
the alternatives which I have contemplated are a separate account with limited access to individual services and objects on the DC would require a ‘run as’ account creating which i’m sure you are aware could be exposed through powershell
how would you suggest I approach this situation ?
I have attempted to utilise log analytics for these purposes and although all of this good AD information exists within AD Connect Health there is currently no way to export or manipulate this information