Open corsch opened 4 years ago
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
WARNING: LDAP Authentication is refused because LDAP signing is enabled. Trying to connect over LDAPS instead...
DEBUG: Authenticating to LDAP server
ERROR: Failure to authenticate with LDAP! Error 80090346: LdapErr: DSID-0C0906B5, comment: AcceptSecurityContext error, data 80090346, v4563
Traceback (most recent call last):
File "/usr/local/bin/bloodhound-python", line 8, in
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: https://github.com/fortra/impacket/issues/884 PR: https://github.com/fortra/impacket/pull/1652 Repository: https://github.com/ly4k/ldap3
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: https://github.com/dirkjanm/BloodHound.py/pull/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.
Sudo ntpdate -s
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?