In the krb5 project we are working on making principal renames work in our LDAP KDB module. For standalone principals, we issue a Modify DN operation, which could look like this as LDIF:
dn: krbprincipalname=user@LDAPTEST,cn=LDAPTEST,cn=krb5,dc=test changetype: modrdn newrdn: krbprincipalname=user2@LDAPTEST deleteoldrdn: 1
With 389ds, this operation fails with an Operations error. Stepping through the code, I find that in moddn_newrdn_mods(), dn is "krbprincipalname=user@ldaptest,cn=ldaptest,cn=krb5,dc=test"; that is, in the DN, LDAPTEST appears to have been case-folded to ldaptest. moddn_newrdn_mods() produces a list of two mods, deleting "user@ldaptest" and adding "user2@LDAPTEST". Because krbprincipalname is exact-match, the delete fails.
Our workaround is to perform the Modify DN with deleteoldrdn: 0 and delete the old attribute value afterwards.
Could you help us to understand the issue som more? Here's my test case. (I mimicked it.) {{{ $ ldapsearch -LLLx -D 'cn=directory manager' -W -b "uid=user@LDAPTEST,OU=ou0,ou=People,dc=example,dc=com" uid dn: uid=user@LDAPTEST,ou=OU0,ou=People,dc=example,dc=com uid: user@LDAPTEST
$ ldapmodify -x -D 'cn=directory manager' -W dn: uid=user@LDAPTEST,ou=OU0,ou=People,dc=example,dc=com changetype: modrdn newrdn: uid=user2@LDAPTEST deleteoldrdn: 1
modifying rdn of entry "uid=user@LDAPTEST,ou=OU0,ou=People,dc=example,dc=com"
$ ldapsearch -LLLx -D 'cn=directory manager' -W -b "uid=user2@LDAPTEST,OU=ou0,ou=People,dc=example,dc=com" uid dn: uid=user2@LDAPTEST,ou=OU0,ou=People,dc=example,dc=com uid: user2@LDAPTEST }}} That said, I could not reproduce the problem. Usually, DN is internally normalized, but it should not disturb the modrdn operation...
If you could provide us steps to reproduce, we'd appreciate it.
The code hasn't been touched for a while, so it should be stable, but please provide us the output of "rpm -q 389-ds-base".
Thanks.
To reproduce this problem, you need:
The uid attribute uses caseIgnoreMatch, which explains why you don't see the problem in that test.
I tested with 1.3.4.9, but this problem still exists on master. Where ldbm_back_modrdn() calls ldbm_back_modrdn(), it passes slapi_sdn_get_ndn(sdn) as olddn; this is the case-folded form of the DN. I don't know if there would be any negative side effects to changing this argument to slapi_sdn_get_dn(sdn).
Thanks for the input!
git patch file (master) 0001-Ticket-48848-modrdn-deleteoldrdn-can-fail-to-find-ol.patch
Considered "one line fix". Actually, one character fix.
Pushed to master: 735ccc6..e2765ce master -> master commit e2765ce
Metadata Update from @nhosoi: - Issue assigned to nhosoi - Issue set to the milestone: 1.3.5.5
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/1908
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.