How to remove cPassword values from Active Directory

no_passwordsWith 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 admin password (see my other post How to set the Local Administrator account to a Random Password ) the next thing to do is to remove all the passwords from AD so there is no traces left of the old insecure passwords.

Side Note: These passwords in AD that Group Policy preferences user are also know as cPasswords because that is the name of field that is used to save the password value (see below)


How insecure is the cPassword field? See my post Why Passwords in Group Policy Preference are VERY BAD. Then remember that even you have deployed MS14-025 and you are managing password via other mean’s you might still have passwords in your organisation that have not be changed, so these passwords might still be valid on some computers.

So along with the password reset PowerShell script released in the MS14-025 Microsoft  they also provide a script that allows you to identify the polices. Below I go thought and show how you can run this script and how you can purge the scourged of cPasswords in your organisation.

First of all go to and copy the Get-SettingsWithCPassword.ps1 script from the page and save that as a file called “Get-SettingsWithCPassword.ps1” on the computer you are going to run the script.

Note: You will need to run “Set-ExecutionPolicy -ExecutionPolicy Unrestricted” on the computer to run this script as it is not signed. Be sure to not leave your computer in this state as it does reduce the security of your system.

Then open a PowerShell command prompt from any workstation, preferably one that has read access to all the GPO’s which is most accounts by default.

Warning: Depending on the size of your System Volume and how fast your network and domain controllers are this can take a VERY LONG time (Hours).

Then run the following command (replacing the highlighted values with your own DNS domain name):

.\Get-SettingsWithCPassword.ps1 –path “\\corp.local\SYSVOL\corp.local” | Format-List


As you can see it has now listed the Group Policy Objects name and path to the setting in your domain that have the cPassword value configured.

TIP: You may want to run this script on your environment straight away on your environment to see how pervasive the use of the cPassword value is in your environment. (I am betting a lot).

Removing cPasswords the easy way

The easiest thing to do to remove these values would be to simply go in an delete the relevant Group Policy Preferences settings or the Group Policy Object. This will delete all the files that contain the cPassword value from SYSVOL thus purging the value.

Removing cPasswords the hard way

But this Group Policy Preference might be part of a complicated Group Policy Object or other Group Policy Preferences settings so you *might* want to just remove the cpassword value surgically.

To do this open up the Group Policy Management Console and edit the affect GPO so that we can go to the relevant file in the SYSVOL for that GPO. Then navigate to the Computer Configuration (or user) > Policies > Windows Settings > Scripts (Startup/Shutdonw) then click on the “Startup” script and then click on the “Show Files…” button.


This will open up Windows Explorer somewhat close to the folder that has the cPassword value stored. You will need to go up the “Machine” (or User) folder and then open up the “Preferences” folder.


Now open Notepad.exe as an administrator and open the XML files in that location (in our example it is ScheduledTasks.xml).Now search for the name “cpassword” and it will jump to the location that the cPassword is stored.

Note: It is important to open up notepad as administrator (or with permission to edit the GPO) otherwise you will not be able to save the file.


Warning: Be sure that you have replaced the functionality of this Group Policy Preferences using another method as this will break the functionality of the setting.

Now delete the entire cpassword field from the XML and save the XML file.


You can run the script again to confirm that the cpassword filed is removed from AD.


So I expect this is the last in the series of post about cPassword value in Active Directory. Hopefully by now you are fully aware of the issues with passwords with Group Policy Preferences (see Why Passwords in Group Policy Preference are VERY BAD) and that you have prepped your environment (see How to enable WinRM via Group Policy) to enable password management via the means (see How to set the Local Administrator account to a Random Password). You then  applied MS14-025 to all your computers (see Group Policy Preferences Password Behaviour Change – MS14-025) and have been trying to identify and limit the use of the cPassword values using this post.

So how many cPasswords do you have in your environment? Please shout out the number in the comments below.

How to set the Local Administrator account to a Random Password

imageAs 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 word, I know) to manage the passwords of local accounts on the computers in your organisation.

