n8n - 💡(How to fix) Fix LDAP Node: Byte Overflow DN (newSuperior) > 127 Bytes - chore(nodes-base): Bump ldapts to 8.1.7 (>7.2.2)

Bug Description

From: https://community.n8n.io/t/update-ldapts-version-4-2-6-8-1-7-7-2-2/296158

The idea is: 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 ldapts 7.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 Upstream fix PR: fix: modifyDN newSuperior not working with long form by Oh-suki · Pull Request #162 · ldapts/ldapts · GitHub Related upstream issue: ModifyDN not working with over 8 nested OUs · Issue #147 · ldapts/ldapts · GitHub 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.

To Reproduce

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 ldapts modifyDN 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.

<img width="1186" height="326" alt="Image" src="https://github.com/user-attachments/assets/1da00899-ce21-4c1e-90c3-60bdba08c0c9" /> <img width="718" height="123" alt="Image" src="https://github.com/user-attachments/assets/1cd25e3f-5521-421d-b4f3-16bd25a25e35" /> <img width="1194" height="331" alt="Image" src="https://github.com/user-attachments/assets/a19b0edf-f40c-4330-ac7b-c8b081f11f00" /> <img width="878" height="163" alt="Image" src="https://github.com/user-attachments/assets/df208884-15d9-4508-a1fd-003f6aac9412" />

Expected behavior

A rename operation inside the ldap node should move a user from one OU to another OU. In the current ldapts Version inside of n8n (4.2.6): newSuperior > 127 Bytes = false positive "success" In tested version 8.1.7: newSuperior > 127 Bytes = success

Expected: actual success.

Debug Info

bump version to >7.2.2, preferably to the current 8.1.7

Operating System

Unknown to me - hosted in Azure / Docker

n8n Version

2.20.11

Node.js Version

24+

Database

PostgreSQL

Execution mode

main (default)

Hosting

self hosted