Is it possible to create an Account which can create users but cannot do anything to admin-accounts?
I don’t know, if it is still state of the art, but I did it once by editing the slapd.conf giving access to the subtree users and groups to a special group .
Then you have to create a policy to access these modules to this group and finally creating this group.
Dont’t know, if it still works, but you may have a look at it.
#!/bin/bash
#*****************************************************
# Eine Gruppe einrichten, die fĂĽr die Benutzer- und
# Gruppenverwaltung authorisiert ist.
#
# Author: Stefan Kuhn
# Mail: stefan.kuhn@innere.med.uni-giessen.de
# Date: 05.03.2019
# Version:1.1
#
# Ă„nderungshistorie
# 1.0 05.04.2019 Initiales Script
# 1.1 10.09.2019 Da die Berechtigungen in der ACL gefehlt haben, wurde der Block mit den LDAP Berechtigungen hinzugefĂĽgt
#*****************************************************
# Erstelle die Datei fĂĽr den ACL Eintrag in der slapd.conf
cat << EOF > /etc/univention/templates/files/etc/ldap/slapd.conf.d/65DZL_UserAdministration
access to dn.subtree="cn=users,dc=dzl,dc=de"
by set="user & [cn=DZL User Administration,cn=groups,dc=dzl,dc=de]/uniqueMember*" write
by * read break
access to dn.subtree="cn=groups,dc=dzl,dc=de"
by set="user & [cn=DZL User Administration,cn=groups,dc=dzl,dc=de]/uniqueMember*" write
by * read break
access to dn.subtree="cn=temporary,cn=univention,dc=dzl,dc=de"
by set="user & [cn=DZL User Administration,cn=groups,dc=dzl,dc=de]/uniqueMember*" write
by * read break
EOF
cat << EOF > /etc/univention/templates/info/DZL_UserAdministrationGroup.info
Type: multifile
Multifile: etc/ldap/slapd.conf
Type: subfile
Multifile: etc/ldap/slapd.conf
Subfile: etc/ldap/slapd.conf.d/65DZL_UserAdministration
EOF
ucr commit /etc/ldap/slapd.conf
systemctl restart slapd
# Erstelle eine Policy, die den Zugriff auf die Module User und Groups erlaubt
udm policies/umc create \
--set name="DZL User Administration Group" \
--position "cn=UMC,cn=policies,$(ucr get ldap/base)" \
--set allow="cn=udm-users,cn=operations,cn=UMC,cn=univention,$(ucr get ldap/base)" \
--set allow="cn=udm-groups,cn=operations,cn=UMC,cn=univention,$(ucr get ldap/base)" \
--set allow="cn=temporary,cn=univention,$(ucr get ldap/base)"
echo "Erstelle Policy DZL User Administration Group"
# Erstelle eine Gruppe DZL_Admins
udm groups/group create \
--position "cn=groups,$(ucr get ldap/base)" \
--set name="DZL User Administration" \
--policy-reference="cn=DZL User Administration Group,cn=UMC,cn=policies,$(ucr get ldap/base)"
echo "Erstelle Gruppe DZL Administratoren"
1 Like
When I create a new user with my first simple template. it will tell me
You are not authorized to perform this action.
Server error message:
Forbidden
when I hit “Next” it will just keep loading forever.
Is this user-group able to assign groups to users? I think that’s the thing not working here.
Never tested this with UCS 5, but will try it later that day.
There are some issues with the tabs while copy&pasting the script.
The EOF operator must be at the beginning of the line?
And did you replace the ldap/base with yours in the ACLs?
And just to mention:
This way is not secure, since user in this group may grant higher privileges to themself or others. By fault or by bad intentions.
Yes I adjusted the Domain by loading this variable first:
eval "$(ucr shell ldap/base)"
and then I used it like this:
by set="user & [cn=UserAdminGroup,cn=groups,$ldap_base]/uniqueMember*" write
by * read break
maybe there’s a problem with the slapd-conf file. this is how it looks:
access to dn.subtree="cn=users,dc=mydomain,dc=tld"
by set="user & [cn=UserAdminGroup,cn=groups,dc=mydomain,dc=tld]/uniqueMember*" write
by * read break
access to dn.subtree="cn=groups,dc=mydomain,dc=tld"
by set="user & [cn=UserAdminGroup,cn=groups,dc=mydomain,dc=tld]/uniqueMember*" write
by * read break
access to dn.subtree="cn=temporary,cn=univention,dc=mydomain,dc=tld"
by set="user & [cn=UserAdminGroup,cn=groups,dc=mydomain,dc=tld]/uniqueMember*" write
by * read break
I think making it secure should be relatively easy by just creating an OU for the groups these user should have access to.
I can confirm, that it works in UCS5, too and your entry in slapd.conf seems to be okay.
At which place of the conf is your entry? Maybe it is to early in place and overwritten by other directives.
Are there some other LDAP modifications?
Have you double-checked the group name and if user is member of this group.
The user is only in this group and when he logs in he just sees the users and groups-app.
I just called it “65UserAdministration”
I don’t have other modifications there. Should I make it 80UserAdministration?
I didn’t restart slapd… now it works 
somehow I had to do it manually after the script already did it.
I’m trying to secure it. do you have an idea how I could disallow this group from displaying the normal users and groups? (creating works fine in the custom OU)
I tried with “disclose” instead of “write” but this doesn’t work.
Sorry, no idea. This was not my scope and is far away from my LDAP-skills.
but maybe you can boost my perfromance by telling me what this line does?:
by * read break
I understand that the break means that this rule is done but other rule scan still apply. so maybe using “stop” is better here. but I don’t get if the “read” there does something. do you know that?
I recommend this two sources:
https://www.openldap.org/doc/admin24/access-control.html
https://linux.die.net/man/5/slapd.access
do you also get errors when running “slaptest -f /etc/univention/templates/files/etc/ldap/slapd.conf.d/theconfigfile…”?
bad DN "cn=users,dc=domain,dc=tld" in to DN clause
Are you able to add users to a group using your script? for me it’s not possible.
When I switch to “Add Objects” in “Members of this Group” it won’t show me the gorups to add but move to “Default properties”
@kuste
hey there
you never had this problem?:
When I create a new user with my first simple template. it will tell me
You are not authorized to perform this action.
Server error message:
Forbidden
when I hit “Next” it will just keep loading forever.
the problem occurs when accessing
POST https://ucs.mydomain.tld/univention/command/udm/get 403 (Forbidden)"
accessing this url using th ebuiltin administrator works:
https://ucs.mydomain.tld/univention/command/udm/get
I already gave the group “udm-all” in the policies and gave write-permissions to templates in LDAP. but that’s not fixing it.
ucs is behaving weird… I just did some other things (not on ucs) and just tried again and it works without any additional change…