Introduction

An identity migration can move LDAP authentication to a new directory while Duo Authentication Proxy still sends primary auth to the old one. Users still see MFA prompts, but password validation continues hitting the retired directory, one proxy node uses the new LDAP server while another still follows the previous bind target, or failures begin only after the old domain controller or LDAP service is removed because authproxy.cfg, section mappings, and deployment automation often drift separately.

Treat this as an upstream-authentication target problem instead of a generic Duo outage. Start by checking which LDAP server and client section an affected proxy request actually uses, because migrations often validate Duo cloud connectivity first while live primary-auth flows continue following older proxy configuration.

Symptoms

  • Duo Authentication Proxy still sends LDAP authentication to the old directory after migration
  • MFA appears normal, but password validation still depends on the retired LDAP service
  • One proxy node or application uses the new directory while another still uses the previous one
  • Authentication failures begin only after the old directory server, bind account, or certificate is removed
  • The new directory is healthy, but migrated primary-auth requests never use it consistently
  • The issue started after moving LDAP directories, Duo proxy nodes, or application authentication paths

Common Causes

  • authproxy.cfg still points the relevant LDAP client section to the old server or host list
  • An application or RADIUS section still maps to the previous upstream LDAP client definition
  • One proxy node was updated while another still uses the earlier directory target
  • Deployment automation, package rollout, or config management restored older proxy settings
  • Certificates, bind settings, or failover lists were updated partially, leaving the old directory path active
  • Validation confirmed the new directory worked in isolated tests but did not verify which upstream target live Duo proxy requests actually used

Step-by-Step Fix

  1. Capture one affected authentication path and record the listening integration, mapped client section, LDAP server target, and proxy node it actually uses, because the live primary-auth path determines where credentials are really validated.
  2. Compare that active proxy path with the intended post-migration identity design, because one stale client mapping can keep large authentication flows tied to the retired directory.
  3. Review authproxy.cfg, LDAP client sections, application or RADIUS mappings, bind settings, failover hosts, and deployment templates for references to the old directory, because Duo Authentication Proxy behavior depends on both upstream client definitions and listener-to-client mappings.
  4. Check each proxy node, application integration, and authentication path separately if behavior differs, because migrations often update one flow while another still uses the previous directory target.
  5. Update the authoritative LDAP target and section mapping so affected requests authenticate against the intended directory, because standing up the new LDAP service alone does not retarget existing Duo proxy flows.
  6. Run a controlled authentication test and confirm the intended directory handles primary auth for the expected integration, because a successful MFA prompt does not prove the right upstream directory validated the password.
  7. Verify the old directory no longer receives LDAP bind or search traffic from migrated Duo proxy nodes, because split identity paths can remain hidden while both directories stay reachable.
  8. Review certificates, bind permissions, failover order, and time sync if authentication still fails, because the destination can be correct while TLS trust or directory policy still blocks the new path.
  9. Document which team owns proxy config, section mappings, and migration validation so future Duo cutovers verify the actual runtime LDAP target before retiring the previous directory.