Overview
Enterprise Manager (EM) supports these authentication types:
Local Managed and Unmanaged users
LDAP / Active Directory
OAuth (Azure AD / Entra ID / Okta / other IDPs)
A significant issue occurs when a user or admin switches from LDAP/AD to OAuth, especially when their OAuth identity provider is synchronized with Active Directory.
When EM previously imported AD users, and the same usernames later appear through OAuth, EM ends up with two identity records for the same username—each with a different authentication type. EM does not currently merge or migrate these identities, resulting in authentication failures and user/role synchronization problems.
If EM was connected to LDAP/AD at any point, it stored users in the DB with:
auth_type = ldap
When a customer later switches to OAuth (usually via Azure AD/Entra ID), EM receives the same usernames as:
auth_type = oauth
Because EM treats these as different identity types, EM cannot reconcile them.
This causes:
-OAuth login failures
-Failed user and role synchronization
-Importer update errors
-Permissions not updating on NVRs
Customer symptoms include:
-OAuth logins fail
-Roles and permissions defined in EM do not sync to NVRs
-Group/role mappings appear to apply but never propagate
-Importer logs show repeated user update warnings
Logs May show the following or similar:
WARNING [Importer2:XXXX,ServerUserAndPrivilegeManager:XXXX,users.py:75]
Failed to update evapi user on server_id: user: , userrole: is_ldap: False as owner:
or:
OAuth login failed: user exists with different authentication type
This indicates EM attempted to update a user whose stored auth_type does not match the method currently expected (OAuth vs LDAP) and will likely result in log in failures and other undesirable cascading effects. These rarely surface in the UI but appear in detailed logging.
This scenario occurs when:
-The customer previously had LDAP/AD integration in EM
-They later switch EM authentication to OAuth
-Their OAuth provider is synchronized with Active Directory
-The same usernames appear again under the OAuth provider
-The legacy LDAP entries remain in the EM database
Because EM does not currently have logic to migrate, merge, or warn about auth-type conflicts, it fails on authentication and synchronization.
Failure to prevent this causes major operational issues:
- OAuth logins fail
EM rejects authentication because the LDAP identity already exists. - User/role synchronization fails
Permissions configured in EM do not propagate to NVRs. - Importer threads halt on conflicted users
Role mapping and updates fail silently. - Troubleshooting becomes misleading
Symptoms resemble EVAPI or SQL problems even though root cause is identity conflict. - Cleanup can require DB rebuild
Production sites may require SQL cleanup with L3 assistance.
Warning: Before a customer switches authentication methods:
Step 1 – Determine whether EM used AD/LDAP before
Ask:
“Has your Enterprise Manager ever been connected to Active Directory or LDAP?”
Step 2 – Confirm whether their current OAuth IDP syncs with AD
If yes, duplicate usernames are expected.
Step 3 – Remove legacy AD entries before enabling OAuth:
Option A (recommended for non‑production or new deployments):
Rebuild the EM database to clear all LDAP/AD identities cleanly.
Option B (for production systems):
Open an L3 case to guage whether we can remove LDAP users via SQL.
Do not delete LDAP users through the EM UI without guidance.
Step 4 – Enable OAuth only after LDAP identities are fully removed
A fix to prevent this issue is planned for the next release of ExacqVision Enterprise Manager.
This fix is expected to:
-Detect when a username exists under multiple authentication types
-Provide warnings or UI feedback
-Prevent creation of conflicting identities
-Potentially support identity migration or cleanup logic
Escalate when:
-The customer is already in production
-LDAP entries cannot be safely removed from UI
-SQL cleanup is required
-OAuth continues to fail after cleanup
-Importer logs show repeated failed evapi user update entries
Include the following:
- Full EM Debug Level Support Diagnostic Logging
-Summary of authentication method history
-IDP/AD sync information
-Names of affected users
Error Log Reference (for quick identification):
WARNING [Importer2:XXXX,ServerUserAndPrivilegeManager:XXXX,users.py:75]
Failed to update evapi user … is_ldap: False
This is the primary signature of a conflicting LDAP/OAuth user record.
Final Notes:
This issue is preventable through proper sequencing.
L2 must proactively warn customers who are migrating from AD to OAuth.
A fix is coming in the next EM release, but until then, cleanup or DB rebuild is required.
EM does not yet support automatic identity migration between auth types.