inejge
Support authentication with NT hash in NTLM auth flow
With NTLM authentication, it is technically not necessary to possess the cleartext password. Since the challenge-response scheme is solved with the NT hash of the password instead of its cleartext value, it is sufficient to know the NT hash.
It would be awesome if ldap3 would support connection establishment with a known NT hash instead of a password.
Use cases:
- Someone might be hesitant to store a cleartext password somewhere and would like to do it with the hash instead.
- In penetration testing, it is common to get access to an NT hash and assessment tools need support for that. For example https://github.com/g0h4n/RustHound-CE/issues/5
NTLM handling in the library is very experimental, and may not even end up in the released code, depending on how extensive the support for other things (like channel bindings) is going to be. NT hashes are hence a very low priority. I'll keep the issue open until I decide what's going to happen to NTLM support as a whole.
Okay, thanks for the fast response. I think it would also be fine to have basic NTLM auth support first and then gradually improve over time. Maybe people will conduct PRs if they require a missing feature like LDAP signing, channel binding or NT hash support.
But in general, I would consider NTLM auth support an important feature. In many cases the LDAP implementation will be Active Directory and NTLM is often required there.
NTLM is dead and has been deprecated for a very long time. What is the reason to support it?
NTLM is dead and has been deprecated for a very long time. What is the reason to support it?
You are right that NTLM has been deprecated and it is definitely recommended to authenticate via Kerberos in Active Directory environments.
However, NTLM is still very common and enabled in most AD environments. And there are use-cases where NTLM support in a tool is crucial.
One example (where I come from) is the case of Active Directory security testing (penetration testing / red teaming). In such engagements, it might happen that you, as a security tester, are able to acquire the NT password hash of another account. And since NTLM authentication can be performed when knowing the NT hash (pass-the-hash) it becomes very useful when whatever tool you want to use next supports that. (In this particular case, the issue came up with RustHound-CE, an AD information gathering tool.)
NTLM is dead and has been deprecated for a very long time. What is the reason to support it?
You are right that NTLM has been deprecated and it is definitely recommended to authenticate via Kerberos in Active Directory environments.
However, NTLM is still very common and enabled in most AD environments. And there are use-cases where NTLM support in a tool is crucial.
One example (where I come from) is the case of Active Directory security testing (penetration testing / red teaming). In such engagements, it might happen that you, as a security tester, are able to acquire the NT password hash of another account. And since NTLM authentication can be performed when knowing the NT hash (pass-the-hash) it becomes very useful when whatever tool you want to use next supports that. (In this particular case, the issue came up with RustHound-CE, an AD information gathering tool.)
I see, but what about mimikatz?
I see, but what about mimikatz?
mimikatz is exactly one of the tools that could get you an NT hash. But this issue here is about support for using this hash afterwards to perform NTLM authentication over the network. This would be useful to have in different tools. The scope here of course are tools utilizing the ldap3 library. And RustHound-CE is one of such tools. It serves a completely different purpose than mimikatz.
I see, but what about mimikatz?
mimikatz is exactly one of the tools that could get you an NT hash. But this issue here is about support for using this hash afterwards to perform NTLM authentication over the network. This would be useful to have in different tools. The scope here of course are tools utilizing the ldap3 library. And RustHound-CE is one of such tools. It serves a completely different purpose than mimikatz.
I see what you are after. One might look onto curl's NTLM type 1 and type 3 message impl as a start.
+1 for this
It's a pretty common scenario in pentesting that you only have the NTHASH and can't obtain the plaintext password.
This is an issue for RustHound-CE where the only solution is to use a different tool written in python that supports this.
It's very useful for any pentesting tool that interacts with ldap to support this
Since the channel binding PR has been accepted in sspi-rs, the future of NTLM support in ldap3 is clearer to me.
First of all, I will include NTLM in the next release. The supported options are not as extensive as with Kerberos, but the following will be possible:
-
Authentication with a plain password on a non-TLS connection, with no signing/sealing.
-
Authentication with a plain password on a TLS connection, with automatic channel binding support.
(1) means that connections to AD instances which enforce LDAP signing won't work. I don't plan to work on that option. I might accept a PR, but open an issue before doing it, as there are several requirements to be met. Don't open an issue just to request the feature.
Authenticating with an NT hash must be supported by sspi-rs before it's done in ldap3. I'm not going to pursue this myself. Therefore, if you need that feature, take it up with sspi-rs developers first, then reopen this issue, or make a PR and reference the issue.
First of all, I will include NTLM in the next release.
Thank you :)
Authenticating with an NT hash must be supported by sspi-rs before it's done in ldap3. I'm not going to pursue this myself. Therefore, if you need that feature, take it up with sspi-rs developers first
You are right. And this is already tracked in https://github.com/Devolutions/sspi-rs/issues/472