Blog

Cleaning up (b)admin accounts in ConfigMgr

Recently, I overheard a conversation between IT staff members at one of my customers…

One colleague to another:

“… maybe we should reboot those servers first, because there might still be processes running as the badmin account that we renamed.”

Me, with sparked interest since I heard the badmin account referenced:

“Oh, good to know you renamed that account. You do know that account is used in your SCCM environment, don’t you?”

Customer, thinking it, but not saying it:

“I didn’t think of that. But I haven’t noticed all hell breaking loose on us so we’re good. I’ll just nod yes in a reassuring way…”

If by now you’re wondering, the term badmin does not stand for Bachelor of Administration. I found a few passable but inappropriate definitions on the Urban Dictionary, which I’ll leave entirely up to you to have a look at. But what I refer to as a badmin account, is that one user account that has god power on Active Directory, including Enterprise admin rights of course, local admin on every Windows server and workstation, your Exchange server AND the ConfigMgr site. It’s the bad admin account. It’s that shared account that system administrators use for anything and everything. Not their fault per se, they’ve probably been told to use it because it’s the path of least resistance.

Well, at least this customer is mitigating that issue by creating named admin accounts and MSAs for services. They just missed the fact that the badmin account is in use by a whole heap of services. Amongst which, in ConfigMgr, the Client Push Installation account and the Site System Installation account. So let’s fix that. Other accounts had already been configured for the same purposes so we’re removing the account from the ConfigMgr environment altogether.

First off, it’s easy to find out what accounts are in use throughout the ConfigMgr environment. In the Console’s Administration pane, under the Security node, have a look at the Accounts list. In our case, the account we want to remove

Removing the account as a Client Push installation account is easily done through the Site properties. Open up the Client Push Installation Properties from the Action Ribbon, select the badmin account, remove it from this list and hit OK. Make sure there remains at least one other account with appropriate admin rights for Client Push to work! If you don’t specify one, the site system computer account will be tried to push the client to machines. See here for full instructions: https://docs.microsoft.com/en-us/sccm/core/clients/deploy/deploy-clients-to-windows-computers#configure-the-site-to-automatically-use-client-push-for-discovered-computers

Now for the Site System Installation Account. Any time we add or remove a role to an existing Site System, or when installing a new Site System, this account is used to authenticate to the remote machine and change its configuration. If you only have 2 or 3 site system in your ConfigMgr hierarchy, it would take only a minute to open up the properties for each of them and remove or replace the account.

At this particular customer though, there’s 20 site systems. I do not consider myself a bad admin, but I certainly am a lazy admin! So I use PowerShell to automate this repetitive task.

The ConfigMgr PowerShell cmdlet we’ll be using today is Set-CMSiteSystemServer. The parameters we need today are -SiteSystemServerName and -AccountName.

The documentation for the latter lacks a good description in my opinion. It should read more like: Specifies the account used as Site System Installation Account, other than the site server’s computer account. It should then reference the parameter -UseSiteServerAccount and the documentation for the Site System Installation account.

To set the site installation account for one server, we use the following command.

Set-CMSiteSystemServer -SiteSystemServerName <fqdn for server> -AccountName <SAMAccountName>

Example:

Set-CMSiteSystemServer -SiteSystemServerName “Server2.contoso.com” -AccountName “contoso\administrator”

To do this for all site system servers, use

Get-CMSiteSystemServer | Set-CMSiteSystemServer -AccountName “contoso\administrator”

In our case, only some servers had the badmin account set as installation account. So we first need to apply a filter to only target those servers configured with the account. Guess what. There’s no parameter to the Get-CMSiteSystemServer command that allows us to filter the results. Instead, the Get-CMSiteSystemServer returns an IResultObject with a props attribute that contains the information we’re looking for.

So if the UseMachineAccount property has a value of 0 then the UserName property contains the account name under Value2. Knowing this, we can construct our filter.

And finally, we can configure these site systems to use a different account.

Alternatively, configure the servers to use the site server’s computer account.

You should now have removed all reference to the badmin account from your ConfigMgr hierarchy. You may now delete the account from Administration > Security > Accounts

Final thought

This article does not cover the possible use of the badmin account in Task Sequences, applications or other entities in your ConfigMgr environment. These may fail following a change to the account. Listing account references and dealing with them, would require parsing the XML data behind these objects. If there’s enough feedback on the matter, I’ll write another blog article on that.

That’s it for now. Thanks for reading.

Merlijn