MEM or SCCM: reset local admin passwords

Decorative title image of computers in a lab with pad lock icons on the screen

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 Microsoft Endpoint Manager (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 Microsoft Endpoint Manager (SCCM), allowing the script contents to be decrypted by anyone that can see the Package in Microsoft Endpoint Manager).

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 Microsoft Endpoint Manager or 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 from below) the Gist 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)

; Basic information
AppName = Computer Maintenance
AppVerName = Computer Maintenance 0.0.1
AppPublisher = Neil Sabol
AppVersion = 0.0.1
Compression = lzma
SolidCompression = yes
PrivilegesRequired = admin
; Choose a benign directory to "install" even though we are
; not really installing anything - this "installer" will
; just run 2 commands 
DefaultDirName = {win}\Temp
; Tidy up the name and location of the generated installer
; (current user's Desktop)
; Do not allow selection of an alternative install
; location and do not prompt for a Start menu location
; Do not create an uninstaller or add an entry to Apps
; (Programs and Features)
Uninstallable = no
CreateUninstallRegKey = no

; Reset the password administrator password with
; "net user ..."
Filename: "net.exe"; Parameters: "user administrator MyNewPassword2018"; Flags: shellexec waituntilterminated runhidden; StatusMsg: Performing maintenance
; Add a registry value that can be used in a detection
; rule (in SCCM) so the "install" status is traceable
Filename: "reg.exe"; Parameters: "add ""HKLM\SOFTWARE\Computer Maintenance"" /v ""Status"" /t REG_DWORD /d 201812 /f /REG:64"; Flags: shellexec waituntilterminated runhidden; StatusMsg: Capturing status

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 Microsoft Endpoint Manager or SCCM)

  1. 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)

  2. Copy the generated “installer” into your Microsoft Endpoint Manager (SCCM) content share

  3. Create a new Application in Microsoft Endpoint Manager (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 Content location and installation program in SCCM

    • Application Deployment Type Content -> Detection Rule: Detect and match a value for HKLM\Software\Computer Maintenance\Status Example detection rule, using value written to registry by password reset application

    • Application Deployment Type Content -> User Experience: Install for system, run without user logged in, and run hidden Example user experience settings for password reset application in SCCM

  4. Distribute the application to the appropriate Distribution Points

  5. Deploy the application to collections of computers where you want the administrator password reset

  6. 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 Microsoft Endpoint Manager (SCCM)

Example of deployment status for password reset application, courtesy of detection rule

Further Recommendations

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 Microsoft Endpoint Manager (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