locked
User password and NTLM hash RRS feed

  • Question

  • I am having a hard time understanding Windows authentication.  

    Currently I am trying to figure out how the users password can be used after the NTLM hash is changed.  Here is the scenario:

    1. User has password set and NTLM hash is updated.

    2. User is set to "smart card required for interactive log on" and NTLM hash is once again updated.

    3. User's original password still works for non interactive log on.

    4. Turn off smart card required and the user's password from step one is still valid.

    Is the users NTLM hash sent after authentication?  How can the client generate the same NTLM hash that exists on the DC?  It cannot be adding something from UserAccountControl since the NTLM hash does not change when smart card log on is turned off.

    Thank you in advance.

    Monday, December 1, 2014 7:28 AM

Answers

  • Hum, I think there are some confusions here. It might be me, so I'd rather clarify.

    You can't change the password without changing the NT hash. And the NT hash does not change by itself. Hopefully otherwise it would just break the authentication. When the smart card option is checked, it generates a random password hence a new hash, not just a new hash, it does generate a password which is not visible, that's it. We do not store the password of a domain user in Active Directory, we store its hash we can't change the first one without the other. If you want to change the hash, you change the password. The hash does not change automatically (on Windows Server 2012 gMSA accounts could be perceived an exception to this rule but there are a very specific scenario and this is still not a change of the hash but the generation of a random password hence a change of the hash).

    Credential Manager and Credential Locker documentations:


    On the domain controller
    , domain users information are exposed through the SAM API (and it is documented in here [MS-ADTS]: Active Directory Technical Specification and here [MS-SAMR]: Security Account Manager (SAM) Remote Protocol (Client-to-Server)).

    Local SAM does not store domain user hash. I don't understand your claim. Do you have a reference? Or a test which validate this?

    Things can be done for the hash or ticket in the LSASS memory and this is what the Restricted Admin function of Remote Desktop does (with its bunch of limitations).

    Risks and mitigation techniques for Pass-The-X are available on the Microsoft Cyber Security Blog: http://blogs.microsoft.com/cybertrust/2012/12/11/new-guidance-to-mitigate-determined-adversaries-favorite-attack-pass-the-hash/

    As far as I know, there is no way to dump hashes on a system without being a local administrator or elevating your privileges (to get the seDebugPrivilege or other privilege that can lead to enabling this one). We can debate about live debug, but this a bit off the topic.


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.





    Wednesday, December 3, 2014 1:43 PM

