get_user_groups() iterates over connection.response instead of connection.entries
ry99 opened this issue · comments
I'm trying to authenticate against Active Directory, but when the search completes, connection.response is iterated over instead of connection.entries. Unfortunately, AD (or maybe just my administrator?) appears to return some cruft in connection.response which causes the logic into an exception, and fails to authenticate anyone. My connection.response looks like this:
{'type': 'searchResEntry', 'raw_attributes': {}, 'dn': ..., 'attributes': {}}
{'type': 'searchResEntry', 'raw_attributes': {}, 'dn': ..., 'attributes': {}}
{'type': 'searchResEntry', 'raw_attributes': {}, 'dn': ..., 'attributes': {}}
{'uri': ["b'ldap://ForestDnsZones...'"], 'type': 'searchResRef'}
{'uri': ["b'ldap://DomainDnsZones...'"], 'type': 'searchResRef'}
Obviously, the last two items fail during the iteration because they have no attributes key, and even if they did, no dn key. Connection.entries just has the groups.
At the moment, I'm working around this by not fetching groups, but that's a problem long-term.
It looks like something close to PR #5 is needed here. Or Is there some other way I should specify my search? Can you add a check to see if there is an attributes key before referencing it? Please advise.
Just spent about 30 minutes looking at the best solution to this problem. Looks like connection.entries
isn't really a solution. ldap3
authors say
Entries found in search are returned also in connection.entries as abstract.entry objects. This can be helpful when you use the ldap3 library from the interpreter prompt.
Implying they're the same as what is returned in the connection.response
.
I really want to re-write parts of this library to better use ldap3 library, but obviously this will introduce many breaking changes.
For now i'm just going to go ahead with a slight modification #5, and we'll see how that goes.
I have now released this fix. Let me know if this resolves the problems for you.