Bug 1099654
| Summary: | Normalization from old DN format to New DN format doesnt handel condition properly when there is space in a suffix after the seperator operator. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Noriko Hosoi <nhosoi> |
| Component: | 389-ds-base | Assignee: | Noriko Hosoi <nhosoi> |
| Status: | CLOSED ERRATA | QA Contact: | Viktor Ashirov <vashirov> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | low | ||
| Version: | 7.0 | CC: | nkinder, rmeggins, vashirov |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | 389-ds-base-1.3.3.1-1.el7 | Doc Type: | Bug Fix |
| Doc Text: |
Cause:
DN normalizer (slapi_dn_normalize_ext) follows RFC 4514
and keeps a white space if the RDN attribute type is not based on the
DN syntax. But Directory server's configuration entry sometimes uses
"cn" to store a DN value (e.g., dn: cn="dc=A,dc=com",cn=mapping tree,
cn=config), which expects the value of cn treated as DN although cn
is not a DN syntax type.
Consequence:
Configuration DNs which are different from each other by white spaces around
a separator are treated as 2 different DNs.
Fix:
To solve the problem, this patch introduces a configuration parameter
"nsslapd-cn-uses-dn-syntax-in-dns" to "cn=config" which takes "on" or "off".
If "on" is set, if the value of cn under "cn=config" is quoted, it's processed
as DN.
Result:
Configuration entries which has DN in the CN value is always handled correctly.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-03-05 09:34:39 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Noriko Hosoi
2014-05-20 20:26:14 UTC
Steps to verify: stop the server set "nsslapd-cn-uses-dn-syntax-in-dns: off" in cn=config start the server. ldapsearch ... -b "cn=config" -s base nsslapd-cn-uses-dn-syntax-in-dns nsslapd-cn-uses-dn-syntax-in-dns: off Add the following 3 entries. All should be successfully added. ==> test0.ldif <== dn: cn="dc=abc, dc=def, dc=com",cn=config objectClass: extensibleObject objectClass: top ==> test1.ldif <== dn: cn="dc=abc,dc=def,dc=com",cn=config objectClass: extensibleObject objectClass: top ==> test2.ldif <== dn: cn="dc=abc ,dc=def ,dc=com",cn=config objectClass: extensibleObject objectClass: top ------------------------------------------------------------------------- stop the server set "nsslapd-cn-uses-dn-syntax-in-dns: on" in cn=config start the server. ldapsearch ... -b "cn=config" -s base nsslapd-cn-uses-dn-syntax-in-dns nsslapd-cn-uses-dn-syntax-in-dns: on Add the following 3 entries. Only the first one is successfully added and the rest is rejected with error "Already exists". ==> test0.ldif <== dn: cn="dc=abc, dc=def, dc=com",cn=config objectClass: extensibleObject objectClass: top ==> test1.ldif <== dn: cn="dc=abc,dc=def,dc=com",cn=config objectClass: extensibleObject objectClass: top ==> test2.ldif <== dn: cn="dc=abc ,dc=def ,dc=com",cn=config objectClass: extensibleObject objectClass: top Tested on: $ rpm -qa | grep 389-ds 389-ds-base-debuginfo-1.3.3.1-11.el7.x86_64 389-ds-base-1.3.3.1-11.el7.x86_64 389-ds-base-libs-1.3.3.1-11.el7.x86_64 [1] nsslapd-cn-uses-dn-syntax-in-dns is off $ ldapsearch -LLL -D "cn=Directory Manager" -w Secret123 -b "cn=config" -s base nsslapd-cn-uses-dn-syntax-in-dns dn: cn=config nsslapd-cn-uses-dn-syntax-in-dns: off $ ldapmodify -D "cn=Directory Manager" -w Secret123 -c -a << EOF dn: cn="dc=abc, dc=def, dc=com",cn=config objectClass: extensibleObject objectClass: top dn: cn="dc=abc,dc=def,dc=com",cn=config objectClass: extensibleObject objectClass: top dn: cn="dc=abc ,dc=def ,dc=com",cn=config objectClass: extensibleObject objectClass: top EOF adding new entry "cn="dc=abc, dc=def, dc=com",cn=config" adding new entry "cn="dc=abc,dc=def,dc=com",cn=config" adding new entry "cn="dc=abc ,dc=def ,dc=com",cn=config" [2] nsslapd-cn-uses-dn-syntax-in-dns is on $ ldapsearch -LLL -D "cn=Directory Manager" -w Secret123 -b "cn=config" -s base nsslapd-cn-uses-dn-syntax-in-dns dn: cn=config nsslapd-cn-uses-dn-syntax-in-dns: on $ ldapmodify -D "cn=Directory Manager" -w Secret123 -c -a << EOF dn: cn="dc=abc, dc=example, dc=com",cn=config objectClass: extensibleObject objectClass: top dn: cn="dc=abc,dc=example,dc=com",cn=config objectClass: extensibleObject objectClass: top dn: cn="dc=abc ,dc=example ,dc=com",cn=config objectClass: extensibleObject objectClass: top EOF adding new entry "cn="dc=abc, dc=example, dc=com",cn=config" adding new entry "cn="dc=abc,dc=example,dc=com",cn=config" ldap_add: Already exists (68) adding new entry "cn="dc=abc ,dc=example ,dc=com",cn=config" ldap_add: Already exists (68) Only the first one is successfully added and the rest is rejected with error "Already exists". Marking as VERIFIED Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0416.html |