Entwicklungsumgebung/ACL Einrichtung

Diese Seite ist momentan eine Baustelle im Zustand: 1

• 0

  Bearbeitung noch offen

• 1

  Bearbeitung übernommen

• 2

  Bearbeitung abgeschlossen

• 3

  Korrekturlesen abgeschlossen

• 4

  Fremdkorrektur abgeschlossen

Wird bearbeitet von: Harry

Hilfe zum Bearbeitungsstatus: Hilfe:Status eines Artikels

ACLs im Filesystem (für SAMBA und NFS)

Wir wollen, das die Gruppe der "Domänen Administratoren" volle Kontrolle erhält. Mitglieder dieser Gruppe sollen alle Dateien, in allen Freigaben bearbeiten und vor allem auch die Rechte setzen dürfen. Dazu setzen wir eine "Default-ACL" auf /home:

setfacl -R -m default:mask::rwx /home
setfacl -R -m default:group:domainadmins:rwx /home

ACLs im LDAP

Die Datei "slap-acl_0.1.tgz" enthält:

 -rw-r--r-- root/root       887 2009-04-12 22:11 ./root/new-teacher
 -rw-r--r-- root/root       887 2009-04-12 22:11 ./root/new-student
 -rwxr--r-- root/root       405 2009-04-05 17:01 ./root/user.sh
 -rw-r--r-- root/root      4491 2009-04-12 22:09 ./etc/ldap/slapd.conf
 -rw------- root/root      3439 2009-04-12 22:09 ./etc/ldap/slapd.acl-db1

Die Datei "slapd.conf" bitte vor dem Entpacken des Archivs sichern.

Änderungen in der slapd.conf:

1. defaultsearchbase hinzugefügt, damit erspart man sich die Eingabe einer searchbase bei den LDAP-Clients
2. Monitor & Config Backend eingerichtet (rudimentär)
3. Das "unique-overlay" hinzugefügt für die Attribute (Felder) "uid" und "cn". Die Vergabe von gleichen Namen für Personen, Accounts und Gruppen wird jetzt vom Server abgelehnt.
4. Auslagerung der ACLs in eine eigene Datei

Das Script "user.sh" legt für die Gruppen je einen Benutzer an:

Benutzer	Gruppe
        ha	hadmin
        ca	cadmin
        ta	tadmin
        ma	material
        fa	fachl

Achtung: Im LDAP wurde die Gruppe "Domain Admins" in "DomainAdmins" umbenannt!

Die Funktionalität sollte sein, wie hier beschrieben:

• http://www.arktur.th.schule.de/doku/samba.txt

zwei zusätzliche Einträge gibt es noch.

1. DomainAdmins dürfen dasselbe wie die Gruppe hadmin
2. In der Rolle "cn=admin,dc=delixs-schule,dc=de" eingetragene Benutzer erhalten Vollzugriff auf den LDAP-Baum.

Einrichtung der ACLs

Vorab sollten Sie einen "shell-alias" zum vereinfachten Suchen einstellen:

alias lds='ldapsearch -x -LLL '

Die geänderten Einträge im LDAP sehen so aus:

[root@alix ~]# lds cn=admin
dn: cn=admin,dc=delixs-schule,dc=de
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
roleOccupant: uid=root,ou=people,ou=accounts,dc=delixs-schule,dc=de

[root@alix ~]# lds cn=domainadmins
dn: cn=DomainAdmins,ou=groups,dc=delixs-schule,dc=de
objectClass: top
objectClass: posixGroup
objectClass: sambaGroupMapping
gidNumber: 512
cn: DomainAdmins
description: Netbios Domain Administrators
sambaSID: S-1-5-21-2105935012-446678297-1863235838-512
sambaGroupType: 2
displayName: Domain Admins
memberUid: dmax

Test der Rechte

Hier einige Kommandos zum Test

• "cadmin" darf Schüler hinzufügen

 ldapadd  -D uid=ca,ou=people,ou=accounts,dc=delixs-schule,dc=de -w schule -x -f new-student adding new entry "uid=new-s,ou=people,ou=accounts,dc=delixs-schule,dc=de"

• "hadmin" löscht Schüler

 ldapdelete -D uid=ha,ou=people,ou=accounts,dc=delixs-schule,dc=de -w schule -x uid=new-s,ou=people,ou=accounts,dc=delixs-schule,dc=de

