On 3/16/06, luisa merenda <merenda@gmx.net> wrote:
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.