LDAP write access - ACL

[oliK]

Hallo,

wenn ich auf das primäre Adressbuch über die Konfiguration LDAP-WriteAcess aktiviere,
habe ich ja "nur" über ACL die Möglichkeit einzuschränken, wer via LDAP schreiben darf.
Kann mir jemand das herumprobieren ersparen und sagen, welches Zugriffslevel bzw. welche Rolle man nicht haben darf,
um im Adressbuch via LDAP herumzuschreiben oder gar Personen anzulegen?

Wären das das Zugriffslevel "Autor" und die Rolle "UserCreator"?
Schade dass es für LDAP keine eigene Rolle gibt, um das besser zu differenzieren.
Ich benötige für einen UseCase LDAP-Schreibrechte, möchte aber verhindern, dass plötzlich via LDAP die Scheunentore offen sind
für andere an das LDAP gekoppelte Systeme.
Diese sind aktuell über einen Serviceaccount mit Level "Reader" und ohne Rolle "UserCreator" angebunden.

[stoeps]

Ein Reader darf nicht schreiben, egal welche Rolle er hat.

Wenn du nur ändern willst, dann Autor (wo der User Creator ist) oder Editor. Oder willst du wirklich User anlegen? Dann gäbe es die Möglichkeit ldap write für ein zusätzliches Adressbuch zu konfigurieren. Dann passiert im Directory nichts. Schreib mal was du erreichen willst.

[oliK]

Hallo,

Hintergrund ist dieser Beitrag: https://atnotes.de/index.php/topic,62059.0.html

Aus einer Coexistence mit einem Firmenteil mit Exchange haben wir schon lange ein sekundäres Adressbuch im Einsatz,
in dem über eine per LDAP angebundene Drittsoftware die Benutzer aus dem Exchange-AD hineinsynchronisiert werden.
Der technische Account hat Rechte für Benutzeranlage und -änderung.
Ich habe es aktuell auch genau wie von dir beschrieben im Einsatz, dass LDAP-write eben nur auf dem sekundären Adressbuch aktiviert ist um eben das primäre vor möglichem Synchronisations-Müll zu schützen.

Jetzt kommt es aber immer häufiger vor, dass Benutzer aus dem anderen Firmenteil zusätzlich einige
der Notes-Applikationen nutzen wollen/sollen ohne aber auf ihr Outlook verzichten zu müssen.
(Ja IMSMO ich weiss...aber das braucht noch viel Überzeugungsarbeit).
Das ist alles machbar über einen zweiten Zertifizierer.

Leider stolpere ich bei all diesen Benutzern über das Problem, dass die Erstanmeldung in Notes bzw. ein Rechnerwechsel
ärgerlich ist, weil der ID-Vault nicht für diese Benutzer funktioniert.
Obacht....prinzipiell sammelt der ID-Vault deren IDs tatsächlich ein, auch Änderungen nach Passwortwechsel.
Aber bei der Erstanmeldung schaut der Domino-Server einfach nicht ins sekundäre Adressbuch hinein.
Ich muss also immer zu den Leuten hin und ihnen ihre ID manuell am Client ablegen.
Und natürlich befeuern genau diese Kollegen den Anmeldeschmarrn bei Notes.

Daraufhin habe ich diverse Varianten ausprobiert und herausgefunden, dass es nicht am sekundären Zertifizierer liegt sondern am sekundären Adressbuch. Der initiale ID-Vault-Lookup läuft NUR ins primäre Adressbuch (schade eigentlich, dabei sind beide in der DirectoryAssistance hinterlegt).
Im Umkehrschluss bedeutet das, dass wenn ich einen Domino-Benutzer ins sekundäre schiebe, findet er ihn bei Erstanmeldung nicht automatisch, wenn ich aber einen Exchange-Domino-Benutzer (;.)) ins sekundäre schiebe, findet er ihn.

Also für mich die einzige brauchbare Ziellösung: alle in das primäre Adressbuch werfen.
Grundlegend fände ich das sogar schöner, weil man dann nicht mehr überlegen muss, wo der Mensch sitzt,
wenn man ihn im Adressbuch suchen möchte.
Aber ich mache mir natürlich Sorgen, LDAP-write auf dem primären Adressbuch zu aktivieren.
Von den Rechten sieht es aber soweit gut aus, dass ausser den Admins und einem technischen Account keiner im LDAP anlegen darf (hoffe ich).

[stoeps]

Ok, also anlegen sollte ein Editor mit der UserCreator Rolle erledigen dürfen. Evtl nimmst du ihm die Delete Rechte