LDAP Problem and Solution and Recommendation for openLDAP/RHDS/Open-389/

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Enable LDAP
2. Enter ambiguous fields "ldap_suffix" "ldap_domain_dn"
3. Attempt to authenticate using "username"

What is the expected output? What do you see instead?
Authenticaion

What version of the product are you using?
2.1.2

On what operating system? With what Browser (IEx, FFx, ...)
Server on RHEL, Browser Firefox on FC16.

Please provide any additional information below.

I struggled with getting LDAP to work. I had to inspect the source code and 
inspect the LDAP server log files. Here is the problem.

First, without understanding the actual LDAP query that is built, I am fairly 
sure that the Settings->LDAP->"LDAP Base dn of your domain" is not even being 
used. If you were to follow the mouseover instructions and populate the other 
two fields with something like this:

LDAP account suffix for your domain: @ou=People,dc=example,dc=com
LDAP array of domain controllers: ldap01.example.com,ldap01.example.com  

Then try to authenticate with user, "typedeaf".
The query to the LDAP server would look like this:

[02/Feb/2012:19:26:50 -0500] conn=548345 fd=126 slot=126 connection from 
10.1.2.3 to 10.4.5.6
[02/Feb/2012:19:26:50 -0500] conn=548345 op=0 BIND 
dn="typedeaf@ou=People,dc=example,dc=com" method=128 version=3
[02/Feb/2012:19:26:50 -0500] conn=548345 op=0 RESULT err=32 tag=97 nentries=0 
etime=0
[02/Feb/2012:19:26:50 -0500] conn=548345 op=1 UNBIND
[02/Feb/2012:19:26:50 -0500] conn=548345 op=1 fd=126 closed - U1

Okay. So there is the problem. That will never work with an '@' character in 
there. And, the relative dn (RDN) is not even being built. Also, clearly, the 
base dn is not being used for anything. You will get "error 32" when you try 
this, which of course means nothing without a lookup string table.

The easiest fix for this is to realize that the 'Account' field has changed 
context when enabling LDAP. What should go in there is the RDN for the user. So 
if you use the POSIX "uid' attr, then you would type, "uid=typedeaf", in the 
Account field. That fixes half the problem. The other part is to simply remove 
the '@' char from the account suffix setting and ensure that it is the full 
path to your users container. In my case, it already is the full path to the 
People ou under the root suffix. 

The harder fix is to modify the PHP source to build the query properly.

Recommendations:
1) Add a setting in the LDAP section for the RDN key, such as "uid" or "cn" so 
that it builds the RDN properly off the username. ex. "uid=$username"

2) This will only work for simple DITs. Supposing that the user might not 
always be under the same path, the search will fail. This is where the unused 
field "LDAP base dn" should be used. This should be the base of a LDAP search 
query. Such as SRCH base="dc=something,dc=example,dc=com" scope=2 
filter="(&(objectClass=posixAccount)(uid=typedeaf))". So, search the DIT given 
the RDN and a base to search, and then build the BIND query off the search 
results. 

Original issue reported on code.google.com by typede...@gmail.com on 3 Feb 2012 at 5:13

[GoogleCodeExporter]

Oh, I forgot to the most important thing. The PHP LDAP lib is adLdap. Why? 
Isn't this an Open solution that is more likely to end up on a LAMP stack? Why 
don't you use a standard LDAP lib?

http://www.php.net/manual/en/book.ldap.php

If I get time, I will re-write the adLdap parts and submit the patch. Would you 
accept that?

Original comment by typede...@gmail.com on 3 Feb 2012 at 6:44

[GoogleCodeExporter]

Yes sure ... I'm open to any modification ;-)

Original comment by nils.cpa...@gmail.com on 5 Feb 2012 at 5:51

[GoogleCodeExporter]

Any update on this? I'm looking at a similar scenario

Original comment by mikeym...@gmail.com on 30 Mar 2012 at 4:59

[GoogleCodeExporter]

Same problem here. Nils, do you have a fix ?

Original comment by p...@vircio.com on 30 Oct 2012 at 9:32