Delegation der Benutzerverwaltung

Hallo,

ich habe einen UCS 4 aufgesetzt und möchte nun einer Gruppe die Berechtigung zum Verwalten der Nutzer und Gruppen geben. Diese Nutzer sollen keine weiteren Einstellungen am Server ändern dürfen.
Über die UMC habe ich der entsprechenden Gruppe die Policies “udm-groups” und “udm-users” gegeben.
Damit die Benutzer dieser Gruppe jetzt auch tatsächlich die Benutzer verwalten können, müssen die LDAP-ACLs angepasst werden.

Diese Zeilen habe ich in der slapd.conf eingetragen:

access to dn.subtree="cn=users,dc=domain,dc=intranet"
    by set="user & [cn=User Admins,cn=groups,dc=domain,dc=intranet]/uniqueMember*" write
    by * read break

access to dn.subtree="cn=groups,dc=domain,dc=intranet"
    by set="user & [cn=User Admins,cn=groups,dc=Domain,dc=intranet]/uniqueMember*" write
    by * read break

Beim Versuch Nutzer über die UMC zu verwalten, erhalte ich leider immer noch folgende Fehlermeldung:

Wie müssten die LDAP-ACLs korrekterweise aussehen, und an welche Stelle in der slapd.conf (bzw. im Template) müssen sie eingetragen werden?

Vielen Dank für die Unterstützung,
Andreas

1 Like

Hallo,

ich denke die Benutzer müssen mindestens noch Schreibzugriff auf den Container “cn=temporary,cn=univention,dc=domain,dc=intranet” (bzw den den entsprechenden Untercontainern) bekommen um Locks anlegen zu dürfen (für UIDs, GIDs, mailadressen etc.).

Mit freundlichen Grüßen
Janis Meybohm

Hallo Herr Meybohm,

vielen Dank für Ihren Tipp, damit funktioniert es nun. Oder zumindest fast.

Zunächst musste ich die Zeilen

by set="user & [cn=User Admins,cn=groups,dc=domain,dc=intranet]/uniqueMember*" write

durch

by group/univentionGroup/uniqueMember="cn=User Admins,cn=groups,dc=domain,dc=intranet" write

ersetzen.

Das Anlegen, Löschen und Bearbeiten von Benutzern und Gruppen funktioniert jetzt.
Wir benutzen den UCS hauptsächlich für die Benutzerverwaltung von Open Xchange. Wenn ich jetzt mit dieser Konfiguration, als Nutzer der Gruppe “User Admins”, einen Nutzer anlegen möchte, und dabei das Benutzertemplate “open-xchange groupware account” auswähle, erhalte ich die Fehlermeldung “Forbidden”. Wenn ich kein Template auswähle funktioniert es.

Hier ein Mitschnitt des Requests:

POST /umcp/command/udm/get HTTP/1.1
Host: XXX.XXX.XXX.XXX
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US
Accept-Encoding: gzip, deflate
Content-Type: application/json; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://XXX.XXX.XXX.XXX/univention-management-console/?lang=de-DE
Content-Length: 131
Cookie: UMCUsername=test.user1; _pk_id.14.9bc9=2c7a1a088aec44c7.1424775150.7.1425309176.1425060260.; UMCSessionId=0d6d9cf4-9367-4882-bafe-96257c01d255; _pk_ses.14.9bc9=*
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

{"options":["cn=open-xchange groupware account,cn=templates,cn=univention,dc=domain,dc=intranet"],"flavor":"settings/usertemplate"}

HTTP/1.1 403 Forbidden
Date: Mon, 02 Mar 2015 15:13:10 GMT
Server: CherryPy/3.2.2
Content-Length: 257
Content-Type: application/json
Via: 1.1 ucs.domain.intranet
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive

{"status": 403, "message": "Forbidden"}

Jetzt lag es natürlich nahe, der Gruppe auch Schreibzugriff auf cn=templates,cn=univention,dc=domain,dc=intranet und deren Untercontainern zu geben. Das brachte aber leider keinen Erfolg.
Selbst wenn ich der Gruppe LDAP-Schreibrechte auf alles gebe ändert sich nichts.
Wenn ich der Gruppe zusätzlich die Policy “udm-all” gebe funktioniert es. Aber dann hat die Gruppe natürlich mehr Rechte als sie haben muss.

Wie kann ich dieses Problem lösen? Ein LDAP-Rechte-Problem scheint es ja nicht zu sein!?

Vielen Dank,
Andreas

Hallo,

anscheinend fehlt hier ein UMC Operationset für den Zugriff auf die Benutzertemplates. Sie können das mit dem folgenden Befehl hinzufügen und das Operationset dann der UMC-Policy Ihrer “User Admins” hinzufügen. Dann sollte es beim verwendend er Templates keine Fehlermeldung mehr geben. Eins spezielle ACL für den Zugriff auf “cn=templates,cn=univention,dc=domain,dc=intranet” ist nicht notwendig da dort nur gelesen werden muss.

