On Thu, 08 Mar 2012 14:57:24 +0000, KeN Etter wrote:
> I have users in two OUs in eDirectory. I have a website that requires
> them to login. Created this using PHP and checking via LDAP. I could
> not figure out how to use ldap_bind and check both OUs in a single pass.
Short version: You're doing it wrong.
Longer version: In order to "log in" via LDAP, called a "bind", you
generally are going to have to supply two pieces of information. One is
the DN of the object you want to authenticate as. The other is that
object's password. Keeping this simple for the moment, let's assume
you're talking about User objects, and that nothing fancy like two factor
authentication or smart cards are in play here.
There are two kinds of LDAP bind operations, anonymous, and
authenticated. Anonymous is any bind where a password is not supplied.
Authenticated is a bind with a DN _and_ a valid password.
Generally, what you want to do is prompt the person for their username
and password. So they supply "bob" and "secret1". But "bob" is not an
LDAP DN, so you can't directly use it to authenticate/bind to verify the
What you do is bind to the LDAP server with an anonymous bind. Submit a
search using some reasonable base (tree root, or something lower down if
appropriate) with a search filter like "(&(objectclass=user)(cn=bob))",
and possibly a list of attributes to be returned (fullName, etc.).
You'll get back a return of 0 or more objects matching the search filter.
If 0, then there's no "bob" and you can error out ("no such user").
If 1, then you can proceed to attempt to authenticate using the returned
If more than one, you have a dilemma to resolve. You got back
cn=Bob,ou=Sales,o=Foo and cn=Bob,ou=Engineering,o=Foo. Which "bob" is the
right one? You can prevent this by requiring tree-wide unique user names.
Or you can prompt the user to pick which one is correct. Or you can throw
your hands in the air, run in circles, and fail.
Once you have resolved which unique DN represents user "bob", *then* you
can attempt to verify that the person has supplied the correct password
by doing an authenticated bind. Be careful here also to check that the
password supplied is not a null string, as *that* will succeed (it's
actually then an anonymous bind), leading to a security failing in your
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.novell.com
Please post questions in the forums. No support provided via email.