Univention Bugzilla – Bug 46904
cn=dc,cn=computers container must be documented
Last modified: 2019-03-01 21:53:12 CET
The "cn=dc,cn=computers,$ldap_base" container is used by several LDAP ACLs to give DCs elevated permissions like reading certain LDAP attributes. If the machine account of a DC is not located in that container, certain things like "univention-join" will fail: the DC will not be able to replicate "krb5VersionNumber" for example, which is a required MUST attribute of "objectClass: krb5Principal", the user "uid=Administrator" and the machine account will not get replicated. LDAP authentication against the local PC then fails with some very strange error messages (but works against the Master). The UCS documentation should clearly state, that DC machine accounts *must* be stored directly in that container (or the LDAP ACLs must be changed). (There is another ACL to give members of the group "Domain Admins" access to those attributes, too. Membership to that group can be used if the machine account is moved outside of "cn=dc". Why the DN is used instead of checking the groups "DC Backup Hosts" and "DC Slave Hosts" I have no idea; I guess its performance reasons as checking membership of a group requires additional LDAP operations while checking the DN is cheap.)
(In reply to Philipp Hahn from comment #0) > (There is another ACL to give members of the group "Domain Admins" access to > those attributes, too. Membership to that group can be used if the machine > account is moved outside of "cn=dc". Why the DN is used instead of checking > the groups "DC Backup Hosts" and "DC Slave Hosts" I have no idea; I guess > its performance reasons as checking membership of a group requires > additional LDAP operations while checking the DN is cheap.) If the ACLs are altered, please check also UCS@school. There are additional ACLs to emulate the access right similar to those for cn=dc,cn=computers,...