Bug 32015 - Configure cn=admin as rootdn in DC Master slapd.conf
Configure cn=admin as rootdn in DC Master slapd.conf
Status: RESOLVED FIXED
Product: UCS
Classification: Unclassified
Component: LDAP
UCS 3.1
Other Linux
: P5 enhancement (vote)
: ---
Assigned To: UCS maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-18 16:33 CEST by Arvid Requate
Modified: 2018-04-14 13:44 CEST (History)
1 user (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): UCS Performance
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arvid Requate univentionstaff 2013-07-18 16:33:38 CEST
A couple of LDAP ACLs grant write access to cn=admin,$ldap_base. This could be avoided if this DN was configured as rootdn in slapd.conf. According to OpenLDAP documentation (e.g. man slapd.access) this might increase perfomance.

Prices to to pay:

* The password or its hash needs to be included in the slapd.conf file as "rootpwd: {[CLEARTEXT|SHA|...} <string>"

* On DC-Slave and DC-Backup the rootdn is configured to be cn=update,$ldap_base. So cn=admin could not be privileged this way on these systems. But then, currently there are no special ACLs for cn=admin installed anyway on these systems.
Comment 1 Stefan Gohmann univentionstaff 2013-08-13 07:07:19 CEST
(In reply to Arvid Requate from comment #0)
> * On DC-Slave and DC-Backup the rootdn is configured to be
> cn=update,$ldap_base. So cn=admin could not be privileged this way on these
> systems. But then, currently there are no special ACLs for cn=admin
> installed anyway on these systems.

I don't think it is a good idea to handle the configuration for cn=admin on master and backup in a different way.

Maybe we could improve the performance by one ACL like this:

access to *
  by cn=admin,$ldap_base
  by * none break