Tuesday, January 6, 2009

Script Code: Setting Admin Passwords

There are a great many ways to set/reset local Administrator account passwords on computers which are joined to a domain.  This article will cover just one of them: Using a startup script, but with a small twist.  I should take a moment to recommend Don Hite's blog for a huge collection of scripts to do just about anything.  I will try to not reinvent any wheels.  In any case, on to the chase...

Option 1 - A simple BAT file startup script

Create a .BAT file and post it into a shared folder on your network.  Grant access to the folder and share to allow the "Domain Computers" security group READ access.  Remove "Everyone" from the share permissions and add "Domain Admins" to have CHANGE permissions.  Leave the NTFS permissions at default (Administrators = Full Control, Users = Read, etc.)

The .BAT file will contain a simple one-line command:

    @echo off
    net user administrator newPassword

Replace "newPassword" with your actual (and hopefully *strong*) password.

Create a new (test) OU in Active Directory.  Now, create a new GPO and name it appropriately (e.g. "Local Admin Password") and edit it to specify the startup script using the appropriate UNC shared path.  Then link the GPO to the OU and drag a computer account over into the OU to use as a test.  Reboot the computer.  It may require a second reboot in some cases before the GPO takes effect.  Verify the new password by logging on or using a RUNAS command.

Now, the protection on the new password is only as good as the permissions you apply to the shared folder and NTFS permissions to the folder itself.  If you want to add another layer of protection...

Option 2 - Tokenized KixTart Script

Using the same folder and share as described above, but this time drop the Kix32.exe file into the folder.  I strongly recommend using the latest KixTart version available.  Then, in a different location, create a script named "SetAdminPwd.kix" with the following code:

    break ON
    shell "net user administrator newPassword"
    return

Remember to replace "newPassword" with your actual preferred (strong) password.  Save the .kix file.  Then open a CMD console and navigate to the folder where the .KIX file resides.  Run Kix32.exe with the /t option to pre-tokenize the script and create an encoded .KX output file.  The .KX file will execute the same way a .KIX file does, but the source will not be readable by anyone that opens it because it is encoded to protect it from such prying annoyances.  Another benefit is that pre-tokenized code is smaller and executes faster than raw source code.

    X:> \kix32.exe SetAdminPwd.kix /t

Replace with the appropriate path to the Kix32.exe file.  This should produce a new file named SetAdminPwd.kx in the same folder as the .kix file.  Copy the .kx file up to the shared folder where you placed Kix32.exe previously.  You should now have Kix32.exe and SetAdminPwd.kx in the shared folder.  Now, to wrap things up nicely, create a small .BAT file, named SetAdminPwd.bat, with the following code to call Kix32.exe and run the SetAdminPwd.kx script file:

    @echo off
    %0\..\kix32.exe SetAdminPwd.kx

Save the .BAT file and modify your GPO setting to invoke the SetAdminPwd.bat file.

Now, you have a script that sets the local Administrator account password for each computer which is controlled by the GPO by way of the OU link.  The script itself is unreadable by anyone that might gain access to it.  You can keep the .kix source file in a safer place and use it to update the password and create a new .kx file to upload when you need to modify the password again.

You can do just about anything within the scope of this if you want.  You can use other commands to do things you can't or won't do with GPO settings.  For example: set passwords, rename or disable local accounts, download or upload files, or whatever.

Caveats

What this won't do?  It won't manage workgroup computers unless you set a local policy on each one to invoke the script and you would have to adjust your permissions to suit.  It won't help with computers which are not connected to the network (laptops on the road, etc.).  It won't help with computers not running Windows 2000, or later.  So it can't do much for Linux or OSX clients.  It's not going to end world hunger.  But it might help in certain situations.

There's at least a dozen ways to modify or improve upon this, but hopefully it gives you an idea of what you can do with a few minutes and some rather basic scripting.

No comments: