none
How user's password is hashed and checked?

    Question

  • We know that user's password is stored as either LAN or NT or AES or Digest hash in SAM or Active directory. It is stored in unicodePwd attribute which cannot be read by the user or even the administrator.

    How the user's password is hashed?

    When the user enters the password, it is sent to the server using Kerberos protocol. After that how it is hashed and authenticated?

    Monday, June 16, 2014 5:39 AM

Answers

  • Hi

    This is how the data is stored in the Active Directory database.

    1. LM Password is hashed using NTOWF, Encrypted with the user's RID using SystemFunction025, Encrypted with PEK (Password Encryption Key), Stored in the unicodePwd attribute

    2. NTLM Password is hashed using NTOWF, Encrypted with the user's RID using SystemFunction025, Encrypted with PEK (Password Encryption Key), Stored in the dbcsPwd attribute.

    Note: That the PEK (Password Encryption Key) is generated by the SYSKEY of each DC, and the key is therefor unique on each DC/Database. The PEK it self is maintained in a none-readable, none-replicated attribute. (peekList: http://msdn.microsoft.com/en-us/library/cc221063.aspx)

    Other password hash formats are stored as "KeyPackages" in the supplementalCredentials attribute: http://msdn.microsoft.com/en-us/library/cc245674.aspx

    The supplementalCredentials attribute is also protected by the local PEK.

    Bonus: ADAM/ADLDS dose not drive it's PEK from the SYSKEY as ADDS. ADAM/ADLDS dose not apply the additional RID Encryption using SystemFunction025 for unicodePwd and dbcsPwd.

     


    Enfo Zipper
    Christoffer Andersson – Principal Advisor
    http://blogs.chrisse.se - Directory Services Blog



    Monday, June 16, 2014 6:49 AM

All replies

  • Hi

    This is how the data is stored in the Active Directory database.

    1. LM Password is hashed using NTOWF, Encrypted with the user's RID using SystemFunction025, Encrypted with PEK (Password Encryption Key), Stored in the unicodePwd attribute

    2. NTLM Password is hashed using NTOWF, Encrypted with the user's RID using SystemFunction025, Encrypted with PEK (Password Encryption Key), Stored in the dbcsPwd attribute.

    Note: That the PEK (Password Encryption Key) is generated by the SYSKEY of each DC, and the key is therefor unique on each DC/Database. The PEK it self is maintained in a none-readable, none-replicated attribute. (peekList: http://msdn.microsoft.com/en-us/library/cc221063.aspx)

    Other password hash formats are stored as "KeyPackages" in the supplementalCredentials attribute: http://msdn.microsoft.com/en-us/library/cc245674.aspx

    The supplementalCredentials attribute is also protected by the local PEK.

    Bonus: ADAM/ADLDS dose not drive it's PEK from the SYSKEY as ADDS. ADAM/ADLDS dose not apply the additional RID Encryption using SystemFunction025 for unicodePwd and dbcsPwd.

     


    Enfo Zipper
    Christoffer Andersson – Principal Advisor
    http://blogs.chrisse.se - Directory Services Blog



    Monday, June 16, 2014 6:49 AM
  • Hi,

    In addition to the above information, please find the details given below,

    - The AD Users' password is stored in the Active Directory on a user object in the unicodePwd attribute. 
    - 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.

    Reference - View Password hash in Active Directory

    Regards,
    Gopi
    JiJi Technologies

    Monday, June 16, 2014 8:36 AM
  • Hi,

    I like the question and Chris answer

    "When the user enters the password, it is sent to the server using Kerberos protocol. After that how it is hashed and authenticated?" - this depends and the reason is explained below

    I will extend the discussion and not limiting to just user logon but Authentication as a prime. For every transaction of an application / executable / service NT Security subsystem validates user credential information and selects the right package ( authentication packages )

    Phase 1

    User Logon :
    After Windows subsystem is successfully started by SMSS and initialization of Session 0 ( all of windows services would run ), c:\windows\system32\wininit.exe creates 3 child processes SCM , LSASS and local session manager. LSASS listens to any authentication requests and enforces security policies and audit messages.

    < not explaning about SCM and other LSM >

    after SCM and LSM initialization and loading of services are completed,

    Winlogon creates system sid  --> Winlogon secure desktop gets loaded --> Winlogon establishes Asynchronous LPC call with LSA --> Winlogon creates User SID which then passed to LSASS

    Phase 2

    Authentication

    user enters his credentials  --> creds are sent to packages [msv1_0 / Kerberos]

    Phase 2 : Branch 1 : MSV1_0 : please note that MSV1_0 implements Lan Manager / LM 2 protocol

    MSV1_0 reads user name and hashed password, Groups it belongs and send to SAM --> Validates hashed password against SAM db --> Creates User token --> Windows never stores complete hash password in registry but stores half of the hash

    For any other authentication ( eg: shared folder access )

    Ksecdd.sys exports MSV1_01 package --> KSECDD calls LSA to generate NTLM response based on user credentials --> MSV1_01 validates password against SAM --> NTLMSSPs.dll creates hashed blob -->

    Phase 2 : Branch 2 : Kerberos

    similar process as MSV1_01 except that the protocol and port changes to Kerberos and port 88 .KDCSVC.dll  is the key process which validates user info and returns back to LSASS and LSASS creates access token

    with the above information, I would like to understand more about your requirement

    Monday, June 16, 2014 8:45 AM
  • Hi,

    In addition to the above information, please find the details given below,

    - The AD Users' password is stored in the Active Directory on a user object in the unicodePwd attribute. 
    - 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.

    Reference - View Password hash in Active Directory

    Regards,
    Gopi
    JiJi Technologies


    SSL/TSL encryption is only required for LDAP in Windows 2000 Server, there is various other API calls that you can use to set the password and write back to the attribute.  Also note: On Windows Server 2003 operating system, Windows Server 2008 operating system, Windows Server 2008 R2 operating system, Windows Server 2012 operating system, and Windows Server 2012 R2 operating system, the DC also permits modification of the unicodePwd attribute on a connection protected by 128-bit (or better) SASL-layer encryption _instead_ of SSL/TLS.

    Enfo Zipper
    Christoffer Andersson – Principal Advisor
    http://blogs.chrisse.se - Directory Services Blog

    Monday, June 16, 2014 12:32 PM