Bug 32015
| Summary: | Configure cn=admin as rootdn in DC Master slapd.conf | ||
|---|---|---|---|
| Product: | UCS | Reporter: | Arvid Requate <requate> |
| Component: | LDAP | Assignee: | UCS maintainers <ucs-maintainers> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P5 | CC: | gohmann |
| Version: | UCS 3.1 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| 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: | |||
(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 |
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.