Entwicklungsumgebung/ACL Einrichtung
Diese Seite ist momentan eine Baustelle im Zustand: 1
-
0
-
1
-
2
-
3
-
4
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:
- defaultsearchbase hinzugefügt, damit erspart man sich die Eingabe einer searchbase bei den LDAP-Clients
- Monitor & Config Backend eingerichtet (rudimentär)
- 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.
- 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:
zwei zusätzliche Einträge gibt es noch.
- DomainAdmins dürfen dasselbe wie die Gruppe hadmin
- 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