Passwords stored in GP Preferences

Posted April 23, 2009

Linda Moore from the GPTeam created a blog posting on the team’s blog about stored passwords in GP Preferences. She makes some points about how secure the passwords stored in GP Preferences are:

http://blogs.technet.com/grouppolicy/archive/2009/04/22/passwords-in-group-policy-preferences-updated.aspx

The key points are:

  • Passwords are stored - encrypted with AES - in the XML files
  • those files are stored on SYSVOL authenticated users have read access to it and can therefore read it
  • Use dedicated accounts when using GP Preferences to store passwords.
  • [AES is a symmetric key algorithm. If I have the key, I can decrypt all of the passwords if the key doesn’t change.]
Posted in Group Policy

9 Comments so far

  1. Tomek on April 23rd, 2009

    I just thought that this post URL might be useful as well as it contains information about AES encryption which is not present in blog post You have pointed to:
    http://blogs.technet.com/gpguru/archive/2008/09/09/passwords-in-group-policy-preferences.aspx

    Just to point to some sources ;)

  2. florian on April 23rd, 2009

    Thanks Tomek, I mentioned AES with its 256bit encryption in another posting: http://www.frickelsoft.net/blog/?p=116 — but I kind of like an authoritive source (MSFTish) better :)

  3. bremby on April 23rd, 2009

    hi florian,
    what do you mean with “•Use dedicated accounts when using GP Preferences to store passwords”?
    can you explain this point?

  4. Mike Kline on April 23rd, 2009

    Do you think GPP is still a valid solution for changing the local admin password on machines?

    At my last job we used a third party tool to do this.

    Thanks

    Mike

  5. florian on April 24th, 2009

    bremby,

    I actually meant that you should only “deploy” user accounts with GPP that you don’t use for other services. You shouldn’t use an AD account you use for backups and other stuff that has extended permission on other machines/services.
    You should also regularly change the account’s

    Cheers,
    Florian

  6. florian on April 24th, 2009

    Mike,

    it is a good solution to deploy passwords in smaller organizations - I’ve seen a lot approaches, from scripts to encrypted scripts with passwords in it. So I think this is really a step forward for rather small to medium organizations.

    With the right precautions like dedicated user accounts that you use in GPP to push on clients and regular password change cycles, I guess it is a good thing.

    Nothing for high security environments but good enough if you know what isses it has.

  7. Alan Burchill on August 31st, 2009

    I have written a blog about how to use this option to reset the local admin password on computer using Group Policy Preferences while keeping the window of opportunity as small as possible for someone grabing the obfuscated password.

    http://abskb.spaces.live.com/blog/cns!8834054641A09100!1071.entry

  8. florian on September 1st, 2009

    Howdie!

    That is a nice trick although I think most larger orgs (and even the mid-sized ones) won’t want to change the GP refresh time as that puts additional load on the DCs and the lines. With that, you could easily take down a line between a hub and the spoke if the spoke clients need to connect to a hub DC

  9. Alan Burchill on September 17th, 2009

    Florian

    Excellent point… I think for the very large organisations the GPO’s are normally broken down into regions and/or sites… therefor you could probably stager the change. Another option is that you could make the change early one morning so all the computer will get the new policy when they log on.

    In any case i think you network and DC’s would have to be pretty close to the edge if changing the policy refresh period from 90min to 30min slows everything down… However this could cause issues on XP as users do seem to notice the flicker that is assoicated with a GP update.