![](https://seccdn.libravatar.org/avatar/c0546552edcd1efb2997fd3796ed13ff.jpg?s=120&d=mm&r=g)
--- Ursprüngliche Nachricht --- Von: "Dieter Kluenter"
Sehr löblich!
DANKE schön :)
Du kannst doch nicht einfach meinen rootDSE klauen :-)
Keine sorge ist nur für Testzwecken ;) Oh, jetzt weiß ich erst mit wem ich es hier zu tun habe. Es ist mir wirklich eine Ehre. Sehr gutes Buch übrigens !
Ich weiss nicht, welche OpenLDAP Version du verwendest, aber die aktuelle hat auch das referential integrity overlay, mit man solche Spielchen einfacher lösen kann.
Für den Test verwende ich gerade die Version 2.1.4 auf einer SLES8 Maschiene. Die Produktion soll aber nach weiteren Tests auf einer SLES9 Maschine mit OpenLDAP 2.2.6 Laufen.
Denke einmal darüber nach, was denn dn.base bedeuten könnte. Als Hinweis man slapd.access(5) Du möchtest doch sicher den Scope subtree durchsuchen lassen.
Nach deinem Tipp hat es gefunzt, THX. Ich hab es folgender Massen gelöst: access to dn="ou=users,ou= einkauf,o=avci,c=de" by peername=127.0.0.1 read by peername=10.206.157.86 read by * none access to dn="ou=users,ou=verkauf,o=avci,c=de" by peername=127.0.0.1 read by peername=10.206.157.87 read by * none
Ein anderer Lösungsansatz wären Access Regeln mittels Sets.
http://www.openldap.org/faq/data/cache/1133.html Das klingt komplizierter als es wirklich ist.
Hm... Sieht interessant aus, werde ich mir bei Gelegenheit anschauen. Aber ich denke ich werde es erstmal so lösen wie oben beschrieben. Gruß Merenda Luisa -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++