TIP: Before starting remember that it is entirely practical to have an SOE with no local admin accounts enabled at all. If this ever gets you into tight water and you need to logon to the computer you can still follow my other blog post to logon to the computer (see How to enable a disabled Local Administrator account offline in Windows 7 (even when using BitLocker)

But, if you are using local admin accounts on your workstations then the following will give you an alternative to using the now disabled password feature in Group Policy Preferences. The PowerShell script that Microsoft provides generates a unique random password for each compute so it’s also a mitigation step against a Pass-the-Hash attacks. This is a nice side affect of setting a unique password as you cannot use the hash of one local admin account to access another computer.

Simply put, this PowerShell script contacts each computer over the network from a pre-defined list and then set the local account password to a random value.

Note: Because the computer’s need to be turned on for it to reset the passwords so you may have to perform this process on a regular basis to ensure that you cover all computers.

Next, it then saves this password to a file that can/should be encrypted with a “master password” of your choosing. This is of course necessary to give  added protection against anyone that “might” grab a copy of the password file as it means they would also have to know the encryption password to decrypt the password value.  Saving the password in a text file might not sound all that secure however it is a lot more secure than using Group Policy Preferences.

Recap: Group Policy Preferences saves the “cPassword” value in Active Directory System Volume in files that are readable by all users and with the same 32bit encryption password.

Warning: While this script is from Microsoft it clearly states that in no way shape or form is it actually support so the following is to be used at your own risk. (See MS14-025 for further disclaimers).


As I said before this PowerShell script actually makes a connection to each computer you first need to enable WinRM on all the computers that you are changing the password on. To do this take a look at my previous post How to enable WinRM via Group Policy and ensure that it is applied to your computers.

Running the Password Change Script

Go to MS14-025 and take a copy the script the entire change password script into a text file on the computer you are going to be running the process from. Next you need to open a PowerShell Windows running as Administrator permission and then paste the contents of the script into the Windows. You will then need to press “Enter” twice to ensure that the entire script has run. (see below)


You have now created the require functions in that current PowerShell window to perform the password change process. You will need to do this each time you open a new PowerShell Window as the command are not persistent. This might be a little convoluted but doing it this way also removes the need to enable unrestricted or bypass of script signature checking. The next step is to generate an up to date list of computer names in a text file for the script to process though with the password change.

Below is my extremely complicated example file: image

Once you have you file created you now need to run the Invoke-PasswordRoll that will go though and set the password on each computer name in the list:

Invoke-PasswordRoll -ComputerName (Get-Content ComputerList.txt) -LocalAccounts Administrator -EncryptionKey "P@ssw0rd1" -PasswordLength 22 -TsvFileName "LocalAdminPasswords.tsv"

Of course you should use your own unique Encryption Key to encrypt  the password value. Tip: Don’t forget the password!!!!! image

As you can see the script will also warn you when there is other local accounts on the computer that is not affected by this script. The script will append to the “LocalAdminPasswords.tsv” file is as follow, this means that the last password value on the list for that computer name is the valid encrypted password. image

Now when you want to retrieve the password for that account you need to copy the corresponding “EncryptePassword” value and then run it through the “ConvertTo-CleartextPassword” command.

Tip: Be sure that the encryption key matched the value you used in the “Invoke-PasswordRoll“ command above.

ConvertTo-ClearTextPassword -encryptionkey "P@ssw0rd1" –EncryptedPassword (WAY TO LONG TO PUT HERE)

As highlighted below is the unique 22 character random password for the local admin account on the corresponding computer that you can now use to logon to the computer. image

Now that you have an alternative to the passwords in Group Policy Preferences be sure that the file is save in secure location and that you also periodically run the script. While this is no where near as easy as using Group Policy Preferences this is definitely are far more secure way to mange the local admin passwords on your computers. But as I mentioned above, if you can, its far better to disable all the local admin accounts entirely on your computers as this will be more secure and easier to manage.

How to enable WinRM via Group Policy

The Windows Remote Management (a.k.a. WinRM) interface is a network service that allow remote management access to computer via the network. It’s used  frequently as a conduit to allow remote management of computer via PowerShell. As a result WinRM is enabled by default on Windows Server 2012 to enable the Server Manager tool but it is not enabled for Windows client OS’s by default.

As it is turned off by default on client OS’s the following describes how you can enable it using Group Policy.

Firstly create a Group Policy Object that targets the workstation that you want to enable the WinRM (e.g. “Enable WinRM”)

Then enable the “Allow remote server management through WinRM” policy setting found under Computer > Policies > Windows Components > Windows Remote Management (WinRM) > WinRM Service. From here you need to specify the IP Address ranges that the service will accept connections from, be cautious if you just add “*” in the field as this can potentially allow incoming connection form all network locations. If possible specify the exact IP ranges that you will be performing the remote management from to reduce the risk of connection coming in from any computer.

Note: This policy is also know as “Allow automatic configuration of listeners”


Next we need to enable the “Windows Remote Management (WS-Management)” Service via the Group Policy Preferences Services.


And finally we need to open up the firewall rules to allow the incoming TCP connection on the Domain Network profile.

Go to Computer Configurations > Policies > Security Settings > Windows Firewall and Advanced Security > Windows Firewall and Advanced Security then right click on “Inbound Rules” and click on the “New Rule…” option.


Check the “Predefined” option and select “Windows Remote Management” from the pop-down list and Click “Next”


Then uncheck the top “Public” rule to again reduce the exposure of this services to the internet and then click “Next”


Then click “Finish”


And you should now have a new listed as similar to below.


To again reduce the exposure of this service again you can double click on the new rule you just created and remove the “Private” from the network profiles that this applies.


You have now enable WinRM on your workstations that is required to allow you run PowerShell remote commands against.

As you might already realise enabling this should not be taken lightly as you are essentially opening up a way to completely remote control your computers. This is why should always limit the scope of incoming network connections to only the required networks/hosts.

Group Policy Preferences Password Behaviour Change – MS14-025

imageA number of month ago I did a blog post explaining why the use of passwords (a.k.a. cPasswords)  in  Group Policy Preferences was such a bad idea ( see Why Passwords in Group Policy Preference are VERY BAD). Well Microsoft have now taken the additional steps and now release a new hot fix for Group Policy Management Console that explicitly blocks the functionality (MS14-025: Vulnerability in Group Policy Preferences could allow elevation of privilege). What this effectively means is that after you have installed this patch you can no longer add or modify the password field on any Group Policy Preferences.

As you can see how this looks in the “User Group Policy Preferences” where the password dialog fields are now greyed out.


But now you might be wondering what happens if you already have the password configured on a Group Policy and you try to edit that password…

As you can see below, when you edit an existing Group Policy Preference settings with a password configured you will see the following dialogue box warning.


You can see that the password is configured, however you will not be able to modify or delete the value using the user interface..


So this means that after years of guidance / warnings from Microsoft to not use passwords in Group Policy Preferences they are now explicitly blocking the ability to configure this via the UI. However this patch is not automatically pushing out this patch therefore this removal of functionality will only happen when you explicitly install the update.

This hotfix is available for ALL versions of Group Policy Management Console that support Group Policy Preferences and you you can get the files via  Vulnerability in Group Policy Preferences Could Allow Elevation of Privilege (2962486)

Coming soon: How to Manage Local Admin Password and How to remove cPasswrods from your AD

How to setup Internet Explorer 11 Enterprise Mode Logging

IE9answerIn my recent blog post about Internet Explorer 11 I explain how you can enable Enterprise Mode via Group Policy. The option “Let users turn on and use Enterprise Mode from the Tools menu” as the name suggest allows users to enable the option form the Tools menu in Internet Explorer.

But as the description of this also mentions:

Optionally, this policy also lets you specify where to get reports about the websites for which users turn on Enterprise Mode using the Tools menu.

This is like Crowd Sourcing the list of internal web sites you have that need to be configured in IE Enterprise Mode for them to work.  You can then use this information and build your own IE Enterprise Mode site list using the Enterprise Mode Site List Manager tool and deploy your own Enterprise Mode XML list so that the other users do not need to explicitly need to do something to make their browsers work.

To setup this option on the client just following the TechNet article  Turn on local control and logging for Enterprise Mode (see example below).

Note: In the example below have used a custom HTTP port 81. I recommend you do this for your logging web server.


But it the TechNet article says:

To turn on logging, you must include a valid URL that points to a server that can be listened to for updates in your registry key

This unfortunately does not explain how to setup an end point server to listed for these incoming POST messages that are sent whenever a user toggles the Enterprise Mode button in the Menu.

Being curious I then cracked open Fiddler to see what exactly the payload was that was being submitted as a POST form. As you can see it submits two parameters in the form of a POST form submission. As a side note I also noticed that the User-Agent string is different in the browser as it switches between modes.



But as you can see by the error messages on the right I did not have a server setup to accept these incoming POST messages.

Therefore I next installed IIS the DC01 server with ASP component so that I could setup an ASP form to accept this incoming information.


I then edited the binding of the web site to port 81 to match the custom port I configured in the Group Policy setting. The reason I created a custom port is so that I could have a dedicated site that was only for this incoming information. This is important as I am logging the information to the web sites log file and any other traffic would make it much harder to find the incoming Enterprise Mode Logging  information.


I then modified the logging of the web site to only include Date,Client IP,User Name and URI Query. I did this to keep the log file as simple as possible. If you really wanted to you could just select the URI Query option. But I found the date, client IP useful for discovering who was having issues.


I then placed the ASP file called “ieem.asp” (see code below) which  in the root of the web server. The name of this file again has to match the name you specified in the Group Policy above.

<% @ LANGUAGE=javascript %>


Response.AppendToLog(" ;" + Request.Form("URL") + " ;" + Request.Form("EnterpriseMode"));


The ASP information above simple logs the POST fields to the IIS log file that you can then simply extract the date you need (example highlighted below)..

IIS Log File Output


Internet Explorer 11 Enterprise mode is now rolling out automatically as part of Windows 8.1 Update and the recent Windows 7 internet Explorer 11 security update KB2929437. This means that this functionality is probably already starting to deploy in your organisation if you are using IE11 so why not start taking advantage of your users to Crowed Source what internal web sites have compatibility issues.

Credit: Thanks to Adam Kim and Chris Jackson from Microsoft for the ASP code and point me on the right direction to get this working.