In this post, I will outline yet another approach that can be used to reset local account passwords across a Windows environment that is managed with SCCM (or another device management tool that is capable of pushing and silently “installing” packages on managed computers - i.e. Microsoft Intune, PDQ Deploy).
Before I get into this, I want to mention that this approach is far from 100% secure; it relies primarily on “security by obscurity” which is not ideal. As with anything related to security, a proper balance for the organization must be achieved.
At the high end of the security spectrum are solutions like:
- Using Microsoft LAPS (Local Administrator Password Solution) - this is a great solution, but there is overhead which may or may not be worth the investment (depending on the security needs of your environment)
At the lower end of the spectrum are solutions like:
- Deploying a plain-text script to set passwords (where the password appears in clear text on the client computers where it is being reset)
I like to think that my solution lies somewhere in between (along with Felipe Binotto’s solution, which I am very fond of as well). The limitation of these middle tier solutions is that the password is just obfuscated in some way; in my case, in a compiled executable (viewable if decompiled on a client computer), and in Felipe’s case, with an encryption key (which must exist in clear text in SCCM, allowing the script contents to be decrypted by anyone that can see the Package in SCCM).
My approach requires using InnoSetup to build a compiled “installer” (exe file) that runs the net user … command to set the password on a local account.
In most cases, I am inclined to recommend Felipe’s approach (or a slight adaptation to it since SCCM now natively supports executing PowerShell scripts with parameters against computers and collections). But, I wanted to share another possibility in case it is a good fit for other use cases.
- InnoSetup downloaded and installed
- Download (or copy/paste) the Gist below into a “.iss” file and save it on the same computer where InnoSetup is installed
- Open the iss file with InnoSetup, make your changes (set your password in line 28, change the name in lines 3 4 and 16, change the registry key name/path in line 31), and compile an installer (Build –> Compile)
- Create an Application (and Deployment) in your device management tool of choice to run the “installer” silently on your managed devices
- Devices can be standalone, domain (ADDS) joined, or Azure AD joined
The code (InnoSetup installer script - Gist)
In my testing, once the installer is compiled, the password is not readily readable in clear text. For example, opening the installer EXE in a text editor does not reveal the password, nor does attempting to extract the installer EXE with 7-zip.
This said, if you know of a way to decompile the installer EXE and recover the password, I am very interested to hear about that process. I am certain it is possible but have admittedly not invested much time in exploring it.
The process (configuration and deployment with SCCM)
Download and install InnoSetup and use the sample ISS file to build an installer that resets the local administrator password upon execution (see Requirements above)
Copy the generated “installer” into your SCCM content share
Create a new Application in SCCM as follows
- Application Deployment Type Content -> Content Location: specify accordingly - path to Comp-Maint.exe in your content share
Application Deployment Type Content -> Installation program: Comp-Maint.exe /VERYSILENT
Application Deployment Type Content -> Detection Rule: Detect and match a value for HKLM\Software\Computer Maintenance\Status
Application Deployment Type Content -> User Experience: Install for system, run without user logged in, and run hidden
Distribute the application to the appropriate Distribution Points
Deploy the application to collections of computers where you want the administrator password reset
Monitor status - setting the registry key in the installer package and checking it with a detection rule allows you to see the progress/status in SCCM
Again, this solution is far from 100% secure but may be viable for your environment. To maintain the “security by obscurity” principle, I recommend considering the following:
- Ensure the proper security scopes are set on your Application in SCCM so other SCCM admins do not see the Application if they do not need to
- Name the Application and installer it contains non-descript; i.e. do not call it “Set Windows Admin Password.” Call it something generic like “Computer Maintenance” or “Quarterly Patch Installer” or “869sduy768sdfsdf976sdf” (random string)
- Change the registry key used in the example