ACRM Windows/IIS SSO Logs In Inactive or Wrong Account (Duplicate Windows Domain/User Mapping)

Solution

Issue (Symptoms)

In ACRM (reported on 15.25.2) using Windows/IIS SSO (NTLM/Kerberos):

• Inactive employees/accounts can still authenticate via SSO.
• If an active and inactive ACRM Login are both mapped to the same Windows identity, ACRM may log the user in as the inactive account.

Environment / Context

• Module: CRM Web (CRM.Web)
• SSO method: IIS Windows Authentication (NTLM/Kerberos), often used alongside Azure Entra ID / Windows Integrated Authentication (WIA)

How to recognize this issue

You are likely affected if either of the following is true:

1. An “inactive” ACRM user can still open CRM.Web and is automatically logged in (SSO still resolves them to a Login).
2. A single Windows identity (same domain + username) sometimes logs into the “wrong” ACRM Login (commonly an inactive/legacy login).

Root cause (What’s happening)

1. IIS/Windows authenticates first (NTLM/Kerberos).
2. ACRM maps the authenticated identity by finding a Login (US) record that contains:
   • Windows Domain
   • Windows User Name

If the mapping exists on any Login (US), ACRM has enough information to complete SSO mapping for that Windows identity.

If multiple Login (US) records contain the same Windows Domain + Windows User Name, the configuration is ambiguous and ACRM may select an unintended login (effectively “first match wins” behavior). There is no supported “prefer active user” disambiguation for duplicates—duplicates must be removed.

Troubleshooting & Investigation

1) Confirm what Windows identity IIS is presenting

• From a domain-joined workstation/browser, access CRM.Web and confirm the Windows identity being used for Windows Authentication.
• If needed, use an IIS test approach to display the authenticated user so you can confirm the exact DOMAIN\username (or equivalent) value IIS passes.

Record the values as:

• <windows_domain>
• <windows_username>

2) Audit ACRM user mappings for duplicates

In ACRM, search in Login (US) for records where:

• Windows Domain = <windows_domain>
• Windows User Name = <windows_username>

If more than one Login (US) record matches, SSO mapping is ambiguous and must be cleaned up.

3) Check inactive/legacy logins still holding mappings

For users who should not access ACRM anymore:

• Verify whether their Login (US) record still contains Windows Domain / Windows User Name.
• Verify whether any other Login (US) record (including inactive/legacy) still contains the same mapping.

4) Validate IIS configuration for Windows SSO

In IIS for the CRM.Web site/application:

• Ensure Windows Authentication = Enabled
• Ensure Anonymous Authentication = Disabled
• Confirm the provider configuration matches your supported setup (commonly NTLM as required by your deployment standard)

Misconfiguration can change how identities are presented and complicate mapping cleanup.

Supported Remediation / Best Practice

A) Remove SSO access for inactive users (required)

For each user who must no longer access ACRM via Windows/IIS SSO:

1. Deactivate the ACRM user
   • Mark the Rep/user as Inactive using your standard deactivation process.
2. Remove the SSO mapping from Login (US)
   • Open the user’s Login (US) record.
   • Clear:
     • Windows Domain
     • Windows User Name
   • Save.

Result: Even if the Windows account can still authenticate to IIS, ACRM will no longer be able to resolve that Windows identity to an ACRM Login via SSO.

B) Eliminate duplicate mappings (required)

1. Identify every Windows identity (<windows_domain> + <windows_username>) that appears in more than one Login (US) record.
2. Decide which single Login (US) should own that mapping (typically the active/current login).
3. Remove the mapping (clear Windows Domain / Windows User Name) from:
   • inactive logins
   • legacy logins
   • any duplicate logins

Target state (best practice): Exactly one Login (US) record contains a given Windows Domain + Windows User Name mapping.

C) If using modern CRM.Web SSO (OIDC-style) instead of IIS/NTLM

If your deployment uses the CRM.Web “button-based” SSO (for example, Azure AD / Google OAuth configured via users.xml) rather than IIS Windows Authentication:

• Ensure the selected claim (NameClaimType) maps uniquely to exactly one active ACRM user identity.
• Remove or disable the mapping for inactive users so they cannot be resolved to an ACRM login.

Verification (Post-fix Checks)

1. Previously inactive user
   • Attempt SSO login again.
   • Expected: the user is not automatically logged into CRM.Web because the mapping no longer exists. Depending on your setup, they may see the standard login page or an authorization failure, but they should not land in an ACRM session.
2. Previously ambiguous/duplicate mapping user
   • Attempt SSO login multiple times.
   • Expected: the user is consistently logged into the intended (active) ACRM Login.
3. Mapping uniqueness audit
   • Re-run the Login (US) search for <windows_domain> + <windows_username>.
   • Expected: exactly one record matches for each Windows identity.