A few weeks ago, I explained how to use Configuration Manager to make sure LAPS actually changed the local administrator account password. However, to improve security, it is even better to disable the built-in local administrator account and create another one you then can manage with LAPS. The reason is that the built-in local administrator account has a well-known SID, and it is therefore easy to find out the name if you only renamed it.
Most of us use Group Policy to disable the admin account. However, this way we never get any information back to a central location or log if the action applied the policy successfully or not.
Verifying whether the administrator account is disabled ^
With all the compliance demands we have today and the fact that security is more important than ever, Configuration Manager, CIs, and baselines will play a more and more important role. They can make sure the configurations we think we have on our clients out there actually are set as we think they are. We can also use Event Forwarding to verify we've applied Group Policy settings.
To monitor the state of the local administrator account with SCCM, we will be using a simple CI. This time, I will not list all the steps required to create a CI because I already covered the details in my previous blog post.
To check whether the local administrator account is disabled, you can use the PowerShell commands below. Because someone might have renamed the account, we use the well-known SID to read the account's name.
$USer = Get-WmiObject -Class Win32_UserAccount -Filter "LocalAccount='True' And Sid like '%‑500'" Return $User.Disabled
The script will return True or False, and that is what we then measure in the CI.
Disabling the administrator account ^
This time we add a remediation script as well, so if the administrator account is enabled, we simply disable it. The steps to implement it are the same as for the LAPS monitoring script, but we select Add script under Remediation script this time.
There we add the following script that will simply disable the built-in administrator account if it is enabled.
$USer = Get-WmiObject -Class Win32_UserAccount -Filter "LocalAccount='True' And Sid like '%‑500'" $User.disabled=$true;$User.put()
After that, we add the following to the compliance rule under the Compliance rule tab to run the remediation script.
To make Configuration Manager remediate the setting, we also need to add to the baseline used to deploy the CI that it should execute remediation as well. To create a new baseline, select Create Configuration Baseline in the Configuration Manager console. Give it a name and select Add Configuration Items.
We then select the CI we created and add it to the baseline.
Then we click OK twice. The baseline is now ready to deploy. When deploying the baseline, we have to select the Remediate noncompliant rule when supported option and then choose a collection to deploy the baseline to. I also change the schedule to run the baseline once a day. The default setting is once a week, and that is not frequent enough.
Viewing the results on the client ^
When we look at a client in the Configuration Manager control panel applet, we can run baselines and see the results as well. We need to run the Configuration Manager control panel applet with elevated privileges to be able to view a report of a configuration baseline result.
In this example report, we enabled the local administrator account, and the SCCM client ran the remediation script to change the value:
We can see that the script returned "False" in the Previous Value field, but after execution of the remediation script, the Remediated Value field is set to "True."
Subscribe to 4sysops newsletter!
I believe CIs and baselines are the most underestimated and underused features in Configuration Manager. Give them a try!