On 26 Jan 2010, at 4:44 AM, Eric Covener wrote:
This new behaviour covers the two use cases described above (even
though I did
not check it in an Active Directory setup).
Patch is nice and simple, but it would be great if someone with AD
leanings could confirm that this combination of HTTP username,
attribute, and basedn is likely to result in something that can bind
in a typical AD install.
There are three possible scenarios for login:
- User provides username, auth_ldap server does a search within the
directory to find the DN corresponding to the username, and then
attempts to bind as that DN. If it succeeds, you're in. This usually
requires a DN of some kind to use to do the initial login to do the
original search. (AD works fine in this scenario, on condition you
have an account to bind and do the initial search with).
- User provides username, auth_ldap applies the username to an admin-
provided recipe of some kind to create the DN. This recipe needs to be
flexible enough to support various scenarios, such as the base URL for
the recipe being something other than the base URL for searches (think
group searches, a group might not have the same base DN as the person).
- User provides username, auth_ldap tries to bind directly with that
username without first converting it to a DN. This is how AD would work.
Ideally auth_ldap should support the above three methods, am I correct
in understanding that the patch implements the second option above? (I
don't have time to review it fully at the moment).
Regards,
Graham
--