udm settings/umc_operationset create --position "cn=operations,cn=UMC,cn=univention,$(ucr get ldap/base)" \ --set name="udm-usertemplates" \ --set operation="udm/get" \ --set flavor="settings/usertemplate" \ --set description="User templates"

Mit freundlichen Grüßen
Janis Meybohm

Hallo Herr Meybohm,

Super, jetzt funktioniert es!

Vielen Dank für Ihre Mühe,
Andreas

Frage dazu: Die Änderungen nur auf dem Master oder auf jedem Backup-Server?

Hallo Zusammen,
ich weiß, der Thread ist schon etwas älter, ich habe aber gerade genau das gleiche Problem:
Ich möchte die Benutzerverwaltung an eine Gruppe delegieren, ohne diesen Domain Admin Rechte zu geben.
Also hab ich eine neue Gruppe “Vorstand” erstellt und dieser in der UMC eine neue Richtlinie für diese Gruppe erstellt und dieser die UDM-Users Policie zugeordnet.
Nun kann ich in der UMC mit den betroffenen Usern die Benutzer zwar sehen, jedoch bekomme ich die Meldung

Das LDAP-Objekt konnte nicht gespeichert werden: Zugriff verweigert.

wenn ich versuche zu speichern.

Wenn ich neue Nutzer anlegen möchte, bekomme ich die Meldung

Das LDAP-Objekt konnte nicht gespeichert werden: Zugriff verweigert. Konnte die Sperrzeit von 'cn=lo2,cn=uid,cn=temporary,cn=univention,dc=mydomain,dc=mytld' nicht modifizieren.

Die selben Fehlermeldungen bekomme ich auch wenn ich der Gruppe schon vorhandene Richtlinien wie “UMC-All” usw. zuweise.

Ich habe folgendes in meine slapd.conf eingetragen, um Schreibrechte auf den temporary Container zu bekommen:

access to dn.subtree="cn=users,dc=mydomain,dc=mytld"
    by group/univentionGroup/uniqueMember="cn=Vorstand,cn=groups,dc=mydomain,dc=mytld" write
    by * read break
access to dn.subtree="cn=groups,dc=mydomain,dc=mytld"
    by group/univentionGroup/uniqueMember="cn=Vorstand,cn=groups,dc=mydomain,dc=mytld" write
    by * read break
access to dn.subtree="cn=temporary,cn=univention,dc=mydomain,dc=mytld"
    by group/univentionGroup/uniqueMember="cn=Vorstand,cn=groups,dc=mydomain,dc=mytld" write
    by * read break

Aktuell installiert ist UCS 4.2-3 errata312.

Habe ich noch etwas vergessen?
Vielen Dank schon mal für eure Hilfe!

Liebe Grüße,
Felix

Hallo Felix,

in der Fehlermeldung und der Konfigurationsdatei stimmen die Domains nicht überein:

dc=dualer,dc=de

und

dc=mydomain,dc=mytld

Vielleicht ist das schon das ganze Problem?

Viele Grüße
Andreas

Hi Andreas,

danke für deine Antwort aber leider nein, ich bin einfach nur dumm und hab vergessen auch in der Fehlermeldung unsere Domain auszublenden :roll_eyes:
In der richtigen Config stimmen die DCs natürlich (mit denen in UCS konfigurierten) überein.

Lg Felix

Hi in die Runde,

konnte Felix Anfrage gelöst werden? Ich stehe vor dem selben Problem.

lg,
Manuel

Hallo, ist es mit dieser Lösung nicht möglich, einen Benutzer zum Administrator zu machen und damit die ganze Mühe umsonst oder übersehe ich etwas? Siehe auch: Administrator Benutzer zur Benutzerverwaltung

Doch, ist es. Sprich Sicherheit bringt diese Form der Separation nicht.

Wenn es aber eher darum geht, vertrauenswürdigen Personen erhöhte Rechte zu geben, ohne sie gleich mit der vollen Oberfläche und damit allen Admin-Optionen zu erschlagen, kann das eine gute Lösung sein. Der Punkt ist hier, dass man den Leuten wirklich vertraut, die aber vielleicht technisch nicht all zu versiert sind (in kleineren Organisationen durchaus gängig).

3 Likes

Kann man nicht verhindern, dass sie zugriff auf die Admin Gruppen bekommen? Also dass sie nur Nutzer in bestimmten Gruppen anlegen und bearbeiten können? Obwohl, die Zuweisung passiert ja im Nutzerobjekt :frowning:

Dieser Beitrag ist zwar schon etwas älter, beschäftigt mich momentan aber auch. Wie man das technisch lösen könnte, weiss ich leider nicht und hoffe hier eine Antwort zu finden. Aber es sollte doch möglich sein, gewisse Gruppen auszublenden, dass also die Delegierten die Admin-Gruppen nicht verändern können, damit eben kein unberechtigter User bei den Domänenadmins landet.

Mastodon