-
Notifications
You must be signed in to change notification settings - Fork 329
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't connect with LDAP Signing / Channel Binding enabled #55
Comments
Is ldap channel binding set to required? That may cause the issue when connecting over TLS |
yes it is |
Interesting. I imagine this is a limitation of the ldap3 library since it doesn't support channel binding nor signing. I'd have to look if we can add it to that library. There isn't really another way to fix it. |
Where did this land? Noting that the project hasn't been updated for Bloodhound 4.x - I still use this from time to time and signing is currently breaking things., |
I'm also looking forward for a new version :) The "good" thing is, that Microsoft is still not enforcing signing and channel binding :D |
Hello - I came across this issue recently with the same error. I went searching through the ldap3 docs and if i'm reading this right there might be supporting for signing now but honestly don't understand this well enough to know, but just thought i'll share. https://ldap3.readthedocs.io/en/latest/ssltls.html?highlight=channel%20binding DEBUG: Authenticating to LDAP server |
While attacking an AD I stumbled over this topic too. In their case LDAPS was not allowed through the firewall but LDAP was for some reason. In addition only Kerberos was allowed here. And LDAP Signing was enforced. There are multiple open issues on this topic but no solution yet (besides using LDAPS which was not an option). Interestingly msldap is able to connect to LDAP (389) and perform the BIND that was denied to ldap3. Did not figure out yet how to modify ldap3 to perform the same handshake. Another option would be to use msldap (as an option) instead of ldap3 but not sure what is easier. |
This is still unsupported by ldap3. Since signing is not only used in the bind stage but with every ldap message sent, this would require quite some modifications to the library. Channel binding would probably be slightly easier, but since you can't use LDAPS then it's still the same problem. Switching out the core ldap library to a different one isn't exactly easy either, there would be additional dependencies and many things breaking probably. |
@dirkjanm I've been able to use ly4k version of ldap3 to work with impacket. I'm still having some trouble with bloodhound.py, but at least I got getTGT.py to work with Impacket. Here is the issue and links: Original Issue: fortra/impacket#884 |
From Bloodhound.py with ldap3.py from ly4k: # snippet
pyasn1.error.PyAsn1Error: <TagSet object, tags 0:32:16-64:32:30> not in asn1Spec: <AS_REP schema object, tagSet=<TagSet object, tags 0:32:16-64:32:11>, subtypeSpec=<ConstraintsIntersection object>, componentType=<NamedTypes object, types <NamedType object, type pvno=<Integer schema object, tagSet <TagSet object, tags 0:0:2-128:32:0>, subtypeSpec <ConstraintsIntersection object, consts <ValueRangeConstraint object, Impacket before using l4yk: getTGT.py 'domain.example/user1:Password' -dc-ip 192.168.1.1
# snippet
<TagSet object, tags 0:32:16-64:32:30> not in asn1Spec: <AS_REP schema object, tagSet=<TagSet object, tags 0:32:16-64:32:11>, subtypeSpec=<ConstraintsIntersection object>, componentType=<NamedTypes object, types <NamedType object, type pvno=<Integer schema object, tagSet <TagSet object, tags 0:0:2-128:32:0>, subtypeSpec <ConstraintsIntersection object, consts <ValueRangeConstraint object, Impacket after Ldap3.py from Ly4k: getTGT.py 'domain.example/user1:Password' -dc-ip 192.168.1.1
[*] Saving ticket in user1.ccache |
There's a PR which adds support for that, maybe that would help you in the right direction: #148 |
Edited: Disregard. I'm dumb and didn't see your PR from Bloodhound.py Let me try that. |
In case you stumbled onto this issue like me then maybe try sync your local machines clock with the LDAP server. |
Since I've enabled LDAP Signing on our Domain Controllers I'm no longer able to run bloodhound.py
Does anyone else have this issue too?
The text was updated successfully, but these errors were encountered: