With the recent MS14-025 security patch Microsoft has removed the ability to configure passwords in Group Policy Preferences via the User Interface. However this update does not remove the password value from AD nor does it stop the value being applied to computers/users. So, if you have apply MS14-025 and you have also implemented another way of managing the local…

As per my previous blog post Microsoft has release MS14-025 that blocks the ability to configure passwords using Group Policy Preferences. However as part of the guidance they have also published a PowerShell script that allows you to set a random password to the user local admin account. This blog post show you how you can use this script (bad…

A long time ago did a blog post explaining how to use the Group Policy Preferences Local Users setting to manager the password of the local accounts. This post explained how to do it  in a way that minimised the exposure of the password in Active Directory (see  How to use Group Policy Preferences to change account Passwords ) for…

One strange thing that still seems to catch a lot of people out is that you can only have one password policy for your user per domain. This catches a lot of people out as they apply a password policy to an OU in their AD thinking that it will apply to all the users in that OU…. but it…

If you are using the Group Policy Preferences to apply local user account be aware there is a security risk in doing this. In short the passwords are stored in the AD SYSVOL encrypted using AES however the encryption key is well known so this could only be considered obfuscated at best…. More info about this can be read at http://blogs.technet.com/grouppolicy/archive/2009/04/22/passwords-in-group-policy-preferences-updated.aspx

However using Group Policy Preferences to set passwords on local user accounts is still extremely useful and one could argue that not changing the local administrator account password is potentially more of a security issue over time. So if you still want to use this option but want to mitigate the risk in using this feature then here are a few steps that can be taken that will help.

Before you start tell as few as people as possible when you are changing the passwords. This is important as if you tell people when the password is changing they will know when to look for the password stored in the SYSVOL.

Step 1. Change default group policy refresh period to be as short as you dare (see Image 1). The default is 90 minutes but if you can safely crank it down 5 or 10 minutes that would be better. This will speed up the propagation delay of the new password once is configured in the group policy.

Image 1. Changing the default group policy refresh

Step 2. Some time during the middle of the day create a new group policy object and configured the the new local user password option (See image 2). then wait for the setting to propagate.

Image 2. Configuring the Local Account Password

Step 3. Then you need to wait… How long? The formula i would use for the time to wait is as follows:

Max Active Directory Propagation Delay + Max Group Policy Refresh Interval

Therefore if it take 16 minutes for Group Policy changes to propagate to all DC’s in the domain and you have set group policy refresh to 10 minutes the formula will look like this.

16 minutes + (10 minutes + 2 minutes) = 28 minutes

Note the 2 minutes is to take into account the 20% offset that group policy refresh interval has from the set value.

Step 4. Then one you have waited for the new password setting to rollout DELETE the group policy password setting you configured. This will purge the obfuscated version of the password from the SYSVOL. The reason also I recommend you create and delete a new group policy each time you do this is so the password file is store in a different path in the SYSVOL which is just another way to make it harder for someone to file the password file.

Step 5. You may want to repeat steps 4, 5 and 6 a couple of days apart to ensure that you have applied the setting to all the computers that were not turned on or connected to the network the first time (sounds like a great reason to deploy Direct Access).

Step 6. Finally don’t forget to wind back the default group policy refresh interval to its original value.

Now as we are all good IT Professional it would be best to tell people that the local admin password has changed and will be disseminated securely (NOT via email or IM) when needed. The key is to do it quick and then remove the policy as soon as you are done to have the smallest window of opportunity as possible for someone to grab the password file.

Of course this sound very devious and some could say you are covering your trails by deleting the policy once you are done which is not something you generally want to do as a good IT Professional… But if you are going to do this in a organisation then your are probably going to need to follow change control anyway so you should still have an official record of what you have done.

Alan Burchill