locked
Where is the AES key stored? How protected/secured? RRS feed

  • Question

  • AES (symmetric algorithm where encryption and decryption key is the same) is used for instance within Group Policy (passwords set by group policy preferences) to encrypt those passwords in the xml file being part of the group policy definition stored in SYSVOL. The question now - How do the domain joined client does get the key used for decryption and how is it protected / stored on the client? Is it a forest/domain based key or world wide the same (what I can't believe)? How easy would it be to find that key if I do have administrator rights on a domain joined client?
    Thursday, May 5, 2011 9:56 AM

Answers

All replies

  • Can you give a specific example?

    You can on this blog more information about passwords in group policy preferences.
    http://blogs.technet.com/b/grouppolicy/archive/2008/08/04/passwords-in-group-policy-preferences.aspx

    Kind Regards
    DFT


    IM me - TWiTTer: @DFTER
    Thursday, May 5, 2011 1:33 PM
  • the Groups.xml of a GPO contains:

    <Groups clsid="{3125E931-EB16-4b4c-9934-544FC6D24D26}">

    - <User clsid="{DF5F1815-51E5-4d24-8B1A-D9BDE98BA1D1}" name="Administrator (built-in)" image="2" changed="2011-04-28 13:51:56" uid="{88BED886-2FA4-4CF9-8ADE-081AEE061F87}" userContext="0" removePolicy="0">

    <Properties action="U" newName="" fullName="" description="Built-in account for administering the computer/domain" cpassword="L57tVpazDLR3tBYWJ82YFgjW81lPibLe5NdXmGREtqXlSfLBhUPWvFXNj87JEeYehVz1jg3GVTr1OgmoeYz0txwl4J+1X6u31U/OOgkzrDI" changeLogon="0" noChange="1" neverExpires="1" acctDisabled="1" subAuthority="RID_ADMIN" userName="Administrator (built-in)" />

    </User>

    where cpassword is the AES encrypted string. Now, to be able to decrypt the AES key is required by the client processing the GPO. Where does the client get the key from? Is it stored locally on the client somewhere and if so how is it protected?

    I also found the blog you mentioned above, but the blog doesn't answer our questions.

     

    Thursday, May 5, 2011 4:17 PM
  • Hi,

     

    Thanks for posting in Microsoft TechNet forums.

     

    I would appreciated if you can clarify why this inquiry is placed.

     

    With regarding to cpassword, there is a known issue. cpassword=""  remains blank password.

     

    Best Regards

    Magon Liu

    TechNet Subscriber Support in forum. If you have any feedback on our support, please contact tngfb@microsoft.com

     

     


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”
    Friday, May 6, 2011 9:32 AM
  • The query has been placed as it is not recommended to use preferences within GPOs to set passwords in high secure environments and my customer would like to be able to decide if whole process of AES key exchange to decrypt the password within such a GPO is secure enough for his environment. So, for instance if the AES key used is the same worldwide for all Microsoft Active Directories - this would be a NO GO; if the key is unique per client and protected by trusted certificates (to just pick an example) - customer would consider that the key exchange is safe enough for his environment. I hope I've been able to asnwer your question.
    Friday, May 6, 2011 9:45 AM
  • Hi,

    Please see the below links, it should answer your queries. It is not recommended for high security environments as passwords are not secured and simply obscured.


    Passwords in Group Policy Preferences (updated) http://blogs.technet.com/b/grouppolicy/archive/2009/04/22/passwords-in-group-policy-preferences-updated.aspx

    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.

     

    Passwords in Group Policy Preferences http://blogs.technet.com/b/gpguru/archive/2008/09/09/passwords-in-group-policy-preferences.aspx

    Are passwords in preference items secure?
    Passwords in Group Policy preference items are protected using 256-bit AES encryption. In the XML source code of a preference item, the password does not appear as clear text; it is encrypted. The client reads the XML, decrypts the password, and implements the configuration.

    Although passwords in Group Policy preference items are encrypted, they are not completely secure and therefore are not appropriate for situations requiring high security. Consider the security requirements of your situation, and use discretion when deciding whether to include passwords in preference items.

     


    Sumesh P - Microsoft Online Community Support
    • Proposed as answer by Sumesh P Monday, May 9, 2011 11:02 AM
    • Unproposed as answer by tiZ.A Monday, May 9, 2011 11:19 AM
    Monday, May 9, 2011 11:02 AM
  • I know those blogs but maybe I have described misleading. Let's try it once more coming from another direction:

    Why is an encrypted string using 256-bit AES key considered as not secure ? In fact it is high secure if the used key is protected!!! So the problem is the key which is used to decrypt the string and therefore my questions how is that key transferred to the client und stored in a secure manner at the client. By knowing that, we can decide for our environment if we consider it as secure enough or not. 

    Monday, May 9, 2011 11:29 AM
  • The key is hard-coded in the source. They key is also documented PUBLICLY in the protocol documentation in MSDN.

    This basically makes the obscured password a clear-text password for any informed attacker.


    Sumesh P - Microsoft Online Community Support
    • Marked as answer by tiZ.A Monday, May 9, 2011 12:42 PM
    Monday, May 9, 2011 12:38 PM
  • Hi Sumesh,

    that's what I was looking for - thanks. Do you have the link to that public available document on MSDN, please.

    Monday, May 9, 2011 12:41 PM
    • Marked as answer by tiZ.A Monday, May 9, 2011 1:12 PM
    Monday, May 9, 2011 12:49 PM