Andrew Bartlett wrote:
I'm up against my next challenge in the great challenge of Samba4 and OpenLDAP.
As metioned on openldap-devel, I've hit up against renaming DNs onto themselves.
For example, I previously mentioned cn=ldaptestuser2,cn=users,DC=samba,DC=example,DC=com into cn=ldaptestuser3,cn=users,DC=samba,DC=example,DC=com
This should become:
dn: cn=ldaptestuser2,cn=users,DC=samba,DC=example,DC=com changetype: modrdn newrdn: cn=ldaptestuser2 deleteoldrdn: 1
There appears to be a typo somewhere in your example, but I can't tell if you meant ldaptestuser3 or ldaptestuser2.
RFC 4511 states that a modify DN operation must fail with the entryAlreadyExists result code if there was already an entry with that name. However, a broad interpretation would recognize that such a modify DN operation is going to be a no-op and simply ignore it. The specific case doesn't seem to be explicitly dealt with in RFC 4511.
I've written a module to cause this to never reach the DB, but my next test (which AD also permits) is:
cn=ldaptestuser3,cn=users,DC=samba,DC=example,DC=com into cn=ldaptestUSER3,cn=users,DC=samba,DC=example,DC=com
So it seems I need some backend help. Is there another way I should be handling case changes in a DN, or could/should the DB be modified to allow these operations?
'way back I recall explicitly allowing this case, but the current backend code doesn't. I think it's worth filing an ITS for this.
As for renaming an entry to exactly the same DN, I could go either way. If we ignore it and silently return success, it will still generate replication traffic, which may or may not be desired.
(These tests arose because a user tried to do exactly this from the windows management tools, and we also failed to allow it in ldb).
Thanks,
Andrew Bartlett