- Remote help for Intune and Microsoft Endpoint Manager - Tue, Jan 25 2022
- Windows 10/11 Azure AD/Intune Enterprise subscription is not valid - Mon, Nov 8 2021
- Upgrade from Windows 10 to Windows 11 with Setupconfig.ini and Intune - Wed, Sep 22 2021
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!
Hello,
Thanks for this guide.
I’m having trouble with the compliance rule part. Config Mgr 1710. For the section “The value returned by the specified script, Equals, has a notification:
“Specify a valid integer”.
I’m not sure what I’m doing wrong. Any suggestions?
Wow, less than 5 minutes after posting, I found the cause. I had set the script data type to integer, not string….
Well, it doesn’t appear to be working after all. I just want to confirm, the script value is integer or string? If it is an integer, shouldn’t the compliance value be a numerical value, not a string (true)?
Hi,
The data type should be “boolean”, thanks for pointing out will update that screenshot.
Regards,
Jörgen
Great. Thanks for clearing that up.
In the report for my test device, the compliance rule still seems to have a problem. When viewing the report on the client:
Details > Non-Compliant Rules > Instance Data
I see:
Expression: Equals True
Current Value: NULL
Instance Source: (empty)
Rule Type: Value
Syntax errors were the cause. In this article, the minus symbol in the code ,”%-500″, is actually a special character. I retyped the code in the configuration item. Everything seems to be working OK now!