A complete reference for implementing least privilege delegation using standard Microsoft mechanisms – and a migration path for ADManager customers looking to migrate to EasyEntra.
1. Delegation with EasyEntra: Native, Simple, Trusted
Delegation is a cornerstone of secure and efficient IT operations. It:
- Gives users only the access they need to do their job
- Enables safe handover of routine tasks to helpdesk or junior IT
- Ensures every action can be traced through standard auditing
EasyEntra is designed to work directly with Microsoft’s native delegation model, making it possible to grant least privilege access without introducing extra service accounts, infrastructure, or logging systems. By relying on the same roles, scopes, and security boundaries used in Microsoft’s own admin tools, EasyEntra provides a secure, transparent, and easy-to-maintain delegation model that aligns naturally with modern hybrid and cloud environments across Active Directory, Entra ID, and Exchange Online.
For organizations that are currently using ADManager, this guide also provides a clear explanation of how the two approaches differ – and how to migrate to EasyEntra while preserving least privilege delegation and operational control.
This guide explains:
- The fundamental difference between EasyEntra and ADManager delegation models.
- How to configure least privilege delegation in AD, Microsoft Graph/Entra ID, and Exchange Online.
- How to migrate from ADManager to EasyEntra without losing functionality.
- How to troubleshoot and audit permissions effectively.
2. Delegation Models: EasyEntra vs. ADManager
2.1 EasyEntra Delegation Model (Native Microsoft Permissions)
EasyEntra builds directly on Microsoft’s standard delegation model. Users sign in with their own identity – the same account they use to access tools like Active Directory Users and Computers, the Entra admin portal, or the Exchange admin center.
There’s no elevated service account, no extra database, and no middleware to maintain. Permissions are granted using Microsoft’s native mechanisms:
- AD security delegation
- Entra ID roles with Admin Units
- Exchange RBAC scopes
Because EasyEntra uses the same identity and permissions as the native tools, everything is fully auditable through Microsoft’s built-in logging (AD security logs and the MS Graph Unified Audit Log).
In the unlikely event that EasyEntra is unavailable, administrators can continue their work directly in Microsoft’s native portals and tools without any disruption. Delegation is defined in the infrastructure itself – not in the application – which means no loss of control if the tool is offline.
This makes delegation transparent, stable, and easy to troubleshoot.
2.2 ADManager Delegation Model (Service Account + Custom Layer)
ADManager takes a different approach. It relies on a highly privileged service account with full access to the environment. Delegation is configured and enforced inside ADManager’s own database, not in Microsoft’s native security model.
This creates a dependency on the ADManager platform itself. If the service account is locked, the system is misconfigured, or ADManager is down, delegated management stops working entirely – even though users may have no issues signing into Microsoft directly.
Troubleshooting also becomes more complex because admins need to check both Microsoft and ADManager layers to identify the root cause. And because the service account typically has broad privileges, any misconfiguration or bug increases the potential attack surface.
This model can potentially provide more granular delegation options, but it comes with added complexity, more moving parts, and a higher operational risk.
2.3 Comparison Table: EasyEntra vs. ADManager
| Permission model | EasyEntra | ADManager (ManageEngine) |
|---|---|---|
| Permission model | Standard Microsoft delegation (native) | Service account with full access |
| Installation / infra | No server, no DB | Requires server + SQL DB |
| Security model | No privilege escalation | Elevated privileges → risk of misconfiguration |
| Auditing | Microsoft unified audit logs | Custom DB logs (lower trust level) |
| Troubleshooting | Uses native permissions = transparent | Extra layer = more complexity |
| Delegation granularity | Based on the Microsoft model | Potentially more granular, but adds complexity |
| Maintenance | Lightweight | Heavy (installation, upgrades, patching) |
| Exploit surface | Low | Additional layer = additional risk |
| Fallback if the tool is down | Continue management via standard tools (ADUC/Entra ID/Exchange Online) | Delegation no longer works if ADManager fails |
| Trust model | Based on Microsoft identity and auditing | Based on custom application security model |
3. Key Principles of Delegation with EasyEntra
EasyEntra is designed to work with the permissions you already have in Microsoft 365 and Active Directory. There’s no separate security model to learn, no extra infrastructure to maintain, and no service account dependency.
- No service accounts – All actions are performed under the user’s own identity, ensuring accountability and reducing attack surface.
- Same permissions everywhere – If a user can perform an action in Microsoft’s native tools, they can do the same in EasyEntra. If EasyEntra is unavailable, work can continue directly in ADUC, Entra ID, or Exchange Online.
- Standard delegation model – Permissions are set where they belong: in AD, Entra ID, and Exchange Online, following Microsoft’s recommended practices.
- Automatic auditing – All activity is logged in Microsoft’s trusted audit systems, so there’s no need to manage a separate custom low-trust audit database.
- One configuration, multiple tools – Once delegation is set up, it applies not only to EasyEntra but also to all native Microsoft admin interfaces.
- No vendor lock-in – Because EasyEntra uses standard Microsoft delegation, removing or replacing the tool does not affect your security model or access structure.
This approach keeps delegation simple, transparent, and secure, while avoiding unnecessary layers of complexity.
4. Active Directory Delegation for EasyEntra
EasyEntra respects and uses the delegation already defined in Active Directory. If a user has permission to perform an action in ADUC, they can do the same in EasyEntra – no extra configuration or service account needed.
4.1 Typical Use Cases
- Delegate password resets and basic user management to Helpdesk.
- Allow regional IT teams to manage users in their own OUs.
- Limit who can create, disable, or delete accounts.
- Delegate group membership management for specific OUs.
4.2 Step-by-Step Delegation
- Open Active Directory Users and Computers.
- Right-click the target OU and choose Delegate Control…
- Add the security group or user(s) to delegate.
- Select the specific tasks (e.g., reset passwords, create/delete accounts).
- Complete the wizard and verify effective permissions.
- (Optional) Use dsacls or Advanced Security Settings for a detailed review.
4.3 Best Practices
- Delegate to security groups, not individuals.
- Use clear OU boundaries to avoid permission sprawl.
- Review delegated rights regularly and document changes.
- Keep delegation task-specific to follow least privilege principles.
- Test delegated access in EasyEntra and ADUC to confirm expected behavior.
5. Microsoft Graph / Entra ID Delegation
EasyEntra uses the standard Microsoft Entra ID delegation model, so all permissions are configured directly in Entra ID – not inside EasyEntra. Because EasyEntra relies on standard OAuth2 authentication, EasyEntra fully supports and complies with MFA, PIM, FIDO2, and Conditional Access policies. This ensures your security and compliance controls apply consistently across both EasyEntra and native Microsoft tools.
5.1 Typical Use Cases
- Allow Helpdesk to manage user attributes for a specific region or department.
- Grant delegated admins limited rights within their own business unit.
- Enable specialized roles (e.g., onboarding teams) to manage users without tenant-wide access.
- Scope admin permissions for compliance, security, or operational boundaries.
5.2 Step-by-Step Delegation
- Create an Admin Unit (AU) to define the scope (e.g., region, department, location).
- Assign the role (e.g. User Administrator) within the AU, ensuring the user only has access to that scope.
- Test delegated access by signing in with the delegated account.
- Verify behavior in both EasyEntra and the Entra admin portal to confirm alignment.
- (Optional) Use Access Reviews or PIM to strengthen governance.
5.3 Best Practices
- Always scope roles to AUs rather than assigning tenant-wide rights.
- Follow least privilege principles and assign only what’s needed.
- Regularly audit role assignments and AU membership.
- Use security groups to simplify delegation and keep access clean.
- Document delegation decisions for easier maintenance and compliance.
- Leverage MFA, Conditional Access, and PIM to further secure delegated roles.
6. Exchange Online Delegation
EasyEntra works with Exchange Online’s native RBAC model. Permissions are defined and enforced directly in Exchange, and delegation aligns fully with Microsoft’s standard authentication and security controls.
Because EasyEntra uses standard OAuth2 authentication, it fully supports MFA, PIM, FIDO2, and Conditional Access, so delegated access follows the same security posture as the rest of your Microsoft 365 environment.
6.1 Typical Use Cases
- Allow Helpdesk to manage mailboxes in specific departments or locations.
- Let Tier 2 IT handle distribution groups, shared mailboxes, and recipient properties.
- Restrict access to only a subset of users for compliance or operational reasons.
- Delegate mailbox management without granting global Organization Management rights.
6.2 Step-by-Step Delegation
- Assign the Entra ID role “Exchange Recipient Administrator”
- This role covers most day-to-day Exchange management tasks, including managing mailboxes, groups, and recipients.
- Access can be limited with Exchange Management Scopes to ensure least privilege.
- Be aware of role limitations
- This role does not grant the right to create mail-enabled security groups or modify their memberships.
- These permissions can be delegated using Exchange Online RBAC roles (e.g., Security Group Creation and Membership).
- Optionally, create suitable management scopes to define management boundaries (e.g., filter recipients by department, country, or other attributes).
- Link the management scope with Exchange roles and an admin (delegation) group.
- If needed, create or assign additional RBAC role groups for specific functions.
- Add delegated admin users to the appropriate admin (delegation) group.
- Test access with a delegated account to verify expected behavior in EasyEntra and the Exchange admin center.
PS C:\> New-ManagementScope HelpdeskDE -RecipientRestrictionFilter {CountryOrRegion -eq 'Germany'}
Name ScopeRestrictionType Exclusive RecipientRoot RecipientFilter ServerFilter
---- -------------------- --------- ------------- --------------- ------------
HelpdeskDE RecipientScope False CountryOrRegion -eq 'Germany'
PS C:\> New-ManagementRoleAssignment -Role "Mail Recipients" -SecurityGroup "Helpdesk DE" -CustomRecipientWriteScope "HelpdeskDE"
Name Role RoleAssigneeName RoleAssigneeType AssignmentMethod EffectiveUserName
---- ---- ---------------- ---------------- ---------------- -----------------
Mail Recipients-Helpdesk DE Mail Recipients Helpdesk DE SecurityGroup Direct
PS C:\> New-ManagementRoleAssignment -Role "Mail Recipient Creation" -SecurityGroup "Helpdesk DE" -CustomRecipientWriteScope "HelpdeskDE"
Name Role RoleAssigneeName RoleAssigneeType AssignmentMethod EffectiveUserName
---- ---- ---------------- ---------------- ---------------- -----------------
Mail Recipient Creation-Helpd… Mail Recipient Creati… Helpdesk DE SecurityGroup Direct
PS C:\> New-ManagementRoleAssignment -Role "Distribution Groups" -SecurityGroup "Helpdesk DE" -CustomRecipientWriteScope "HelpdeskDE"
Name Role RoleAssigneeName RoleAssigneeType AssignmentMethod EffectiveUserName
---- ---- ---------------- ---------------- ---------------- -----------------
Distribution Groups-Helpdesk … Distribution Groups Helpdesk DE SecurityGroup Direct6.3 Best Practices
- Use Exchange Recipient Administrator for most delegated scenarios and refine access with Management Scopes.
- Delegate mail-enabled security group creation and membership through Exchange RBAC roles if required.
- Avoid assigning Organization Management unless absolutely necessary.
- Always delegate to security groups instead of individuals.
- Review and document role assignments and scopes regularly.
- Enforce MFA, PIM, and Conditional Access to secure elevated access.
7. Migration Guide: From ADManager to EasyEntra
Migrating is about moving from in-app, service-account delegation to native Microsoft delegation with users’ own identities.
7.1 Step-by-Step Migration
- Inventory current ADManager delegation
- Who can do what, over which users/groups/contacts/mailboxes.
- All permissions delegated via the highly privileged ADManager service account must be translated to direct permission assignment.
- Map ADManager → Microsoft-native delegation
- Active Directory: Translate in-app ADManager delegation to direct OU delegation in AD (e.g., password resets, group membership, create/disable users) using the Delegate Control wizard or ACLs on the OU.
- Entra ID: Replace app-level rules with built-in roles (e.g., User Administrator, Authentication Administrator) scoped by Admin Units.
- Exchange Online: Use Entra ID “Exchange Recipient Administrator” for most tasks and limit scope with Exchange Management Scopes (e.g., by department, country, or attributes).
- Note: this role does not allow creating mail-enabled security groups or modifying their membership—delegate that via Exchange RBAC roles.
- Remove service account dependency
- Admins use their own identities with MFA / PIM / Conditional Access / FIDO2.
- Validate in native tools
- Confirm delegated actions work in ADUC, Entra portal, and the Exchange admin center.
- Confirm the same behaviors in EasyEntra.
- Verify auditing
- Activity appears in AD security logs, Unified Audit Log, and Exchange audit—no custom log DB.
- Transition gradually
- Migrate role-by-role; run in parallel if needed.
- Decommission ADManager delegation
- Retire service-account permissions and app-level rules to improve the security posture.
7.2 Benefits of the native model
- No vendor lock-in; security lives in the native Microsoft architecture.
- Lower risk; no over-privileged service account.
- Operational resilience; native tools remain usable at all times with proper delegation.
- Simpler troubleshooting; one security layer, standard audit logs.
8. Troubleshooting Delegation
Troubleshooting delegation with EasyEntra is straightforward because all permissions are defined directly in Microsoft’s native layers – not in a separate application. This means issues can be identified and resolved using standard Microsoft tools.
8.1 What to Check
- Active Directory
- Use Effective Permissions or dsacls to verify delegated rights on the OU.
- Ensure the correct security group or user has the expected permissions.
- Check for conflicting ACEs or inheritance issues.
- Entra ID
- Verify assigned roles and Admin Unit (AU) memberships.
- Confirm the user has the correct role within the intended AU, not at the tenant level.
- Check Conditional Access, MFA, or PIM assignments if access is unexpectedly blocked.
- Exchange Online
- Check RBAC role group membership and Management Scopes.
- Ensure the scope filters match the intended target objects (e.g., department, OU, region).
- Confirm the role covers the specific action (e.g., mailbox management vs. security group membership).
8.2 Common Issues
- Missing or incorrect AU assignments in Entra ID.
- Management Scope not applied correctly in Exchange.
- OU structure or delegation misaligned with operational needs in AD.
- Insufficient permissions due to Conditional Access, MFA, or PIM settings.
8.3 Why Troubleshooting Is Easier with EasyEntra
- No custom delegation or service account layer to investigate.
- All configurations are visible in standard Microsoft admin tools.
- Faster root cause analysis, fewer moving parts, and simpler remediation.
9. Security and Compliance Advantages
EasyEntra inherits its security and compliance posture directly from Microsoft’s native platform. Because it relies on standard identities, native permissions, and OAuth2 authentication, there’s no separate security model or service account layer to secure, monitor, or audit.
- No privileged service account → A smaller attack surface and less risk of privilege escalation.
- Trusted forensic logging → All actions are recorded in Microsoft’s unified audit logs, which are part of the Microsoft 365 compliance and security perimeter. These logs meet rigorous standards including ISO 27001, SOC 1/2/3, FedRAMP, and support NIS2 and CIS control frameworks.
- High forensic trustworthiness → Native logs are cryptographically protected, integrated into Microsoft’s identity platform, and suitable as evidence in security investigations and regulatory audits – unlike third-party application logs, which lack this certification chain.
- Easier forensics and incident response → Security teams can rely on existing SIEM integrations, Microsoft Purview, and compliance tools without custom connectors or external log stores.
- Full operational fallback → If EasyEntra is unavailable, admins can continue managing identities and mailboxes directly in native Microsoft admin tools, with the same permissions and audit trail.
This approach ensures strong security, verifiable compliance, and minimal additional overhead – while avoiding the trust and operational risks of third-party logging systems.
10. Summary & Key Takeaways
- EasyEntra builds on Microsoft’s native delegation model, using the same roles, scopes, and security boundaries already in place.
- No custom infrastructure or service accounts means lower risk, less complexity, and no vendor lock-in.
- ADManager relies on a custom, high-privilege layer, increasing attack surface and introducing an additional point of failure.
- One delegation model – multiple tools: configuration works seamlessly in EasyEntra and all native Microsoft admin interfaces.
- Operational resilience: if EasyEntra is ever unavailable, admins can continue their work directly in Microsoft’s portals without interruption.
- Trusted logging and compliance: activity is captured in Microsoft’s certified audit systems, ensuring strong forensic integrity and regulatory support.
- The result is a simpler, safer, fully auditable delegation model that aligns directly with Microsoft best practices.
