optional attribute_name for user_search

[stroeder]

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]

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

[justsh]

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]

I have also hit this scenario and crafted a workaround here: skyglobe@e68aee8

If it is ok I will send a pull request.

[dedsm]

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