Pennyw0rth
[Draft] POC ldap3 implementation for schannel authentication
POC for ldap3 implementation.
The main goal of this PR is to provide schannel authentication support to Netexec through ldap3 implementation.
Future improvements could be ldap signing and channel binding support (available on ldap3 dev branch at the moment). Great article about it here : https://offsec.almond.consulting/ldap-authentication-in-active-directory-environments.html
A workaround is possible right now to bypass channel binding with a fallback on port 389 and StartTLS, see another great article here : https://offsec.almond.consulting/bypassing-ldap-channel-binding-with-starttls.html. This code logic can be added into the actual code.
Another feature worth to consider is the pkinit function from Certipy.
The problem with ldap3 is that kerberos auth is not native, you need to manually install using apt or whatever libkrb5-dev krb5-config (it's not even default on kali). If you are on linux without admin rights, you just can't use kerberos anymore now and therefore netexec with kerberos
I get your point but not sure to understand if it will be a problem for this PR : I only replace the impacket.ldap import and the code is still using impacket.krb5 so this should be OK. I tested it on a fresh new debian VM without libkrb5-dev krb5-config packages and kerberos is working fine. Let me know if I miss something
I get your point but not sure to understand if it will be a problem for this PR : I only replace the impacket.ldap import and the code is still using impacket.krb5 so this should be OK. I tested it on a fresh new debian VM without libkrb5-dev krb5-config packages and kerberos is working fine. Let me know if I miss something
Ok, i read the code a little bit to fast then, if this is working without any additional package this is an awesome PR !
As you already wrote it into the title i converted the PR into a draft :)
And of course thanks for the PR! I will take a look at it when i got the time
I will update my PR and make modifications from the last netexec version. I guess the changes you pointed out were committed after my PR was sent because I can't remember touching these parts of the code. As suggested by mpgn on the discord, I will also update the PR format to match your last requirements :)
Regarding my code and more precisely the ldap section, the goal of the PR was to not use impacket.ldap anymore and to create a netexec ldap lib (based on ldap3) to handle ldap things. For the POC, I called it ldap3_patch (which is a bad name) just to search and replace ldap_impacket in the whole netexec code. Another approach could be taken, just let me know and I will update the PR in consequence.
As for git, I will ask you help for sure not to mess things up :D
Thanks for the explaination!
However, i think maintaining a patched version of an ldap library inside of NetExec is neither the right place, nor feasible to maintain in the future. This should be strictly seperated, to avoid conflicts or the need to repatch the file every time something in impacket gets updated or patched. Is this only possible with ldap3 at the moment or is there a counterpart in impacket?
From my point of view we have two options how to handle this:
- We implement the remaining features that are needed in impacket, using the ldap3 implementation as a guideline. This is probably the easiest way, because we would have to change NetExec only a little bit while providing the new feature to everyone who uses impacket.
- We switch to ldap3. This would probably require most of the ldap protocol to be rewritten, including all of the dependent features like modules or flags. Though, ldap3 seems not that great maintained (the last commit was 8 months ago). That option is probably more work intensive :D
My suggestion is, that we implement the features needed for cert auth and PR it. I can definitely help with that if i am needed
We switch to ldap3. This would probably require most of the ldap protocol to be rewritten, including all of the dependent features like modules or flags. Though, ldap3 seems not that great maintained (the last commit was 8 months ago). That option is probably more work intensive :D
not compatible with kerberos by default so not the best option ;)
@LightxR in a perfect world where the pr in impacket is merged quickly, is it possible to directly update impacket ldap implementation ?
Right now the POC is quite dirty as you still need to provide username and domain to be able to use the pfx certificate but the ldap module is already "usable" as is (and kerberos is working fine^^), there are still work regarding the ldap3 implementation : laps flag and some modules (get-userPassword.py, get-desc-users.py, groupmembership.py, get-unixUserPassword.py) have not been modified and don't work in consequence.
I completely agree on the fact that working on impacket librairy is a more solid choice because the tool is currently stable with it and had a recent nice PR regarding channel binding :) No sure if I am qualified to do the work on impacket but I will give it a try.
Hey,
Nice PR idea @LightxR, I'm currently struggling to read gMSA password using Netexec on a server where LDAPS is not accessible and this PR would make this possible by using Start TLS I guess.
@NeffIsBack & @mpgn Would https://github.com/skelsec/msldap also be a candidate to replace Impacket LDAP maybe ?
Regards.
Hey,
Nice PR idea @LightxR, I'm currently struggling to read gMSA password using Netexec on a server where LDAPS is not accessible and this PR would make this possible by using Start TLS I guess.
@NeffIsBack & @mpgn Would https://github.com/skelsec/msldap also be a candidate to replace Impacket LDAP maybe ?
Regards.
I have no problem to review and test the PR, but there is so many conflict with main branch that is starting to be archeology work :'(
Following the last conversation, I put on hold the work on ldap3 implementation and started looking for how it could be possible to add schannel support on impacket.ldap.
Hey, Nice PR idea @LightxR, I'm currently struggling to read gMSA password using Netexec on a server where LDAPS is not accessible and this PR would make this possible by using Start TLS I guess. @NeffIsBack & @mpgn Would https://github.com/skelsec/msldap also be a candidate to replace Impacket LDAP maybe ? Regards.
I have no problem to review and test the PR, but there is so many conflict with main branch that is starting to be archeology work :'(
Hi, gonna close this for now. If you made progress feel free to just reopen it 👍