Bug 2117025

The underlying python library the CLI tool uses (python-lib389) is "normalizing" the DN before it adds the backend entries to the server's configuration.  Should be a simple fix to preserve the original case for a root suffix.  Note - that once the suffix case is set it will be strictly enforced.  So even if you add an entry with a different case for the base suffix, it will still use the case you originally set in the server's config.

Upstream ticket:

https://github.com/389ds/389-ds-base/issues/5412

Question for customer...

With the current fix the DN case is preserved to a LDAP client:

ldapsearch -D "cn=directory manager" -xLLL -W -b dc=fedora
dn: dc=FEDORA
objectClass: top
objectClass: domain
dc: FEDORA
description: dc=FEDORA

dn: ou=groups,dc=FEDORA
objectClass: top
objectClass: organizationalunit
ou: groups


But the defaultnamingcontect is normalized - which makes the DN lowercase (this is valid per the LDAP RFC's).  The only way to change this is to NOT normalize the DN, and that could break other customer suffixes where the suffix does need to be normalized (special characters, embedded commas, etc).  I'd prefer to not change this or attempt to modifying our DN normalization code (which is very complex).  Since the case is preserved when an ldap clinet queries the database is that sufficient for this customer?

The issue is migrations from existing LDAP directories. This is how this issue came up. I've also seen it at another customer and tools like Entrust CA require it.

The issue with normalizing is that if a tool (outside of ldap tools) looks the LDAP path by normalizing it does not get what it expects.

(In reply to Jerone Young from comment #11)
> The issue is migrations from existing LDAP directories. This is how this
> issue came up. I've also seen it at another customer and tools like Entrust
> CA require it.

Looking at the case the current hotfix should be fine.  The only thing that is not persevered is the namingcontext attribute in the root dse entry.  I see no mention of that in the bug (which is good).  Any ldap query on the database will return the base DN in the same case that it was created during installation.  Apache Directory Studio is just an LDAP client, so the entries it processes will contain the correct case of the suffix.  Those other attributes in the dse.ldif are inconsequential to server behavior.

Akshay I think we can mark this as verified.  Moving back to on QA.

# PYTHONPATH=src/lib389/ py.test -v dirsrvtests/tests/suites/basic/basic_test.py::test_suffix_case --disable-warnings
re-exec with libfaketime dependencies
============================================================================ test session starts =================================================================
platform linux -- Python 3.6.8, pytest-7.0.1, pluggy-1.0.0 -- /usr/bin/python3.6
cachedir: .pytest_cache
389-ds-base: 1.4.3.31-5.module+el8dsrv+16686+3df5ff63
nss: 3.79.0-10.el8_6
nspr: 4.34.0-3.el8_6
openldap: 2.4.46-18.el8
cyrus-sasl: not installed
FIPS: disabled
rootdir: /root/389-ds-base/dirsrvtests, configfile: pytest.ini
plugins: libfaketime-0.1.2
collected 1 item                                                                                                                                                            

dirsrvtests/tests/suites/basic/basic_test.py::test_suffix_case PASSED                                                                                                 [100%]

====================================================================== 1 passed, 14 warnings in 16.27s ===========================================================

Marking it 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 (redhat-ds:11 bug fix and enhancement update), 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://access.redhat.com/errata/RHBA-2022:7929

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days