Hallo, bin gerade dabei mein LDAP - Server aufzusetzen bzw. er läuft schon ganz gut. Der LDAP - Server soll später zur Benutzer Authentifizierung dienen. Ich hab schon ein paar LDAP-User und diese Können sich auch auf dem LDAP-Server Authentifizieren. Für meine Tests habe ich zwei Abteilungen angelt: - Einkauf - Verkauf Mein Problem ist nur das ich diese Abteilungen auf verschiedene Clients Verteilen möchte. Ein ein Mitarbeiter vom Einkauf darf sich nicht auf dem Server vom Verkauf befinden und anders herum auch nicht. Heute habe ich das Problem über der der /etc/ldap.conf gelöst, in dem ich einfach auf den einzelnen Clients folgendes eingetragen habe: VERKAUF: /etc/ldap.conf: nss_base_passwd ou=verkauf,ou=users,o=avci,c=de nss_base_shadow ou=verkauf,ou=users,o=avci,c=de nss_base_group ou=verkauf,ou=users,o=avci,c=de EINKAUF: /etc/ldap.conf: nss_base_passwd ou=einkauf,ou=users,o=avci,c=de nss_base_shadow ou=einkauf,ou=users,o=avci,c=de nss_base_group ou=einkauf,ou=users,o=avci,c=de Für meine Tests war das ganz ok. Aber wenn ich das mal Produktiv einsetzen möchte, dann wird das wirklich lästig, dass auf jedem einzelnen Client zu verwalten. Ich hab jetzt im Netzt gelesen, dass man das auf dem LDAP-Server in der /etc/openldap/slapd.conf einstellen kann. Aber leider bekomme ich das nicht gebacken die Abteilungen zu trennen. Ich habe es Folgendermaßen versucht: LDAP-SERVER: /etc/openldap/slapd.conf: access to dn.base="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.base="ou=users,ou=verkauf,o=avci,c=de" by peername=127.0.0.1 read by peername=10.206.157.87 read by * none Wenn ich es dann mit "getent passwd" testen möchte bekomme ich keine User angezeigt. Was mache ich an der Berechtigungsfreigabe falsch ?! Danke schon mal für euere Hilfe Gruß Merenda -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++
Hallo,
"luisa merenda"
Hallo,
bin gerade dabei mein LDAP - Server aufzusetzen bzw. er läuft schon ganz gut. Der LDAP - Server soll später zur Benutzer Authentifizierung dienen. Ich hab schon ein paar LDAP-User und diese Können sich auch auf dem LDAP-Server Authentifizieren. Für meine Tests habe ich zwei Abteilungen angelt:
Sehr löblich!
Mein Problem ist nur das ich diese Abteilungen auf verschiedene Clients Verteilen möchte. Ein ein Mitarbeiter vom Einkauf darf sich nicht auf dem Server vom Verkauf befinden und anders herum auch nicht. Heute habe ich das Problem über der der /etc/ldap.conf gelöst, in dem ich einfach auf den einzelnen Clients folgendes eingetragen habe:
VERKAUF: /etc/ldap.conf:
nss_base_passwd ou=verkauf,ou=users,o=avci,c=de nss_base_shadow ou=verkauf,ou=users,o=avci,c=de nss_base_group ou=verkauf,ou=users,o=avci,c=de
Du kannst doch nicht einfach meinen rootDSE klauen :-)
EINKAUF: /etc/ldap.conf:
nss_base_passwd ou=einkauf,ou=users,o=avci,c=de nss_base_shadow ou=einkauf,ou=users,o=avci,c=de nss_base_group ou=einkauf,ou=users,o=avci,c=de
Für meine Tests war das ganz ok. Aber wenn ich das mal Produktiv einsetzen möchte, dann wird das wirklich lästig, dass auf jedem einzelnen Client zu verwalten. Ich hab jetzt im Netzt gelesen, dass man das auf dem LDAP-Server in der /etc/openldap/slapd.conf einstellen kann. Aber leider bekomme ich das nicht gebacken die Abteilungen zu trennen. Ich habe es Folgendermaßen versucht:
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.
LDAP-SERVER: /etc/openldap/slapd.conf:
access to dn.base="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.base="ou=users,ou=verkauf,o=avci,c=de" by peername=127.0.0.1 read by peername=10.206.157.87 read by * none
Wenn ich es dann mit "getent passwd" testen möchte bekomme ich keine User angezeigt. Was mache ich an der Berechtigungsfreigabe falsch ?!
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. 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. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:01443B53
Sehr hilfreich fanden wir auch die Ausgabe vom Linux-Magazin: https://www.linux-magazin.de/Artikel/ausgabe/2004/05 kann online bestellt werden, lohnt sich.
-- Mit freundlichen Grüßen Markus Feilner
-------------------------- Feilner IT Linux & GIS Linux Solutions, Training, Seminare und Workshops - auch Inhouse Beraiterweg 4 93047 Regensburg fon +49 941 9465243 fax +49 941 9465244 mobil + +49 170 3027092 skype ID: mfeilner mail: mfeilner@feilner-it.net
Hallo Markus, das war’s ! Ich hab mir gestern noch die Zeitschrift von einem Kollegen ausgeliehen. Da wird das Thema PAM wirklich sehr gut und ausführlich beschrieben. Und auch dank an alle die geschrieben haben. Gruß Luisa Merenda -- Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie! Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl
--- 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 +++
participants (2)
-
Dieter Kluenter
-
luisa merenda