Dokumentation1.7. Zugangskontrolle
Die Verwaltung, welche Art von Zugriff (Lesen, Schreiben usw.) Benutzern auf Ressourcen gewährt werden soll, wird als bezeichnet
Zugangskontrolle. Die beteiligten Konfigurationsanweisungen werden als Zugriffskontrolllisten oder ACL bezeichnet.
Als wir das slapd-Paket installierten, wurden verschiedene ACL automatisch eingerichtet. Wir werden uns einige wichtige Konsequenzen dieser Standardeinstellungen ansehen und dabei eine Vorstellung davon bekommen, wie ACLs funktionieren und wie sie konfiguriert sind.
Um die effektive ACL für eine LDAP-Abfrage zu erhalten, müssen wir uns die ACL-Einträge der abgefragten Datenbank sowie die der speziellen Frontend-Datenbankinstanz ansehen. Die zu letzteren gehörenden ACLs fungieren als Standardwerte für den Fall, dass die ACLs der ersteren nicht übereinstimmen. Die Frontend-Datenbank ist die zweite, die konsultiert wird, und die anzuwendende ACL ist die erste, die zwischen diesen beiden ACL-Quellen übereinstimmt („erste Übereinstimmung gewinnt“). Die folgenden Befehle geben jeweils die ACLs der mdb-Datenbank („dc=example,dc=com“) und die der Frontend-Datenbank an:
sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcDatabase={1}mdb)' olcAccess
dn: olcDatabase={1}mdb,cn=config
olcAccess: {0}zu attrs=userPassword durch Selbstschreiben durch anonyme Authentifizierung durch * keine olcAccess: {1}zu attrs=shadowLastChange durch Selbstschreiben durch * Lesen
olcAccess: {2}to * by * read
Der RootDN hat immer volle Rechte an seiner Datenbank und muss nicht in eine ACL aufgenommen werden.
sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcDatabase={-1}frontend)' olcAccess
dn: olcDatabase={-1}frontend,cn=config
olcAccess: {0}zu * von dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
,cn=auth manage by * break
olcAccess: {1}to dn.exact="" by * read
olcAccess: {2}to dn.base="cn=Subschema" by * read
Die ersten beiden ACLs sind entscheidend:
olcAccess: {0}zu attrs=userPassword durch Selbstschreiben durch anonyme Authentifizierung durch * keine olcAccess: {1}zu attrs=shadowLastChange durch Selbstschreiben durch * Lesen
Dies kann zur leichteren Verdauung unterschiedlich dargestellt werden:
zu attrs=userPassword
durch selbst schreiben
durch anonyme Authentifizierung durch * keine
zu attrs=shadowLastChange durch Selbstschreiben
von * gelesen
Diese ACLs erzwingen Folgendes:
• Es wird anonymer „Auth“-Zugriff bereitgestellt Benutzer-Passwort Attribut, damit Benutzer sich authentifizieren können, oder binden. Möglicherweise widerspricht es der Intuition, dass „durch anonyme Authentifizierung“ auch dann erforderlich ist, wenn ein anonymer Zugriff auf das DIT unerwünscht ist. Andernfalls wäre dies ein Henne-Ei-Problem: Vor der Authentifizierung sind alle Benutzer anonym.
• Das durch selbst schreiben ACL gewährt Schreibzugriff auf die Benutzer-Passwort Attribut für Benutzer, die sich als authentifiziert haben dn wo das Attribut lebt. Mit anderen Worten: Benutzer können die aktualisieren Benutzer-Passwort Attribut ihrer eigenen Einträge.
• Das Benutzer-Passwort Ansonsten ist das Attribut für alle anderen Benutzer nicht zugänglich, mit Ausnahme des RootDN, der immer Zugriff hat und nicht explizit erwähnt werden muss.
• Damit Benutzer ihr eigenes Passwort ändern können, verwenden Sie passwd oder andere Dienstprogramme, die dem Benutzer gehören SchattenLastChange Das Attribut muss beschreibbar sein. Alle anderen Verzeichnisbenutzer können den Inhalt dieses Attributs lesen.
Dieses DIT kann anonym durchsucht werden, da in dieser ACL „to * by * read“ steht, die jedem (auch anonym) Lesezugriff auf alles andere gewährt:
zu *
von * gelesen
Wenn dies unerwünscht ist, müssen Sie die ACLs ändern. Um die Authentifizierung während einer Bindungsanforderung zu erzwingen, können Sie alternativ (oder in Kombination mit der geänderten ACL) die Direktive „olcRequire: authc“ verwenden.
Wie bereits erwähnt, wird für die slapd-config-Datenbank kein Administratorkonto („rootDN“) erstellt. Es gibt jedoch eine SASL-Identität, die vollen Zugriff darauf gewährt. Es repräsentiert den Superuser des lokalen Hosts (root/sudo). Hier ist es:
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
Der folgende Befehl zeigt die ACLs der slapd-config-Datenbank an:
sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcDatabase={0}config)' olcAccess
dn: olcDatabase={0}config,cn=config
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred, cn=external,cn=auth manage by * break
Da es sich um eine SASL-Identität handelt, müssen wir eine SASL verwenden Mechanismus beim Aufrufen des betreffenden LDAP-Dienstprogramms, und wir haben es in diesem Handbuch schon oft gesehen. Es ist der EXTERNE Mechanismus. Ein Beispiel finden Sie im vorherigen Befehl. Beachten Sie, dass:
1. Sie müssen verwenden sudo zur Root-Identität werden, damit die ACL übereinstimmt.
2. Der EXTERNE Mechanismus funktioniert über IPC (UNIX-Domänen-Sockets). Dies bedeutet, dass Sie das verwenden müssen ldapi
URI-Format.
Eine prägnante Möglichkeit, alle ACLs abzurufen, sieht folgendermaßen aus:
sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcAccess=*)' olcAccess olcSuffix
Zum Thema Zugangskontrolle gibt es viel zu sagen. Siehe die Manpage für slapd.access4.