Bug 46904 - cn=dc,cn=computers container must be documented
cn=dc,cn=computers container must be documented
Status: NEW
Product: UCS manual
Classification: Unclassified
Component: Installation
unspecified
Other Linux
: P5 normal (vote)
: ---
Assigned To: Docu maintainers
UCS maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-04-27 15:14 CEST by Philipp Hahn
Modified: 2019-03-01 21:53 CET (History)
4 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 6: Setup Problem: Issue for the setup process
Who will be affected by this bug?: 1: Will affect a very few installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.069
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philipp Hahn univentionstaff 2018-04-27 15:14:28 CEST
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.)
Comment 1 Sönke Schwardt-Krummrich univentionstaff 2018-04-29 11:01:20 CEST
(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,...