All replies

  • Dear Friend,

    Actually,  lets try to solve this thinking out of the box. Do you have multiple DC's on your enviroment?

    Probably it's not generating the same HASH the point is that the HASH does not get updated by replication delay maybe.

    PDC emulator process password info, take a look on this.

    Best Regards,


    Sergio Figueiredo
    Microsoft Certified Solutions Associate

    Monday, December 1, 2014 12:21 PM
  • Thank you Sergio, but it is not due to replication.  This is actually a method we use for non kerberos authentication to tools like Spectrum for weeks at a time without password reset.  We do notice that the password still expires after 90 days and the user has no way to reset their password if they wait until it expires.  Any time before expiration they can use ctrl+alt+del to reset their password and have another 90 days.

    One of the Microsoft contractors I spoke to about this commented that there are indeed other hashes stored on the DCs that are used for authentication, but did not have the details.  

    I have looked through all the sysinternals books and have not found anything about any of this.  

    How is something like this not documented anywhere?  Does anyone have any information, or can anyone point to any documentation that actually states what is going on?



    Tuesday, December 2, 2014 11:07 AM
  • Dear Pseudosymbiotic,

    Humm go it. Btw, i never heard about spectrum, but i know that NTLM even Kerberus are not a Microsoft proprietary protocol.

    I found this documentation about NTLM outside Windows and another at MSDN, maybe you would like to take a look on it.

    Best Regards,


    Sergio Figueiredo
    Microsoft Certified Solutions Associate


    Tuesday, December 2, 2014 12:10 PM
  • This is what I see on my lab (one DC, Windows Server 2012, one member server Windows Server 2012):

    1. I create a user called Alice with password1
    2. I can log on with Alice on my server using password1, I log off.
    3. I check the checkbox "smart card is required for interactive logon"
    4. I check the version of the attributes userAccountControl, unicodePwd and ntPwdHistory, they all increased by one (the password has been changed - and should be a random password)
    5. I cannot log on with Alice on my server using password1
    6. I uncheck the checkbox "smart card is required for interactive logon"
    7. I check the version of the attributes userAccountControl, unicodePwd and ntPwdHistory, userAccountControl is increased by one, the two others are not changed (the password did not change)
    8. I cannot log on with Alice on my server using password1

    On your side, where in that sequence do you see a difference?


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Tuesday, December 2, 2014 5:07 PM
  • Thank you for your posts guys.  

    It sounds like this may be something they changed in Server 2012, but here is a link to the WordPress blog I started just for posting screenshots of this.

    I do not have a side menu, but there are two posts.  The oldest of the two covers the needing to change the NTLM hash on a smart card required user.  The most recent is the NTLM hash being usable.

    https://meincomp.wordpress.com

    Tuesday, December 2, 2014 10:01 PM
  • I read your posts. Here are some additional information:

    • Password's hashes are stored in 4 attributes in Active Directory: dBCSPwd stores the LM hash, lmPwdHistory which stores the history according to the password policy, unicodePwd which stores the NT hash and the ntPwdHistory that stores the history, again according to the password policy.
    • Those hashes are not reversible. They are not salted.
    • Other attributes can potentially receive a the password (userPassword or unixUserPassword) but those are corner cases and unless you manually configured your environment to be highly interoperable with some Unix based infrastructures, you are not using those password.
    • Every time the password of a domain user is changed, those 4 values are modified.
    • When you enable the option "smart card is required for interactive logon" the password is set to a random value (hence the 4 attributes mentioned above are changed - appended for the history).
    • Accounts with the option "smart card is required for interactive logon" do not apply the password expiration policy.
    • When you uncheck "smart card is required for interactive logon", this does not change the password.
    • Smartcard authentication uses only Kerberos. In order to make sure the user will be able to access to resources not Kerberos aware or capable, or resources using their IP addresses versus their names, the NTHash is sent to the client. This is by design.
    • A user can change its password, or an admin can change the password of the user after enabling the option "smart card is required for interactive logon". Some "security" application even requires the password to be changed to be able to work with the account (3rd party applications, I don't have names on the top of my head).
    • In the continuity of the precedent point, if you uncheck the "smart card is required for interactive logon" and the password has been changed by the user or the administrator, the user will be able to use it (unless in now expired).
    • Windows 2000 Server domain controllers are not generating random password when you select the option "smart card is required for interactive logon", but I guess this OS is way out of the picture now.
    • Domain user's hashes are not stored in the local SAM of workstation or server. They might be cached via the cached credential functionality if enabled (it is by default, this allow a user to take its laptop home and still perform a local logon with its domain account). This could be disabled with the potential issues you might guess.
    • Cached Credential hashes are salted. Only local administrators can access them by default.
    • Other type of credentials might be cached on a machine using the Credential Manager feature (when you checked the box "remember my password" while mapping a drive, or acceding to Internet resources).
    • Hashes (as well as tickets, because the pass-the-hash that you might refer to is also possible with Kerberos - pass-the-ticket) are cached in the memory of the machine. Users with the privilege seDebugPrivilege can access to the memory. By default only local administrators can claim that privilege.

    I hope this helps to see clearer. All of it is documented online on TechNet and MSDN (in the Open Specification Promise section particularly).


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.



    Wednesday, December 3, 2014 3:02 AM
  • I read your posts. Here are some additional information:

    • Password's hashes are stored in 4 attributes in Active Directory: dBCSPwd stores the LM hash, lmPwdHistory which stores the history according to the password policy, unicodePwd which stores the NT hash and the ntPwdHistory that stores the history, again according to the password policy.
    • Those hashes are not reversible. They are not salted.
    • Other attributes can potentially receive a the password (userPassword or unixUserPassword) but those are corner cases and unless you manually configured your environment to be highly interoperable with some Unix based infrastructures, you are not using those password.
    • Every time the password of a domain user is changed, those 4 values are modified.
    • When you enable the option "smart card is required for interactive logon" the password is set to a random value (hence the 4 attributes mentioned above are changed - appended for the history).
    • Accounts with the option "smart card is required for interactive logon" do not apply the password expiration policy.
    • When you uncheck "smart card is required for interactive logon", this does not change the password.
    • Smartcard authentication uses only Kerberos. In order to make sure the user will be able to access to resources not Kerberos aware or capable, or resources using their IP addresses versus their names, the NTHash is sent to the client. This is by design.
    • A user can change its password, or an admin can change the password of the user after enabling the option "smart card is required for interactive logon". Some "security" application even requires the password to be changed to be able to work with the account (3rd party applications, I don't have names on the top of my head).
    • In the continuity of the precedent point, if you uncheck the "smart card is required for interactive logon" and the password has been changed by the user or the administrator, the user will be able to use it (unless in now expired).
    • Windows 2000 Server domain controllers are not generating random password when you select the option "smart card is required for interactive logon", but I guess this OS is way out of the picture now.
    • Domain user's hashes are not stored in the local SAM of workstation or server. They might be cached via the cached credential functionality if enabled (it is by default, this allow a user to take its laptop home and still perform a local logon with its domain account). This could be disabled with the potential issues you might guess.
    • Cached Credential hashes are salted. Only local administrators can access them by default.
    • Other type of credentials might be cached on a machine using the Credential Manager feature (when you checked the box "remember my password" while mapping a drive, or acceding to Internet resources).
    • Hashes (as well as tickets, because the pass-the-hash that you might refer to is also possible with Kerberos - pass-the-ticket) are cached in the memory of the machine. Users with the privilege seDebugPrivilege can access to the memory. By default only local administrators can claim that privilege.

    I hope this helps to see clearer. All of it is documented online on TechNet and MSDN (in the Open Specification Promise section particularly).


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.




    Just want to clarify on "Those hashes are not reversible. They are not salted." - they might not be "salted" how ever they are additionally encrypted in the Active Directory database (NTDS.dit) using the RID using SystemFunction025, Encrypted with PEK (Password Encryption Key) - Some poeple sometimes refer to the RID here as a "salt".

    Moreover, when the password hashes are transported over the write between DSAs (Domain Controllers) they are still additionally encrypted by the RID, and here in fact salted and finally encrypted by the RPC Session key between the DSAs.

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

    Wednesday, December 3, 2014 5:51 AM
  • Thank you Pierre, I agree with the above but would like to add some comments.

    • Accounts with the option "smart card is required for interactive logon" do not apply the password expiration policy.

    In a Server 2008 R2 Domain the password will stop working once the expiration date is met.  Kerberos log in will still work, but users will get the password has expired notification when logging in and will be unable to use the password for network log on types and third party applications not using kerberos.

    • A user can change its password, or an admin can change the password of the user after enabling the option "smart card is required for interactive logon". Some "security" application even requires the password to be changed to be able to work with the account (3rd party applications, I don't have names on the top of my head).

    The user cannot change their password using smart card log on, but if they know their old and new password they can change it using ctrl+alt+delete as long as the old password has not expired.  Unless you give them additional permissions to modify their user object, an admin will need to do the inital password change after setting this option.  I see this as a good thing since it does not allow a known NTLM hash to be generated without admin rights.

    • Domain user's hashes are not stored in the local SAM of workstation or server. They might be cached via the cached credential functionality if enabled (it is by default, this allow a user to take its laptop home and still perform a local logon with its domain account). This could be disabled with the potential issues you might guess.

    In Server 2012 and Windows 8 they created some new security settings to prevent this from happening with admin accounts, but the SAM database does store the NTLM hash for authenticated users in prior versions.  Nothing can be done about keeping it in LSASS due to it being used for Single Sign On (SSO).

    • Cached Credential hashes are salted. Only local administrators can access them by default.

    Cached credentials are a salted hash of a hash.  They are also considered a different type of credentials.

    • Other type of credentials might be cached on a machine using the Credential Manager feature (when you checked the box "remember my password" while mapping a drive, or acceding to Internet resources).

    I would be interested in reading more about the details on this if you have a good source.  I have a hard time wrapping my head around all of this, especially when there are little tid bits here and there.

    • Hashes (as well as tickets, because the pass-the-hash that you might refer to is also possible with Kerberos - pass-the-ticket) are cached in the memory of the machine. Users with the privilege seDebugPrivilege can access to the memory. By default only local administrators can claim that privilege.

    Just to add to this, if the users password was "ever" changed after the user was set to "smart card required for interactive logon", the NTLM hash for that user can be generated with that password even when the password itself is no longer valid.  You would be able to get the hash without admin rights on anything.  Hopefully in Server 2012 they have fixed this by auto refreshing the NTLM hash at regular intervals.

    Thank you again for your time on this.  I know my above comments are more nit picking than anything.

    This is all starting to make more sense.




    Wednesday, December 3, 2014 6:34 AM
  • Hum, I think there are some confusions here. It might be me, so I'd rather clarify.

    You can't change the password without changing the NT hash. And the NT hash does not change by itself. Hopefully otherwise it would just break the authentication. When the smart card option is checked, it generates a random password hence a new hash, not just a new hash, it does generate a password which is not visible, that's it. We do not store the password of a domain user in Active Directory, we store its hash we can't change the first one without the other. If you want to change the hash, you change the password. The hash does not change automatically (on Windows Server 2012 gMSA accounts could be perceived an exception to this rule but there are a very specific scenario and this is still not a change of the hash but the generation of a random password hence a change of the hash).

    Credential Manager and Credential Locker documentations:


    On the domain controller
    , domain users information are exposed through the SAM API (and it is documented in here [MS-ADTS]: Active Directory Technical Specification and here [MS-SAMR]: Security Account Manager (SAM) Remote Protocol (Client-to-Server)).

    Local SAM does not store domain user hash. I don't understand your claim. Do you have a reference? Or a test which validate this?

    Things can be done for the hash or ticket in the LSASS memory and this is what the Restricted Admin function of Remote Desktop does (with its bunch of limitations).

    Risks and mitigation techniques for Pass-The-X are available on the Microsoft Cyber Security Blog: http://blogs.microsoft.com/cybertrust/2012/12/11/new-guidance-to-mitigate-determined-adversaries-favorite-attack-pass-the-hash/

    As far as I know, there is no way to dump hashes on a system without being a local administrator or elevating your privileges (to get the seDebugPrivilege or other privilege that can lead to enabling this one). We can debate about live debug, but this a bit off the topic.


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.





    Wednesday, December 3, 2014 1:43 PM
  • Hi,

    I just want to confirm what is the current situation.

    Regards.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com

    Tuesday, December 9, 2014 3:03 AM