• cadmin versucht einen Lehrer-Account zu erstellen, das wird aber verweigert

 ldapadd  -D uid=ca,ou=people,ou=accounts,dc=delixs-schule,dc=de -w schule -x -f new-teacher adding new entry "uid=new-t,ou=people,ou=accounts,dc=delixs-schule,dc=de"
 ldap_add: Insufficient access (50)
       additional info: no write access to entry

• "hadmin" erstellt neuen Lehrer Account

 ldapadd  -D uid=ha,ou=people,ou=accounts,dc=delixs-schule,dc=de -w schule -x -f new-teacher adding new entry "uid=new-t,ou=people,ou=accounts,dc=delixs-schule,dc=de"

• "hadmin" löscht Lehrer

 ldapdelete -D uid=ha,ou=people,ou=accounts,dc=delixs-schule,dc=de -w schule -x uid=new-t,ou=people,ou=accounts,dc=delixs-schule,dc=de

Zugriff auf das Passwort (userPassword) testen

• Ein Lehrer Account

 id dmax
 uid=1005(dmax) gid=1001(teacher) Gruppen=1001(teacher),1013(hadmin),512(DomainAdmins)

• Ein Schüler Account

 id mmax
 uid=1003(mmax) gid=1002(students) Gruppen=1002(students)

• anoymous hat keinen (lesenden) Zugriff auf das Passwort

 lds uid=ca userPassword
 dn: uid=ca,ou=people,ou=accounts,dc=delixs-schule,dc=de

• ca darf sein eigenes Passwort lesen

 lds -D uid=ca,ou=people,ou=accounts,dc=delixs-schule,dc=de -w schule uid=ca userPassword
 dn: uid=ca,ou=people,ou=accounts,dc=delixs-schule,dc=de
 userPassword:: e1NTSEF9bklTeVJGcG5Nc2R1NHRHTGw5eFFXVDhUL0tuZUhIR0Q=

• ca hat keinen Zugriff auf das Passwort von fa

 lds -D uid=ca,ou=people,ou=accounts,dc=delixs-schule,dc=de -w schule uid=fa userPassword
 dn: uid=fa,ou=people,ou=accounts,dc=delixs-schule,dc=de

• dito für das Passwort von dmax

 lds -D uid=ca,ou=people,ou=accounts,dc=delixs-schule,dc=de -w schule uid=dmax userPassword
 dn: uid=dmax,ou=people,ou=accounts,dc=delixs-schule,dc=de

• ha darf natürlich das Passwort von dmax lesen

 lds -D uid=ha,ou=people,ou=accounts,dc=delixs-schule,dc=de -w schule uid=dmax userPassword
 dn: uid=dmax,ou=people,ou=accounts,dc=delixs-schule,dc=de
 userPassword:: e1NTSEF9enJrR2NDcEpHQ0h6dVVGZXBtKzNHSXdSN3lITEJwZlo=

• ta darf das nicht, weil dmax ja ein Lehrer ist

 lds -D uid=ta,ou=people,ou=accounts,dc=delixs-schule,dc=de -w schule uid=dmax userPassword
 dn: uid=dmax,ou=people,ou=accounts,dc=delixs-schule,dc=de

• ta hat Zugriff auf ein Schülerpasswort

 lds -D uid=ta,ou=people,ou=accounts,dc=delixs-schule,dc=de -w schule uid=mmax userPassword
 dn: uid=mmax,ou=people,ou=accounts,dc=delixs-schule,dc=de
 userPassword:: e1NTSEF9dGhOLzBxWFBCNXBTSDN1bWZoVUN5U0ZSZ0c2RnNZUXU=

Anmerkung: Lesender Zugriff auf Passwörter ist generell natürlich nicht zu empfehlen. Zum Testen des Zugriffs aber durchaus brauchbar. Im Augenblick steht daher in den ACLs "write" als Zugriffsrecht, das wird später durch das restriktivere "wx" ersetzt. Damit ist dann nur noch "ändern" und "anmelden", aber nicht mehr "lesen" erlaubt.

Weblinks

• FAQ zum Thema sets: http://www.openldap.org/faq/data/cache/1133.html
• FAQ zum Thema sets: http://www.openldap.org/faq/data/cache/1134.html
• FAQ zum Thema manage: http://www.openldap.org/faq/data/cache/189.html

---

zurück | Hauptseite