Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of minfrin@sharp.fm designates
 72.32.122.20 as permitted sender)
Message-Id: <6E0320E9-0CF1-4051-8924-9E492EF29A41@sharp.fm>
From: Graham Leggett <minfrin@sharp.fm>
To: dev@httpd.apache.org
In-Reply-To: <1404e5911001251844q16c4dd24ie2493d1a6256b01@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: LDAP authentication: non-anonymous bind
Date: Tue, 26 Jan 2010 14:06:34 +0200
References: <20100125130009.5fdbf39c@erker>
 <1404e5911001251844q16c4dd24ie2493d1a6256b01@mail.gmail.com>

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
--