none
View Password hash in Active Directory

    Question

  • Hi all
    I am the administrator and i want to view the password hashes of the users  in Active Directory. Please tell me how i can view the password hashes of the users. Where are the password hashes of the users  stored in Active Directory.





    Thursday, March 26, 2009 7:07 AM

Answers

  • Hello breth82,

    The users' password is stored in the Active Directory on a user object in the unicodePwd attribute. This attribute can be written under restricted conditions, but it cannot be read due to security reasons. The attribute can only be modified; it cannot be added on object creation or queried by a search. In order to modify this attribute, the client must have a 128-bit Secure Socket Layer (SSL) connection to the server. For this connection to be possible, the server must possess a server certificate for a 128-bit RSA connection, the client must trust the certificate authority (CA) that generated the server certificate, and both client and server must be capable of 128-bit encryption.

    The unicodePwd stores a one-way format of the password that makes it is extremely difficult to determine the original password. AD normally does not use UserPassword attribute to store domain passwords.


    For more information, please refer to:

    How To Change a Windows 2000 User's Password Through LDAP

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;269190

     

    How to set a user's password with Ldifde

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;263991

    Thanks.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Proposed as answer by Scorprio_MiloMVP Saturday, March 28, 2009 5:55 AM
    • Marked as answer by David Shen Saturday, March 28, 2009 3:24 PM
    Friday, March 27, 2009 6:54 AM

All replies

  • Hello breth82,

    The users' password is stored in the Active Directory on a user object in the unicodePwd attribute. This attribute can be written under restricted conditions, but it cannot be read due to security reasons. The attribute can only be modified; it cannot be added on object creation or queried by a search. In order to modify this attribute, the client must have a 128-bit Secure Socket Layer (SSL) connection to the server. For this connection to be possible, the server must possess a server certificate for a 128-bit RSA connection, the client must trust the certificate authority (CA) that generated the server certificate, and both client and server must be capable of 128-bit encryption.

    The unicodePwd stores a one-way format of the password that makes it is extremely difficult to determine the original password. AD normally does not use UserPassword attribute to store domain passwords.


    For more information, please refer to:

    How To Change a Windows 2000 User's Password Through LDAP

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;269190

     

    How to set a user's password with Ldifde

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;263991

    Thanks.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Proposed as answer by Scorprio_MiloMVP Saturday, March 28, 2009 5:55 AM
    • Marked as answer by David Shen Saturday, March 28, 2009 3:24 PM
    Friday, March 27, 2009 6:54 AM
  • Hi David,
    Thanks a lot for your information.But, do you mean to say that even the administrator will not be able to view the password hashes of the users???Then how does the password history process take place::- how is the user's password being checked with the password history???There are many Hashing algorithms available..Which one is very secure??? Is it possible to find which hashing algorithm is used to store user passwords in Active Directory??Waiting for a response from you.
    Monday, April 06, 2009 11:04 AM
  •  

    Hi,

     

    Before going further, let’s clarify how Windows store password.

     

    Instead of storing the user account password in clear-text, Windows generates and stores user account passwords by using two different password representations, generally known as "hashes." When you set or change the password for a user account to a password that contains fewer than 15 characters, Windows generates both a LAN Manager hash (LM hash) and a Windows NT hash (NT hash) of the password. These hashes are stored in the local Security Accounts Manager (SAM) database (C:\Windows\System32\config\SAM file) or in Active Directory (C:\Windows\NTDS\ntds.dit file on DCs).

     

    You can force Windows to use NT Hash password. For detailed information, please refer to the following article.

    How to prevent Windows from storing a LAN manager hash of your password in Active Directory and local SAM databases

    http://support.microsoft.com/kb/299656

     

    After you configure Password History, Active Directory service will check the password hash stored in AD database to determine if user meet the requirement. Administrator doesn’t need to view or use password hash.

     

    Regarding the security of password, the following article may be helpful.

     

    Should you worry about password cracking?

    http://blogs.technet.com/jesper_johansson/archive/2005/10/13/410470.aspx

    Hope this information can be helpful.



    This posting is provided "AS IS" with no warranties, and confers no rights.

    • Edited by David Shen Tuesday, April 28, 2009 2:35 AM
    • Proposed as answer by Jens Ole Kragh Tuesday, April 28, 2009 6:11 AM
    Tuesday, April 28, 2009 2:32 AM
  • Hi David,

    Why is possible that tools like Sun Java Identity Synchronization for Windows can read UserPassword attribute hashes?

    Ordinary Domain account ('Domain Users' permissions only) is needed to read whole AD database hashes and store it to Sun-LDAP.

    How Can We approve our Domain security to disallow that issue?

    Thanks in advance

    Peter

    • Proposed as answer by mjscott77 Wednesday, May 26, 2010 7:20 PM
    Monday, May 03, 2010 1:36 PM
  • Sun does nto touch the hashes.  They cannot be used to sync passwords, as they are one way.  The tool uses a password filter on each domain controller.  Password filters have access to the plaintext password at password change and reset.

     

    Mark

    Thursday, July 29, 2010 6:25 PM