[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Proxying AD : troubles with the comma character
Emmanuel Lesouef wrote:
First of all, thanks for your answer and sorry for my late reply...
Le Wed, 01 Jul 2009 16:57:24 +0200,
Michael Ströder <michael@stroeder.com> a écrit :
It should work. You should provide more details:
- relevant excerpts of slapd.conf
Here it is (skipped unrelevant parts) :
moduleload back_ldap
moduleload back_meta
moduleload rwm
database meta
overlay rwm
back-meta has built-in rwm capabilities, you should not use the rwm
overlay with it.
suffix "dc=authentification,dc=crbn"
uri "ldap://dc1.crbn.intra/ou=ad,dc=authentification,dc=crbn";
"ldap://dc2.crbn.intra";
suffixmassage "ou=ad,dc=authentification,dc=crbn"
"ou=CRBN,dc=crbn,dc=intra"
rwm-rewriteEngine on
rwm-map attribute uid sAMAccountname
rwm-map objectclass inetOrgPerson user
rwm-rewriteContext bindDN
rwm-rewriteRule "(.+)2C(.+)" "$1\,$2"
same as above; use the above commands without the "rwm-" prefix.
In any case, "CN=DUPONT\, Harry, OU=DSI, OU=CRBN, DC=crbn,DC=intra" and
"CN=DUPONT\2C Harry, OU=DSI, OU=CRBN, DC=crbn,DC=intra" are perfectly
equivalent from an LDAP point of view. If AD does not recognize this,
then it's broken.
If you want back-meta to map "\2C" into "\," you need to use
database meta
suffix "dc=virtual"
uri "ldap://:9011/dc=virtual";
rewriteEngine on
rewriteContext searchResult
rewriteRule "^(.+,)?dc=real$" "$1dc=virtual"
rewriteContext searchAttrDN alias searchResult
rewriteContext matchedDN alias searchResult
rewriteContext referralDN alias searchResult
rewriteContext default
rewriteRule "^(.+,)?dc=virtual$" "$1dc=real"
rewriteRule "^(.*)\\\\2C(.*)$" "$1\\,$2"
See notes about escaping in slapd.conf(5) and slapd-meta(5) and
slapo-rwm(5).
uri "ldap://mail.adl.crbn.fr/ou=adl,dc=authentification,dc=crbn";
suffixmassage "ou=adl,dc=authentification,dc=crbn"
"dc=adl,dc=crbn,dc=fr"
uri "ldap://mail.adl.crbn.fr/ou=lycees,dc=authentification,dc=crbn";
suffixmassage "ou=lycees,dc=authentification,dc=crbn" "dc=lycee"
- which LDAP client is doing what (try to reproduce the issue with
OpenLDAP's command-line client)
The result is the same with ldapsearch and with ldapbrowser (java
client v2.8.2).
- how does the AD entry look like
Here is an example of an OpenLDAP entry (skipped some attributes not in openldap schema) :
dn: cn=DUPONT\, Harry, ou=DSI, ou=ad, dc=authentification,dc=crbn
^^^ this is a VERY UNFORTUNATE naming convention, as "," is a special
char in DN. The real fix would be to change it into something less
braindead.
mail: h.dupont@crbn.fr
objectGUID:: YBJCaXTvv73vv71C77+9IO+/ve+/ve+/vXvvv73vv70=
uid: dupont_h
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
company: DSI
name: DUPONT, Harry
sn: DUPONT
telephoneNumber: 9042
cn: DUPONT, Harry
title: Reprographe
homeDirectory: \\gamelle\users$\dupont_h
givenName: Harry
displayName: DUPONT Harry
userPrincipalName: dupont_h@crbn.intra
distinguishedName: cn=DUPONT\2C Harry,ou=DSI,ou=ad,dc=authentification,dc=crbn
And here is the original AD entry :
dn: CN=DUPONT\, Harry, OU=DSI, OU=CRBN, DC=crbn,DC=intra
mail: h.dupont@crbn.fr
objectGUID:: YBJCaXTvv73vv71C77+9IO+/ve+/ve+/vXvvv73vv70=
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
company: DSI
name: DUPONT, Harry
sn: DUPONT
telephoneNumber: 9042
cn: DUPONT, Harry
title: Reprographe
homeDirectory: \\gamelle\users$\dupont_h
givenName: Harry
displayName: DUPONT Harry
userPrincipalName: dupont_h@crbn.intra
distinguishedName: CN=DUPONT\, Harry,OU=DSI,OU=CRBN,DC=crbn,DC=intra
sAMAccountName: dupont_h
Notice the distinguishedName in the two examples... It is not rewriten, but it's another question...
That's because slapd knows nothing about the "distinguishedName"
attribute, as it's not standard track. If you define it as a DN-valued
attribute, then back-meta can rewrite it, as soon as you instruct it to
do so (e.g. by using the "suffixmassage" directive).
p.