Share via

Passwords in Group Policy Preferences (updated)

  • Article

Have you ever wanted to configure a preference item to include a specific user name and password? You can do so in several types of preference items, but you should first consider the security ramifications of embedding a user name and password in a preference item.

Are passwords in preference items secure? A password in a preference item is stored in SYSVOL in the GPO containing that preference item. To obscure the password from casual users, it is not stored as clear text in the XML source code of the preference item. However, the password is not secured. Because the password is stored in SYSVOL, all authenticated users have read access to it. Additionally, it can be read by the client in transit if the user has the necessary permissions.

Because passwords in preference items are not secured, we recommend that you carefully consider the security ramifications when deciding whether to store passwords in preference items. If you choose to use this feature, we recommend that you consider creating dedicated accounts for use with it and that you do not store administrative passwords in preference items.

Where can you use passwords? You can use passwords in the following types of preference items:

  • Local User preference items: When you create or modify a local user account, you can specify both a user name and a password for the account.
  • Data Source preference items: If a user name and password are required to access the data source, you can provide them in the preference item. If you do so, end users to whom the preference item applies can access the data source regardless of their own permissions, but only if the specified account has the necessary permissions.
  • Mapped Drive preference items: You can specify the user name and password to be used to connect to a mapped drive. If you do so, end users to whom the preference item applies can access the mapped drive regardless of their own permissions, but only if the specified account has the necessary permissions.
  • Scheduled Task or Immediate Task preference items: You can configure a scheduled task to run under the security context of a specified user (allowing the task to run regardless of whether that user is logged on), by selecting the “Run as” check box and providing a user name and password.
  • Service preference items: You can modify which account the service runs under by selecting “Local System account” or by selecting “This account” and specifying a user name and password.

For the user name in a Data Source, Mapped Drive, Scheduled Task, Immediate Task, or Service preference item, you can specify a local user account on multiple computers using the format .UserName, or a domain account using the DomainNameUserName format.

So, yes, you can configure some types of preference items to include a user name and password, but because the password is merely obscured rather than secured, you should carefully evaluate the security ramifications for your situation to determine whether it is appropriate to use this feature.

Linda Moore
Technical Writer, Group Policy

(Reposted and updated on 22 April 2009)

Comments

  • Anonymous
    January 01, 2003
    少し前になるのですが、本社のグループポリシーチームのBLOGに以下の投稿がありました。 Passwords in Group Policy Preferences (updated) http://blogs.technet.com/grouppolicy/archive/2009/04/22/passwords-in-group-policy-preferences-updated.aspx

  • Anonymous
    January 01, 2003
    PingBack from http://www.frickelsoft.net/blog/?p=184

  • Anonymous
    April 29, 2009
    What a pain!  So...how difficult would it be to "unobscure" a password stored in the xml file? The capability of managing local administrator passwords has been a long sought feature...now I'm not comfortable recommending this as a solution.

  • Anonymous
    August 31, 2009
    I have written a blog article show how you can still use Group Policy to set password on local administrator accounts while only having a very small window of opportunity for someone to capture the obfuscated password from SYSVOL. This is in my opinion far more secure then haveing the same default local admin password on all your computers for years. Alan

  • Anonymous
    May 15, 2014
    Pingback from Why Passwords in Group Policy Preference are VERY BAD

  • Anonymous
    May 19, 2014
    Pingback from Group Policy Preferences Password Vulnerability Now Patched » Sean's Tech Notebook

  • Anonymous
    May 19, 2014
    Pingback from Group Policy Preferences Password Vulnerability Now Patched » Sean's Tech Notebook

  • Anonymous
    May 23, 2014
    Last week, Microsoft released Security Bulletin MS04-025 , including guidance and an update that resolves

  • Anonymous
    May 23, 2014
    Pingback from Group Policy Preferences Password Vulnerability Now Patched » Sean's Tech Notebook

  • Anonymous
    March 28, 2016
    Hello... Can we reset the Local Admin Password for all computers in my domain using GPOs in server 2012 R2 Standard..