+++ This bug was initially created as a clone of Bug #55563 +++ In https://www.rfc-editor.org/rfc/rfc4514 there are characters specified for a DN which have two alternative representations. For example "\+" and "\2b" are equivalent. In Bug #55563 it was introduced that DNs are normalized when they get passed into UDM, where normalization also means that, among other tings, "\+" is chosen instead of "\2b". When a DN is now saved in an attribute its has the normalized form, but when DNs that were saved before or are retrieved in another way (e.g. an LDAP search), they still have the form that is not normalized. This can have the effect that, depending on the source where DNs are coming from, they can have different forms, and one cannot compare them via simple string comparison. When DNs are retrieved via UDM syntax classes, they should be normalized as well. An example what can go wrong: When a syntax class that derives from `UDM_Objects` (and that has "key=dn") is used to get the choices via `udm/syntax/choices` you will get not-normalized DNs as identifiers. But you can get normalized DNs with `udm/get` when reading attributes which contain normalized DNs. When working on Bug #58261 this was observed for the ox connector syntax class `fullWidthUserName`: The value that is saved in LDAP is not visible, because the `id` did not match with any of the choices.
With Bug #58261, it was decided to revert part of the solution in Bug #55563 - we do not normalize the DN anymore before writing it to an attribute and only verify that is a DN, which was the original intention.
Yes, but we will still use this bug to track the problem.