Context

The ldif npm parser stores the modify operation (add/delete/replace) in change.type, but the code was reading change.operation — which is always undefined. This caused the fallback to "replace" for all modify operations.

Impact:

• add: member in LDIF was silently sent as replace, overwriting all existing group members instead of adding one
• delete: member in LDIF was silently sent as replace, overwriting all group members instead of removing one
• replace: userPassword happened to work correctly by accident (the fallback matched the intended operation)

This bug affects any LDAP dynamic secret using changetype: modify with add: or delete: operations — including the Active Directory group membership example in Infisical's own LDAP docs. It is also a blocker for IBM DB2 dynamic secrets via LDAP, which require adding/removing users from LDAP groups.

No existing working configurations are broken by this fix. Users relying on replace: operations (e.g., static credential rotation) are unaffected since the fallback already matched.

Steps to verify the change

1. Confirm the ldif npm package uses change.type (not change.operation) for modify operations:

   const ldif = require('ldif');
   const parsed = ldif.parse(`dn: cn=test,dc=example,dc=com\nchangetype: modify\nadd: member\nmember: uid=user\n-\n`);
   console.log(parsed.entries[0].changes[0].type);       // "add"
   console.log(parsed.entries[0].changes[0].operation);   // undefined

2. Set up an LDAP dynamic secret with a Creation LDIF that uses changetype: modify + add: member (e.g., the AD example from docs)
3. Generate a lease and verify the user is added to the group (not replacing all members)

Type

• Fix
• Feature
• Improvement
• Breaking
• Docs
• Chore

Checklist

• Title follows the conventional commit format
• Tested locally (verified parser output; no integration test against a live LDAP server)
• Updated docs (if needed)
• Read the contributing guide

Human review notes

• The fix is a two-line change: updating the TEntry type and the property access from change.operation to change.type
• Key thing to verify: confirm that the ldif npm package (the version used in this repo) indeed uses type and not operation on parsed change objects
• No risk to existing replace: workflows — the fallback || "replace" still applies if change.type were ever undefined

Link to Devin session: https://app.devin.ai/sessions/54d3af210fc54c1a957018979fa8abc5
Requested by: ashwin (ashwin@infisical.com)