Duplicate Usernames and MFA After a Merger
PingFederate is the IdP for 1,200 employees after a merger. Users authenticate through an HTML Form adapter backed by an LDAP password credential validator. The merged company has two AD domains, CORP and CONTRACTOR, and 40 contractor accounts have the same sAMAccountName as employee accounts (for example, jsmith exists in both). Contractors must use MFA when they are remote; corporate employees on the office network do not. The current policy tree has a single branch: form login, then MFA for everyone. Since the merger, the 40 contractors sometimes bind to the CORP account and receive employee attributes, and the help desk has disabled the MFA branch to stop lockouts. Remote contractors report failed logins, and audit logs show repeated invalid credentials. You need to restore secure access without asking all 1,200 users to change their usernames.
1. Diagnose why the contractors bind to the wrong account and propose a fix that preserves the user experience for the other 1,160 employees.
Read the worked answer
The collision is at authentication, not authorization. A single form adapter and PCV search both domains by sAMAccountName; LDAP returns the first match, often CORP, so the contractor authenticates as an employee before policy can branch. Disabling MFA made the security posture worse but did not fix the bind.
Fix the identity before the bind. Options in order of preference:
- Require UPN or domain-qualified login for everyone, such as [email protected] or CORP\jsmith. This is unambiguous and can be normalized by the form adapter.
- Route contractors to a separate authentication endpoint or IdP connection tied to the CONTRACTOR directory, while employees use the existing endpoint.
- Reject ambiguous input rather than silently choosing one directory.
A post-authentication attribute branch cannot reliably fix a wrong bind because the wrong account is already authenticated. For only 40 contractors, a separate endpoint is acceptable; for the long term, UPN is cleaner. Re-enable MFA only after the bind is correct, and test with the known duplicate accounts.
2. Design the authentication policy tree for MFA by network zone and population. What must be true for the zone condition to be trustworthy?
Read the worked answer
Use a fail-closed tree: first factor form and PCV, then a branch on network zone and population. Contractors always require MFA. Remote employees require MFA. Employees on the corporate network do not require MFA.
The zone condition is trustworthy only if PingFederate sees the real client IP. Confirm the load balancer preserves the client address or that PingFederate is configured to trust the correct forwarded-for header only from the load balancer. Do not trust a header supplied by the browser. If the zone is unknown, require MFA rather than allowing access.
Contractor status must come from the correct directory after the bind. If contractor status must drive MFA, the bind must already be unambiguous; otherwise the policy may read the employee record. Keep the MFA branch enabled and monitor lockouts by directory, adapter, and zone. Use group or attribute data from the correct domain, not from a global search that can return the wrong entry.