A 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
Blog: Group Policy Preferences Password Behaviour Change – MS14-025 http://t.co/76IyZepNzs
RT @alanburchill: Blog: Group Policy Preferences Password Behaviour Change – MS14-025 http://t.co/76IyZepNzs
RT @alanburchill: Blog: Group Policy Preferences Password Behaviour Change – MS14-025 http://t.co/76IyZepNzs
Group Policy Preferences Password Behaviour Change – MS14-025 http://t.co/mb8SVA8XUq
RT @stealthpuppy: Group Policy Preferences Password Behaviour Change – MS14-025 http://t.co/mb8SVA8XUq
RT @stealthpuppy: Group Policy Preferences Password Behaviour Change – MS14-025 http://t.co/mb8SVA8XUq
Group Policy Preferences Password Behaviour Change – MS14-025: http://t.co/NBNQQM74pn
RT @BjornHouben: Group Policy Preferences Password Behaviour Change – MS14-025: http://t.co/NBNQQM74pn
Hi Alan,
Are you aware of a workaround to help manage local “Administrator” passwords without using GPP?
I presume there is a not a simple resolution as this would need the password to be be located somewhere.
We were using this policy when performing network migrations but would then remove the policy after the network migration was completed.
Thanks
How would you do a scheduled task now to shutdown machines at night whether a user is logged in or not?
So, they disabled a feature that they provided, allowed us to get used to using it, and rather than FIX it, they disabled it…. Worse than that.. they didn’t provide any alternative guidance. Who was in charge of this mitigation, and since when is it ok to just tell people they can’t weigh the risk/benefits for something on their own. I have come to expect better than this from MS. Am I the only one who’s disappointed in the way this was handled?
The problem is that Microsoft *cant* realy fix this problem as what ever method they use to encrypt the password they have do document due to the USA Antitrust laws. They have to publicly disclose any network protocols and as Group Policy goes over the network they need to document how this password is stored and works. As for alternative guidance, yes they did provide this. In fact the UI has been warning user about this option and telling them the risk for years now.
There is also extensive alternative how to guidance on my blog that was based on the MS post http://support.microsoft.com/kb/2962486
Thanks Alan, For Awesome Post , <3
Waiting your Next Post For
"Coming soon: How to Manage Local Admin Password and How to remove cPasswrods from your AD"
Regards Alan <3
“due to the USA Antitrust laws. They have to publicly disclose any network protocols and as Group Policy goes over the network they need to document how this password is stored and works”
sounds like NSA’s imposed requirement to be able to hack into people’s systems without too much effort
Ok, I understand the security merits of this, but I don’t know of a good workaround for my situation. I am struggling with a mapped drive. The box uses Samba, but it has a pre-configured username and password. It’s basically a black-box from a vendor running some stripped down custom linux kernel.
I have about 30 users who I want the AD to map this drive for them when they log on. It obviously fails because their AD accounts are not the one unconfigurable SMB password.
Every time one of these 30 users log into a workstation on the domain for the first time, I don’t want to have to go physically one-off map a drive for them. If something changes like the IP address of this black box, I don’t want to have to go to every workstation that these users have logged onto, log on as them, and change their drive map settings…… How do I rectify this situation without Shell access to the black-box as the vendor keeps that proprietary, and without using the Connect as option?
Essentially there is no way to do this via Group Policy now… this is also the disadvantage of having a non-windows device or one that cannot authenticate with a domain. Certainly 30 users is pushing the scaling limit of what you are trying to do. Sorry i cannot suggest any alternatives…
Not sure how the drive mapping work, but couldn’t you just use Preferences => Windows Settings => Registry within Group Policy and add the mapped drive settings directly? I have used this method to work around ODBC Passwords for MySQL (since SSO isn’t available for MySQL) – in any case it was always this way for ODBC Group Policy on 64 Bit Machines.