What is a one sentence summary of your feature request?
Enable EPP administrators to define how users are identified and matched between the EPP client and Entra ID to prevent duplicate or unmapped users.
Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.
In environments using Microsoft Entra ID (Azure AD) for directory synchronization, the primary user identifier is typically the User Principal Name (UPN) (e.g., user@domain.com).
Currently, the EPP clients collects the Windows sAMAccountName (legacy logon name) as the user identity. However, the Entra ID integration in the EPP console syncs users based on UPN.
Because these identifiers are different, EPP cannot correctly correlate endpoint activity with the synchronized Entra ID user. This leads to:
- Duplicate user entries
- Unmapped endpoint activity
- Confusion in reporting
- Challenges when applying user-specific policies
- Increased administrative overhead
Why This Creates Confusion:
Modern identity environments are built around Entra ID, where UPN is the authoritative and commonly used identity format across cloud and security platforms. When EPP relies on a different attribute for identifying users than the one used in directory synchronization, the system no longer reflects the organization’s real identity structure.
This discrepancy creates confusion for administrators reviewing reports or enforcing policies because the same individual may appear under multiple identities or fail to map correctly.
Additionally, customers may raise questions about reporting accuracy or policy scope, and without flexibility in how users are identified, it becomes difficult to provide a clean and consistent explanation aligned with their identity model.
What Would Help Resolve the Issue:
EPP administrator would benefit from the ability to decide how users (and potentially computers) are identified and matched between:
- the EPP client
- the EPP web interface
- Entra ID
Allowing administrators to align identity matching with how their organization defines users in Entra ID would:
- Eliminate duplicate or unmapped users
- Improve reporting clarity
- Ensure user-based policies apply correctly
- Reduce confusion and support escalations
- Align EPP behavior with modern identity-first environments
The key need is flexibility so that EPP reflects the company’s actual identity structure rather than enforcing a fixed identification method.
How do you currently solve the challenges you have by not having this feature?
At this time, there is no configurable option to adjust how the agent reports user identity or how the console maps directory users.
As a result, administrators must:
- Manually reconcile duplicate or unmatched accounts
- Validate reports carefully to ensure correct user attribution
- Apply broader policies (e.g., at device or group level) when per-user enforcement becomes unreliable
- Accept inconsistencies between EPP agent and directory synchronization
These workarounds increase administrative effort and reduce clarity in environments that rely heavily on Entra ID as the identity authority.