Discussion:
Change LDAP base DN
(too old to reply)
Diana
2017-09-23 18:51:00 UTC
Permalink
Raw Message
Hello,

I need to change the DN on an entry. The problem I'm running into is when the entry is not a leaf node and LDAP throws the Non-leaf exception. One way to handle it would be to delete the whole subtree and then recreate it with the new DN. I wanted to ask the group and see if there is any easier and better way to do this.

Thanks,
Diana
Eddie Hartman
2017-09-24 12:26:16 UTC
Permalink
Raw Message
Post by Diana
Hello,
I need to change the DN on an entry. The problem I'm running into is when the entry is not a leaf node and LDAP throws the Non-leaf exception. One way to handle it would be to delete the whole subtree and then recreate it with the new DN. I wanted to ask the group and see if there is any easier and better way to do this.
Thanks,
Diana
All I can think of is to code function to rename (moddn) all child nodes first, working your way back to the node you intend to change. I'm sure someone out there can cook up a nice recursive function to 'walk the tree' from leaf nodes up, and then share it. One way to detect leaf nodes is to do an iteration (e.g. selectEntries) for a particular DN as the searchBase and see how many nodes are returned. Otherwise you could attempt the moddn and catch any non-leaf exception each time.

-Eddie
yn2000
2017-09-24 15:00:40 UTC
Permalink
Raw Message
Hi Diana,

I am always fascinated when trying to understand the mind behind the LDAP DIT designer. Yes, decades ago, the father of the LDAP were expecting that LDAP DIT is flexible enough to allow people to utilize the OU, so that people with the same name can reside in different OU without modification in his/her name, presumably that they use CN for the DN. But, I thought a modern LDAP DIT designer ditched that idea. Although, Active Directory (AD) people is still using that design, and worse they inject a policy into the OU location. But, to be fair AD is for AD, not for LDAP. But, I still disagree with that LDAP DIT design, although that is the way the cookie crumble.

Now, if you are using LDAP, hopefully not AD, then I would recommend you to re-design LDAP in a way that no one will be changing the DN ever, ever, and ever. Yes, that could be an invention of an ID that is not CN, nor login ID. And usually, just because you tried to find a work-around, I am guessing that you do not have the authority to do that. But, at least you can relay this concern to your manager and let your manager take the risk of being blamed in the future. So, as you may or may not know, every LDAP entry has a machine ID. For example: IBM TDS/SDS: ibm-entryUUID, AD/ADAM: objectGUID or objectSID, SunONE: entryUUID (I do not have a chance to investigate the one from Oracle, but I bet they have it too), Novell: GUID, and Domino: dominoUNID. So, every time you delete the entry, this engine ID will be deleted and when you recreate another entry a new engine ID will be granted. Now, if you have current or future connections (links) that are relying on this machine ID, then those connections (links) will be screwed up.

The remedy is the moddn (or modrdn) that Eddie was mentioning. But, I believe you cannot perform moddn on an entry that has child entry in it, because the DN of those child entries contains the DN of the parent entry. That means deleting and recreating the child entries would your best bet. But, this option is not only non-desirable, but also a dangerous approach, because if there is error in the middle of the process, such as an LDAP socket closed (or other external forces), then the recovery process will be very complex, especially if there is a group (or role) membership that you have to deal with. (I cannot imagine a modern LDAP design where it is not allowed to link to machine ID and/or not allowed to have group (or role) membership that rely on the DN of an entry. Hmmm… unless the LDAP repository is being used as a database (RDBMS like) repository rather than a directory repository)

Yes, I use too many 'but', but I still hope you the best.
Rgds. YN.
Diana
2017-09-24 22:13:20 UTC
Permalink
Raw Message
Thanks for your reply, Eddie and YN!

Eddie, I thought about doing your approach first where I just step through to the nodes and change the DN. I tried it directly in LDAP first and as YN mentioned, it will not let me rename or move an entry where the parent doesn't exist yet. And the Parent can't be renamed till it has no child.

YN, sadly I don't have any control over the design so have to do what I am told. I agree with your concern about something happens in the middle of all the deletes and recreates. I thought about it and couldn't think of a good solution. So hence I posted in this group hoping someone has done this before and got a better solution than what I am doing.
Post by Diana
Hello,
I need to change the DN on an entry. The problem I'm running into is when the entry is not a leaf node and LDAP throws the Non-leaf exception. One way to handle it would be to delete the whole subtree and then recreate it with the new DN. I wanted to ask the group and see if there is any easier and better way to do this.
Thanks,
Diana
Eddie Hartman
2017-09-25 10:49:04 UTC
Permalink
Raw Message
Post by Diana
Thanks for your reply, Eddie and YN!
Eddie, I thought about doing your approach first where I just step through to the nodes and change the DN. I tried it directly in LDAP first and as YN mentioned, it will not let me rename or move an entry where the parent doesn't exist yet. And the Parent can't be renamed till it has no child.
YN, sadly I don't have any control over the design so have to do what I am told. I agree with your concern about something happens in the middle of all the deletes and recreates. I thought about it and couldn't think of a good solution. So hence I posted in this group hoping someone has done this before and got a better solution than what I am doing.
Post by Diana
Hello,
I need to change the DN on an entry. The problem I'm running into is when the entry is not a leaf node and LDAP throws the Non-leaf exception. One way to handle it would be to delete the whole subtree and then recreate it with the new DN. I wanted to ask the group and see if there is any easier and better way to do this.
Thanks,
Diana
Of course YN is absolutely right, as are you, Diana. I whisked off my reply without adequate thought and it shows. As YN states your option here is to copy all entries to the new location and then delete the old sub-tree. And as he warns this can cause problems for any linkages based on internal uuids. And copying entries may not be enough as there could be other metadata tied to DIT nodes, like ACLs, that must also be reinstated on the new nodes.

Sorry for my hasty post earlier.

-Eddie

Loading...