Problem:
A trainee should get the permisson to edit computer objects in UMC. Outside of this, he should not have access to other UMC modules.
The user was added to the “Domain Users” group and a UMC policy was created:
DN: cn=praktikant-umc,cn=UMC,cn=policies,dc=schein,dc=de
allow: cn=udm-computers,cn=operations,cn=UMC,cn=univention,dc=schein,dc=de
allow: cn=ipchange,cn=operations,cn=UMC,cn=univention,dc=schein,dc=de
allow: cn=schoolwizards-classes,cn=operations,cn=UMC,cn=univention,dc=schein,dc=de
allow: cn=schoolgroups-class,cn=operations,cn=UMC,cn=univention,dc=schein,dc=de
allow: cn=computerroom-all,cn=operations,cn=UMC,cn=univention,dc=schein,dc=de
allow: cn=internetrules-all,cn=operations,cn=UMC,cn=univention,dc=schein,dc=de
allow: cn=distribution-all,cn=operations,cn=UMC,cn=univention,dc=schein,dc=de
allow: cn=top-all,cn=operations,cn=UMC,cn=univention,dc=schein,dc=de
allow: cn=schoolrooms-all,cn=operations,cn=UMC,cn=univention,dc=schein,dc=de
allow: cn=roomreservation-all,cn=operations,cn=UMC,cn=univention,dc=schein,dc=de
allow: cn=schoolgroups-workgroup,cn=operations,cn=UMC,cn=univention,dc=schein,dc=de
allow: cn=udm-reports,cn=operations,cn=UMC,cn=univention,dc=schein,dc=de
ldapFilter: None
name: praktikant-umc
univentionObjectIdentifier: 32907733-1c77-4176-9ab8-f6090e89eb2a
Solution:
Create an ldapacl like this:
root@dc01:~# cat univention-support/66praktikanten.acl
access to filter="(|(univentionObjectType=computers/windows)(univentionObjectType=computers/ipmanagedclient)(cn=Windows Hosts))" attrs=entry,children,macAddress,sambaDomain,sambaSID,krb5RealmName,description,uniqueMember,memberUid
by group/univentionGroup/uniqueMember="cn=praktikant-umc-computer,cn=groups,@%@ldap/base@%@" write
by * +0 break
access to dn.subtree="cn=temporary,cn=univention,@%@ldap/base@%@"
by group/univentionGroup/uniqueMember="cn=praktikant-umc-computer,cn=groups,@%@ldap/base@%@" write
by * +0 break
access to dn.regex="^(.+,)?ou=([^,]+),@%@ldap/base@%@$$"
by group/univentionGroup/uniqueMember="cn=praktikant-umc-computer,cn=groups,@%@ldap/base@%@" write
by * +0 break
access to dn.subtree="cn=dns,@%@ldap/base@%@"
by group/univentionGroup/uniqueMember="cn=praktikant-umc-computer,cn=groups,@%@ldap/base@%@" write
by * +0 break
root@dc01:~# cat univention-support/66praktikanten.acl.info
# grant write access to praktikant-umc for computer objects
root@dc01:~#
To register the acl in ldap do:
udm settings/ldapacl create \
--position "cn=ldapacl,cn=univention,$(ucr get ldap/base)" \
--set name=66praktikanten.acl \
--set filename=66praktikanten.acl \
--set data="$(bzip2 -c ~/univention-support/66praktikanten.acl | base64)" \
--set package="66praktikanten.acl" \
--set packageversion=1 \
--set ucsversionstart=5.0-10 \
--set ucsversionend=5.99-0
With
tail -f /var/log/univention/listener.log
you should see something like:
LISTENER ( PROCESS ) : updating ‘cn=66praktikanten.acl,cn=ldapacl,cn=univention,dc=schein,dc=de’ command a
LISTENER ( PROCESS ) : ldap_extension: cn=66praktikanten.acl,cn=ldapacl,cn=univention,dc=schein,dc=de active? [b’FALSE’]
Multifile: /etc/ldap/slapd.conf
LISTENER ( PROCESS ) : updating 'cn=ldap_extension,cn=handler_messages,cn=univention,dc=schein,dc=de
After that, you can check the slapd.conf where the acl is placed. If this is okay, restart the slapd.service
systemctl restart slapd
If something is fishy, you can deactivate the acl like :
udm settings/ldapacl modify --dn "cn=66praktikanten.acl,cn=ldapacl,cn=univention,$(ucr get ldap/base)" --set active=FALSE