OpenLDAPs cn = config fügt einen separaten Benutzer für die Replikation von "olcDatabase = config, cn = config" hinzu.

315
elysch

Ich hoffe, ich stelle keine dumme Frage. Ich bin neu beim Erstellen meines eigenen LDAP-Dienstes.

Für meine reguläre mdb-Datenbank können problemlos mehrere Administratoren hinzugefügt werden. Da es ein olcSuffixAttribut enthält, können Sie eine neue Organisationseinheit hinzufügen, olcAccessRegeln und alles hinzufügen, sodass die Replikation für die Verwendung eines dedizierten Benutzers konfiguriert werden kann.

Ich habe jedoch keinen Weg gefunden, etwas Ähnliches zu tun, wenn ich die Konfiguration repliziere:

olcDatabase=config,cn=config

Ich kann nicht zum cn=configdn hinzufügen . Ich erhalte folgende Fehlermeldung:

could not add entry dn="ou=admins,cn=config" (line=825)

Irgendwelche Empfehlungen?

UPDATE 20180828

Hier füge ich mehr Details hinzu, was ich versucht habe.

Wenn ich versuche zu importieren, beschwert sich der Server:

# ldapadd -c -x -H "ldap://localhost" -D "cn=admin,cn=config" -W -f test.ldif Enter LDAP Password: adding new entry "ou=admins_group,dc=config" ldap_add: Server is unwilling to perform (53) additional info: no global superior knowledge  adding new entry "uid=u1,ou=admins_group,dc=config" ldap_add: Server is unwilling to perform (53) additional info: no global superior knowledge

Die Inhalte von test.ldif sind:

dn: ou=admins_group,dc=config objectClass: organizationalUnit ou: admins_group  dn: uid=u1,ou=admins_group,dc=config objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount objectClass: securityPrincipal uid: u1 cn: u1 sAMAccountName: u1 objectSid: u1 userPassword:: e1NTSEF9VVN6MVpuRmx5bWVmN2w5Tmp5WmJtb3duKzMwSEtXREc= shadowLastChange: 15969 shadowMin: 0 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 1300 gidNumber: 1300 homeDirectory: /home/admin/u1

Fast das gleiche, das ich benutze, um Benutzer zur mdb-Datenbank hinzuzufügen

0
Gibt es einen Rückkehr- oder Ursachencode, der den Fehler begleitet? Hogstrom vor 5 Jahren 0

1 Antwort auf die Frage

1
grawity

Dieser spezielle Fehler bedeutet, dass es keine Datenbank mit einem entsprechenden Präfix für die DNs Ihrer Einträge gibt. Denken Sie daran, dass das Konfigurations-Backend nicht verwendet cn=configwird dc=config. (dc würde bedeuten, dass es sich um eine DNS-Domänenkomponente handelt, die es nicht ist.)

Aber selbst wenn Sie das Präfix richtig erhalten, erhalten Sie nur einen anderen Fehler (Schema-Verletzung). Am Ende kann cn = config keine fremden Einträge haben, diese werden vom Backend erzwungen.

Die gute Nachricht ist, dass das Benutzerkonto nicht funktioniert hat unter cn = config zu sein, kann es überall in seinem jeder Datenbank. Weder die syncrepl- noch die olcAccess-Regeln kümmern sich im Geringsten darum, welches DN-Suffix Ihre Benutzer haben. Fügen Sie also einfach das Konto Ihrer mdb-Hauptdatenbank hinzu - oder verwenden Sie das vorhandene Konto erneut.

Dies ist zum Beispiel meine eigene Konfiguration:

dn: olcDatabase = config, cn = config olcAccess: bis dn.sub = "cn = config" durch dn = "cn = replica, ou = system, dc = beispiel, dc = org" gelesen von group = "cn = Administrators, ou = Groups, dc = Beispiel, dc = org" verwalten durch * keine pause ...

Solange sich der Benutzer am Server anmelden kann, können Sie ihn in ACLs auflisten und für die Replikation verwenden. ( In der Tat, Zertifikat oder SASL / Kerberos - Logins kann DNs erzeugen, die in dem Verzeichnis nicht existieren überhaupt, und das ist immer noch perfekt nutzbar.)

Vielen Dank für Ihre Antwort. Sie müssen eine `olcAccess`-Regel hinzufügen, um Lese- und Schreibberechtigungen in config für den angegebenen Benutzer zuzulassen. Recht? elysch vor 5 Jahren 0
Ja. Alles bleibt gleich. (Obwohl in einer separaten Notiz angegeben, ist syncrepl immer Pull-basiert, sodass der Benutzer des Replikats nur Leseberechtigungen benötigt.) grawity vor 5 Jahren 0

Verwandte Probleme