The current LDAP node appears to hide a modifyDN / rename failure when newSuperior exceeds 127 bytes while moving a user to another OU. In this case, the node can report success even though the DN change is not actually applied.
This behavior matches an upstream ldapts bug in modifyDN long-form BER length encoding for newSuperior. The issue was fixed upstream in ldapts7.2.2 with:
“Fix modifyDN newSuperior not working with the long form.” (#162)
At the moment, n8n still uses an older ldapts version (4.2.6 in the current upstream packages/cli/package.json), so this fix does not seem to be included yet.
My use case:
We run an automation between our HR system and Active Directory. The workflow updates existing users and moves them into the correct OU based on our company structure.
This currently fails for deeper / longer OU paths. We were able to reproduce that:
short newSuperior paths work,
longer newSuperior paths fail silently or behave inconsistently,
manual moves in Active Directory work,
the issue starts when the newSuperior DN exceeds the BER short-form length boundary of 127 bytes.
In our case this breaks production-relevant organizational moves because our company structure creates long OU paths.
I think it would be beneficial to add this because:
This would fix a real data consistency problem in the LDAP node.
Right now, a workflow can report a successful rename while the user remains in the old OU. That is particularly dangerous because downstream steps continue under the assumption that the DN change has already happened.
Fixing this in n8n would:
prevent silent LDAP rename failures,
make Active Directory syncs with deep OU structures reliable,
align n8n behavior with the upstream ldapts fix,
reduce the need for custom forks or workarounds in enterprise environments.
Any resources to support this?
Upstream references:
ldapts changelog:
7.2.2 - Fix modifyDN newSuperior not working with the long form. #162
Additional reproduction details from our environment:
Moves to short target OUs work.
Moves to longer target OUs can return success without actually moving the user.
We measured examples where a working newSuperior was below 127 bytes and failing examples were above 127 bytes.
Manual GUI moves in AD succeed for the same users and the same target OUs, which strongly suggests the problem is in the LDAP client path rather than permissions or AD itself.
Are you willing to work on this?
Yes. I am willing to work on this and can help with reproduction details, testing, and a fork if needed.
welcome to the community @kayjix
I think the most important confirmation now would be to test this outside of n8n, reproduce the same scenario with ldapts 4.2.6 and then repeat exactly the same test with ldapts >=7.2.2. If the problem disappears just by switching the library version, that would strongly support the hypothesis of a bug
I reproduced the issue outside of n8n with a minimal standalone ldapts CLI test against the same AD test system.
The test used the exact same oldDn and newDn in both runs. The only difference was the ldapts version:
ldapts 4.2.6
ldapts 8.1.7
For the tested target path, newSuperior was 132 bytes long, so it is above the 127-byte boundary.
Result:
With ldapts 4.2.6, the rename scenario showed the problematic behavior.
With ldapts 8.1.7, the same rename worked correctly.
So the behavior changes only with the library version, while the LDAP server, credentials, source DN, and target DN stayed the same.
This strongly supports that the issue is caused by the old ldaptsmodifyDN handling and not by n8n workflow logic, credentials, permissions, or the OU itself.
I will also attach screenshots for both runs, including before/after verification.
As mentioned before, version 4.2.6 gives a false positve “success” although the operation was an error due to byte size > 127. Same as mentioned in the ldapts repo pull request #162.
Can you share the test so we can validate it together?
If you’re more comfortable, you can send it to me through the private messages here in the community.
I anonymized the shared example values before uploading it, so the repo does not contain our real internal hostnames, DNs, users, or company-specific LDAP paths.
I also can’t provide access to our LDAP test server, so anyone who wants to validate the repro will need to run it against their own LDAP / AD test environment and fill in their own connection details in the .env file.
The repro is intentionally minimal and only covers the modifyDN(oldDn, newDn) comparison between the two ldapts versions.
And as mentioned before, the issue is known for some time and has been patched in version 7.2.2.
The user Oh-suki has confirmed this via wireshark in 2024.
Thank you for the exchanges, I learned a lot from this case, from the analysis and reproduction you presented. I see a strong indication of a functional issue related to the current version of the ldapts library used by n8n. I think it makes sense to forward/register it as a known issue, leaving the final confirmation to the maintainers.
@tamy.santos
Alright, love to do that, but the known issue tab is restricted.
Are you able to foreward this this thread to the section or who else has to be contacted to do this?
yes, I can access and view the currently 10 open tasks, but I am neither able to open a new thread in this category nor move my thread to it. As far as I know, moving a thread is only possible within the first few minutes for default users, so I would need someone to either move this thread or open a new one on my behalf.
When creating a new thread, I see the option to click on “Known Issue”, but nothing happens. For other categories, such as “Questions”, I can click and select them without issue — “Known Issue” simply cannot be selected.
