optional attribute_name for user_search

stroeder commented 6 years ago

It would be nice if your module would not require to retrieve the user's DN as attribute in the user's entry. Because the DN is returned separately in search result anyway and not every LDAP server returns an operational attribute like this.

fschulze commented 6 years ago

Help with this is appreciated. Especially raw example data which can be used in tests.

justsh commented 5 years ago

I may be hitting this scenario now, which is strange, because I've been using devpi-ldap for about a year now without trouble. I'm not sure where this change occurred for me, possibly it changed in an update to my directory server?

I am currently querying against RHEL FreeIPA 4.5.x. The correct dn is returned on the ldap3.Connection.response, but not as an attribute. Adding a print function to the extract_search definitions in devpi_ldap/main.py shows the following:

[vagrant@localhost devpi]# devpi-ldap ./etc/ldap.yml 'user4'
Password:
2019-02-04 17:11:38,190 DEBUG NOCTX Validating user 'user4' against LDAP at ldap://freeipa45.test.local.
{ 'attributes': {'dn': []},
  'dn': 'uid=user4,cn=users,cn=accounts,dc=test,dc=local',
  'raw_attributes': {'dn': []},
  'raw_dn': b'uid=user4,cn=users,cn=accounts,dc=test,dc=local',
  'type': 'searchResEntry'}
2019-02-04 17:11:38,590 INFO  NOCTX No user 'user4' found.
Result: {"status": "unknown"}
No user named 'user4' found.

skyglobe commented 5 years ago

I have also hit this scenario and crafted a workaround here: https://github.com/skyglobe/devpi-ldap/commit/e68aee8b1b38a8707726a5da6781d55b41d3c19c

If it is ok I will send a pull request.

dedsm commented 4 years ago

I also lost around 4 hours getting to this, just changing the if order in the _search function to check for dn or distinguishedName first works as well

https://github.com/devpi/devpi-ldap/blob/master/devpi_ldap/main.py#L190

devpi / devpi-ldap

optional attribute_name for user_search #41