Aufbau LDAP Baum - Über ACL oder Verzeichnisse Lösen?
Aufbau LDAP Baum - Über ACL oder Verzeichnisse Lösen? Hi @all, ich bin gerade dabei all unsere Linux Systeme (SLES 9) auf LDAP umzustellen (Zentrale Benutzerauthentifizierung über LDAP). Beim meiner Plaung ist mir aufgefallen, dass es Redundante Daten gibt, User sind mehrfach vorhanden (Siehe Schaubild):http://www.imagegravy.com/myImages/1279/phpnx53As_full.jpg Erläuterung des Schaubilds: Es gibt verschiedene Linux-Rechner, auf einem dieser Rechner läuft der LDAP-Server, auf den anderen Läuft der LDAP Client. Neptun ist der Linux Rechner auf dem der LDAP-Master Deamon läuft. Mars und Jupiter sind Linux-Rechner auf denen der LDAP-Client läuft. Die ACLs in der slapd.conf auf der LDAP-Master Neptun sehen unter anderem folgender maßen aus: [code]### mars ### access to dn.subtree="ou=mars,o=neptun,c=de" by dn.base="cn=admin,o=neptun,c=de" write by peername.regex="192.168.0.101" read by * none ### jupiter ### access to dn.subtree="ou=jupiter,o=neptun,c=de" by dn.base="cn=admin,o=neptun,c=de" write by peername.regex="192.168.0.102" read by * none[/code] Die ldap.conf der einzelnen Systeme ist folgendermasen aufgebaut:[code]# This is the configuration file for the LDAP nameservice # switch library, the LDAP PAM module and the shadow package. # # Eintrage der Server. Master, Slave u.s.w. uri ldap://192.168.0.100 # The distinguished name of the search base. base o=neptun,c=de # The LDAP version to use (defaults to 3 ldap_version 3 nss_map_attribute uniqueMember uniquemember pam_filter objectclass=posixAccount nss_base_passwd ou=users,o=neptun,c=de nss_base_group ou=groups,o=neptun,c=de[/code] Das Problem bei dieser Konstellation, es gibt redundante Daten und wenn man eine Änderung an einem User vornimmt, wird es ziemlich mühselig falls er auf vielen Maschinen Definiert ist. Jetzt habe ich mir Überlegt, mein LDAP-Baum folgendermassen aufzubauen (siehe Schaubild): http://www.imagegravy.com/myImages/1279/php4gUF9z_full.png Hier habe ich den Vorteil, dass die User nur ein mal vorhanden sind. Aber nun stehe ich vor dem Problem, wie löse ich das mit den ACLs ? Also so, dass nicht jeder User auf jeder Maschine darf? Ist das nicht ein mega Aufwand für jeden User ALCs einzurichten? Es sind insgesamt etwas über 500 User, wenn ich jetzt für jeden User zwei bis drei ACLs einrichten muss, wird das Total unübersichtilich und der Aufwand wäre enorm. Hat mir jemand ein Tipp? Bzw. wie würdest ihr das Lösen? Gruß Merenda -- Echte DSL-Flatrate dauerhaft für 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl
On 3/16/06, luisa merenda
Aufbau LDAP Baum - Über ACL oder Verzeichnisse Lösen?
Hi @all,
ich bin gerade dabei all unsere Linux Systeme (SLES 9) auf LDAP umzustellen (Zentrale Benutzerauthentifizierung über LDAP). Beim meiner Plaung ist mir aufgefallen, dass es Redundante Daten gibt, User sind mehrfach vorhanden (Siehe Schaubild):http://www.imagegravy.com/myImages/1279/phpnx53As_full.jpg
Das ist krank, so was habe ich ja noch nie gesehen. Viel zu umständlich. Erläuterung des Schaubilds:
Es gibt verschiedene Linux-Rechner, auf einem dieser Rechner läuft der LDAP-Server, auf den anderen Läuft der LDAP Client. Neptun ist der Linux Rechner auf dem der LDAP-Master Deamon läuft. Mars und Jupiter sind Linux-Rechner auf denen der LDAP-Client läuft.
Die ACLs in der slapd.conf auf der LDAP-Master Neptun sehen unter anderem folgender maßen aus:
[code]### mars ### access to dn.subtree="ou=mars,o=neptun,c=de" by dn.base="cn=admin,o=neptun,c=de" write by peername.regex="192.168.0.101" read by * none
### jupiter ### access to dn.subtree="ou=jupiter,o=neptun,c=de" by dn.base="cn=admin,o=neptun,c=de" write by peername.regex="192.168.0.102" read by * none[/code] Die ldap.conf der einzelnen Systeme ist folgendermasen aufgebaut:[code]# This is the configuration file for the LDAP nameservice # switch library, the LDAP PAM module and the shadow package. #
# Eintrage der Server. Master, Slave u.s.w. uri ldap://192.168.0.100
# The distinguished name of the search base. base o=neptun,c=de
# The LDAP version to use (defaults to 3 ldap_version 3
nss_map_attribute uniqueMember uniquemember
pam_filter objectclass=posixAccount
nss_base_passwd ou=users,o=neptun,c=de nss_base_group ou=groups,o=neptun,c=de[/code]
Das Problem bei dieser Konstellation, es gibt redundante Daten und wenn man eine Änderung an einem User vornimmt, wird es ziemlich mühselig falls er auf vielen Maschinen Definiert ist.
Jetzt habe ich mir Überlegt, mein LDAP-Baum folgendermassen aufzubauen (siehe Schaubild): http://www.imagegravy.com/myImages/1279/php4gUF9z_full.png
Schon besser, aber den Ast mit den Hostnamen würde ich weglassen. Soweit ich weiss, unterstützt pam_ldap doch das "host"-Attribut. D.h., zu jedem User-Object fügst Du ein Attribut "host=hostname" hinzu und pam_ldap sorgt dann dafür, dass sich der User nur auf diesem Host einloggen kann. Das host-Attribut kann auch mehrfach auftreten. Hier habe ich den Vorteil, dass die User nur ein mal vorhanden sind. Aber
nun stehe ich vor dem Problem, wie löse ich das mit den ACLs ? Also so, dass nicht jeder User auf jeder Maschine darf? Ist das nicht ein mega Aufwand für jeden User ALCs einzurichten? Es sind insgesamt etwas über 500 User, wenn ich jetzt für jeden User zwei bis drei ACLs einrichten muss, wird das Total unübersichtilich und der Aufwand wäre enorm. Hat mir jemand ein Tipp? Bzw. wie würdest ihr das Lösen?
Mit dem "host"-Attribut wie oben beschrieben. Die ACL's können dabei recht freizügig sein, solange das "userpassword"-Attribut (oder wo immer das Passwort drin steht) geschützt bleibt. Ich habe z.B. die folgende ACL bei uns drin: access to attr=userpassword by self =wcx by group="cn=administrators,..." write by anonymous auth by * none Der Rest ist frei lesbar von allen ("by * read"), da stehen ja i.A. keine Geheimnisse drin. Gruss, Karsten.
Von: "Karsten Künne"
Das ist krank, so was habe ich ja noch nie gesehen. Viel zu umständlich. Ja du hast recht deswegen wollte ich es ja ändern.
Schon besser, aber den Ast mit den Hostnamen würde ich weglassen. Soweit ich weiss, unterstützt pam_ldap doch das "host"-Attribut. D.h., zu jedem User-Object fügst Du ein Attribut "host=hostname" hinzu und pam_ldap sorgt dann dafür, dass sich der User nur auf diesem Host einloggen kann. Das host-Attribut kann auch mehrfach auftreten. Danke für den Tip :) Ich habs gefunden, dass ist genau das was ich gesucht habe! Aber irgendwie funkt das mit :( Ich hab dem User ldap_user1 über phpLDAPadmin das Attribut "host" hinzugefügt. Dem Attribut habe ich dann einen Maschinen Namen angefügt mars. Auf in der ldap.conf der Maschine mars habe ich dann folgenden eintrag eingestellt:
pam_check_host_attr yes Wenn ich dann mit getent passwd eine Abfrage starte, werden mir trozdem alle User angezeigt, was mache ich falsch?
Mit dem "host"-Attribut wie oben beschrieben. Die ACL's können dabei recht freizügig sein, solange das "userpassword"-Attribut (oder wo immer das Passwort drin steht) geschätzt bleibt. Ich habe z.B. die folgende ACL bei uns drin:
access to attr=userpassword by self =wcx by group="cn=administrators,..." write by anonymous auth by * none
Der Rest ist frei lesbar von allen ("by * read"), da stehen ja i.A. keine Geheimnisse drin. Jupp, hab ich jetzt auch so eingestellt.
Gruss, Karsten. Danke und Gruß Luisa Merenda
-- Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer
On 3/17/06, luisa merenda
Von: "Karsten Künne"
Das ist krank, so was habe ich ja noch nie gesehen. Viel zu umständlich. Ja du hast recht deswegen wollte ich es ja ändern.
Schon besser, aber den Ast mit den Hostnamen würde ich weglassen. Soweit ich weiss, unterstützt pam_ldap doch das "host"-Attribut. D.h., zu jedem User-Object fügst Du ein Attribut "host=hostname" hinzu und pam_ldap sorgt dann dafür, dass sich der User nur auf diesem Host einloggen kann. Das host-Attribut kann auch mehrfach auftreten. Danke für den Tip :) Ich habs gefunden, dass ist genau das was ich gesucht habe! Aber irgendwie funkt das mit :( Ich hab dem User ldap_user1 über phpLDAPadmin das Attribut "host" hinzugefügt. Dem Attribut habe ich dann einen Maschinen Namen angefügt mars. Auf in der ldap.conf der Maschine mars habe ich dann folgenden eintrag eingestellt:
pam_check_host_attr yes
Wenn ich dann mit getent passwd eine Abfrage starte, werden mir trozdem alle User angezeigt, was mache ich falsch?
Das ist ja auch richtig so, die User sind alle bekannt, aber sie sollten sich nicht einloggen können, wenn sie nicht den Host im host-Attribut haben. Das sind zwei verschiedene Mechanismen . Das getent-Programm benutzt den Namensdienst, der mit nsswitch.conf eingestellt wird und kümmert sich nicht um das host-Attribut. Beim Login wird der PAM-Mechanismus benutzt, d.h., die pam_ldap-Library guckt nach dem host-Attribut und lässt den Benutzer nur rein, wenn der Wert des host-Attributs mit dem Hostnamen übereinstimmt. I.A. ist das auch das, was man haben will. Es gibt auch noch eine andere Möglichkeit, mit sogenannten "+"-Einträgen in /etc/passwd. Dazu musst Du in /etc/nsswitch.conf folgendes eintragen: ... passwd: compat passwd_compat: ldap .... und dann in /etc/passwd auf jedem Host: .... +user1 +user2 ... usw.. Das würde dann den entsprechenden Effekt haben, dass alle User, die keinen "+"-Eintrag haben, auf dem Host auch nicht bekannt sind und von getent nicht angezeigt werden. Der Nachteil ist allerdings, dass man dann die /etc/passwd-Files auf jedem Host pflegen muss. Das widerspricht irgendwie der zentralisierten Benutzerverwaltung durch LDAP. Gruss, Karsten.
participants (2)
-
Karsten Künne -
luisa merenda