LDAP search scope directive?
Hi, my current problem has already been discussed on this list -- here's a snippet from Nov 2004: "Ron Wahler" <ron@rovingplanet.com> asked:
It seems that one of our customers has a database in which it does Have duplicate users names, they were asking the following question:
"Would also like to know how LDAP handles duplicate user names (if the baseDN was set to O=ACME instead of OU=Users,O=ACME)"
If the basedn Is at the higher level there may be duplicates.
Kostas Kalevras <kkalev@noc.ntua.gr> replied:
Do you mean that there may be:
uid=user,o=acme and uid=user,ou=users,o=acme ?
If that is the case the solution is simple:
ldap ldap1{ basedn = "o=acme" scope = "one" } ldap ldap2{ basedn = "ou=users,o=acme" scope = "sub" }
authorize{ ldap1 ldap2 }
authenticate{ ldap1 }
The only problem is that a scope directive does not exist yet. Adding one will not be hard though if it is needed. If that is what is needed please open a bug request in bugs.freeradius.org.
Due to a reorganization of our LDAP tree, we will need to duplicate our 15.000+ account entries in a new, separate subtree, located below the old one. During migration (which will hopefully run overnight, but certainly take severeal hours), services should be kept running as good as possible. So I'm going to face exactly the situation described above. To make the LDAP search result unique,
ldap ldap1{ basedn = "o=acme" scope = "one" would do the job for me. Has such a directive been implemented?
Thanks, Martin -- Dr. Martin Pauly Fax: 49-6421-28-26994 HRZ Univ. Marburg Phone: 49-6421-28-23527 Hans-Meerwein-Str. E-Mail: pauly@HRZ.Uni-Marburg.DE D-35032 Marburg
As a workaround, put an ACL on the new subtree that blocks the radius server from seeing the entries. As a future solution, perhaps the ldap module can be enhanced to use uri's rather than filters. A search uri contains server name, filter and scope all in one package. LDAP uri's are already supported in the xlat module so adding support to rlm_ldap should be possible. Regards, Frank Ranner
-----Original Message----- From: freeradius-users-bounces+frank.ranner=defence.gov.au@lists.fre eradius.org [mailto:freeradius-users-bounces+frank.ranner=defence.gov.au@l ists.freeradius.org] On Behalf Of Martin Pauly Sent: Wednesday, 4 April 2007 01:41 To: freeradius-users@lists.freeradius.org Subject: LDAP search scope directive?
Hi,
my current problem has already been discussed on this list -- here's a snippet from Nov 2004:
"Ron Wahler" <ron@rovingplanet.com> asked:
It seems that one of our customers has a database in which it does Have duplicate users names, they were asking the following question:
"Would also like to know how LDAP handles duplicate user names (if the baseDN was set to O=ACME instead of OU=Users,O=ACME)"
If the basedn Is at the higher level there may be duplicates.
Kostas Kalevras <kkalev@noc.ntua.gr> replied:
Do you mean that there may be:
uid=user,o=acme and uid=user,ou=users,o=acme ?
If that is the case the solution is simple:
ldap ldap1{ basedn = "o=acme" scope = "one" } ldap ldap2{ basedn = "ou=users,o=acme" scope = "sub" }
authorize{ ldap1 ldap2 }
authenticate{ ldap1 }
The only problem is that a scope directive does not exist yet. Adding one will not be hard though if it is needed. If that is what is needed please open a bug request in bugs.freeradius.org.
Due to a reorganization of our LDAP tree, we will need to duplicate our 15.000+ account entries in a new, separate subtree, located below the old one. During migration (which will hopefully run overnight, but certainly take severeal hours), services should be kept running as good as possible. So I'm going to face exactly the situation described above. To make the LDAP search result unique,
ldap ldap1{ basedn = "o=acme" scope = "one" would do the job for me. Has such a directive been implemented?
Thanks, Martin
-- Dr. Martin Pauly Fax: 49-6421-28-26994 HRZ Univ. Marburg Phone: 49-6421-28-23527 Hans-Meerwein-Str. E-Mail: pauly@HRZ.Uni-Marburg.DE D-35032 Marburg
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (2)
-
Martin Pauly -
Ranner, Frank MR