How to Configure Entra ID for Integration

This guide describes how to prepare Microsoft Entra ID for integration with eAdm or eFeide. The process involves creating an application registration and then assigning the necessary permissions.

You can safely ignore the section on advanced configuration unless specifically instructed by Identum.

Part 1: Create an Entra ID application registration

Log in to the Azure portal with an administrator account.
Navigate to Entra ID.
Select App registrations from the left-hand menu, and then click + New registration.
On the "Register an application" page, configure the following settings:
- Name: Enter a descriptive name for the application. For example: Identum eFeide-eAdm User and Group Management.
- Supported account types: Select Accounts in this organizational directory only (Single tenant).
- Redirect URI: Leave this field blank.
Click Register to create the application.
After the application is created, copy the Application (client) ID and Directory (tenant) ID from the application's "Overview" page. Save these values for later use.

Warning: Do not use a forward slash (/) in the application name, as this can cause issues in Entra ID.

Part 2: Assign API permissions

Next, you must grant the application the required API permissions to manage users and groups.

In your new application registration, navigate to API permissions in the left-hand menu.
Click + Add a permission.
Select Microsoft Graph.
Choose Application permissions.
Add the following permissions:
- Directory.Read.All
- Directory.ReadWrite.All
- Group.Create
- Group.Read.All
- Group.ReadWrite.All
- GroupMember.ReadWrite.All
- User.Read.All
- User.ReadWrite.All
- User.EnableDisableAccount.All
Also, add the following permissions if they are relevant to your specific needs:
- AuditLog.Read.All: Required if you want to sync the lastLogonTimeStamp attribute to eAdm, or sync MFA registration status.
- UserAuthenticationMethod.ReadWrite.All: Required if eAdm will manage user MFA methods.
- Reports.Read.All: Required if eAdm will sync mailbox size to eAdm.
- LicenseAssignment.Read.All: Required if eAdm will sync assigned license names/IDs to eAdm.
After adding the permissions, click Add permissions.
On the API permissions screen, click Grant admin consent for [Your Tenant Name] and confirm when prompted.

Note: The permissions listed in bold are mandatory for basic integration. The others are required for specific, common scenarios.

Part 3: Create a client secret

A client secret is a password that the application uses to authenticate itself.

Navigate to Certificates & secrets in the left-hand menu.
Click + New client secret.
Enter a description for the secret and set the expiration period to 24 months.
Click Add.
Immediately copy the value of the new client secret from the Value field.

Warning: The client secret value is only displayed in full immediately after creation. If you do not copy it now, you will have to create a new one. Store this value securely.

Note: If Privileged Identity Management (PIM) is active in your environment, you may not be able to set a fixed expiration date.

Part 4: Assign an administrator role

To perform sensitive actions like changing passwords or updating user phone numbers, the application needs an administrative role.

In the Azure portal, navigate to Entra ID.
Select Roles and administrators.
Find and select the User Administrator role.
Click Add assignments.
Search for and select the application you created earlier (e.g., Identum eFeide-eAdm User and Group Management).
On the next screen, set the Assignment type to Active and provide a justification, such as "Required for eFeide to manage user passwords."
Click Assign to complete the role assignment.

Note: If you use role-assignable groups for any users managed by eFeide or eAdm, the application requires the Privileged Authentication Administrator role instead. Please see: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/privileged-roles-permissions?tabs=admin-center#who-can-perform-sensitive-actions

Part 5: Send information to Identum

Once the configuration is complete, you must send the following information to Identum to finalize the setup:

Tenant Name (e.g., yourcompany.onmicrosoft.com)
Directory (tenant) ID
Application (client) ID
Client Secret

Warning: For security, send the Client Secret separately from the other information (e.g., via SMS or another secure channel).

Advanced configuration

Warning: Do not perform the following steps unless you have been explicitly instructed to do so by Identum or you are an expert user.

Assign permissions in Exchange Online

These permissions are only required if eAdm or eFeide will manage Exchange Online features directly, such as distribution groups or mail-enabled security groups.

In your application registration, go to API permissions and click + Add a permission.
Switch to the APIs my organization uses tab.
Search for "Office" and select Office 365 Exchange Online.
Select Application permissions.
Choose the Exchange.ManageAsApp permission and click Add permissions.
Grant admin consent for the new permission.
Assign the application the Exchange Recipient Administrator role via the Roles and administrators panel in Entra ID. This will allow it to manage Exchange objects.

Mail-enabled security groups:

Handling mail-enabled security groups requires an additional role ("Security Group Creation and Membership" in Exchange Online. This can be a bit finicky to set up.. But below, we describe how to add the single role (You can use custom Role Groups if you prefer). Refer to https://learn.microsoft.com/en-us/exchange/permissions-exo/application-rbac for background and further instructions:

1. Create the Service Principal in Exchange Online

First, find your application's Object ID from Entra ID and use it to register the service principal within Exchange Online. This only needs to be done once per application.

PowerShell

# Make sure you are connected to both services
# Connect-MgGraph -Scopes "Application.Read.All"
# Connect-ExchangeOnline

# --- Enter your Application (Client) ID here ---
$appId = "00000000-0000-0000-0000-000000000000"

# Find the application's details in Entra ID
$sp = Get-MgServicePrincipal -Filter "appId eq '$appId'"

# Create the service principal object within Exchange Online
# The -ErrorAction flag prevents an error if it already exists
New-ServicePrincipal -AppId $sp.AppId -ObjectId $sp.Id -DisplayName $sp.DisplayName -ErrorAction SilentlyContinue

2. Assign the Single Role to the Application

Now, use the New-ManagementRoleAssignment cmdlet with the -App parameter to assign the role directly to the service principal you just created.

PowerShell

# Assign the role directly to the application
# Provide a unique name for the role assignment
New-ManagementRoleAssignment -App $appId -Role "Security Group Creation and Membership" -Name "App_SG_Creation_Membership_Direct_Assignment"

Your application now has the specific Exchange Online permissions to manage mail-enabled security groups.

Certificate-based authentication

This step is only necessary if Identum needs to run custom scripts against your Exchange Online or Entra ID environment. This is typically used for advanced integrations and will be coordinated directly with you.

A self-signed certificate will be generated. You will be instructed on how this is done.
In the application registration, navigate to Certificates & secrets.
Select the Certificates tab and click Upload certificate.
Upload the public key file (.cer, .pem, or .crt) provided to you.

Appendix: Review of Required Permissions

The following table details the Microsoft Graph API permissions and the reason they are required.

Permission	What it's used for	When it's required
`User.Read.All`	Read user profiles, used to match Entra IDaccounts against eADM records and detect existing accounts.	Always. Every Entra ID sync run needs this, even a users-only setup.
`User.ReadWrite.All`	Create, update, and delete user accounts.	Always, unless the sync step is read-only (import only, no provisioning).
`Group.Read.All`	Read groups and group properties.	Always required, in every scenario — including a users-only import with no group provisioning. The sync engine reads the full group list on every run as a technical dependency, unrelated to whether groups are actually imported or exported.
`Group.ReadWrite.All`	Create, update, and delete groups; also used to enable Microsoft Teams on a group.	Required if group provisioning or Teams-on-group is enabled. Not required for a users-only setup — but `Group.Read.All` above is required regardless.
`GroupMember.ReadWrite.All`	Add/remove group members without full group write access.	Optional alternative to `Group.ReadWrite.All` if eADM should only manage membership, not group properties or ownership.
`User.EnableDisableAccount.All`	Enable/disable a user account (e.g. on leave/return, or termination).	Required only if account reactivation/deactivation is part of the customer's lifecycle flow. Not needed for plain create/update.
`Directory.ReadWrite.All`	Broader read/write on users and groups; also covers restoring a previously deleted user.	Optional. Only needed if restoring soft-deleted accounts is in scope, and only as an alternative to `User.ReadWrite.All` for that specific action.
`AuditLog.Read.All`	Read sign-in activity (last logon) and MFA registration status.	Required only if last-logon sync or MFA-status sync is configured.
`UserAuthenticationMethod.ReadWrite.All`	Manage a user's authentication methods (e.g. register a phone number for MFA, issue a Temporary Access Pass).	Required only if eADM manages MFA methods or issues Temporary Access Passes. Grants broad control over a user's sign-in security — review carefully before granting.
`Reports.Read.All`	Read mailbox size/usage reports.	Required only if mailbox-size sync is configured.
`LicenseAssignment.Read.All` (or `Directory.Read.All` / `Directory.ReadWrite.All`)	Read assigned license/SKU information.	Required only if license-name or license-ID sync is configured.
`Exchange.ManageAsApp` (Exchange Online, not Graph)	Manage distribution lists and mail-enabled security groups.	Required only if eADM manages Exchange-side mail groups. Needs a separate Exchange Online role assignment — see Advanced configuration.

Microsoft Teams provisioning happens through a property on a group (Teams is enabled on a group eADM already creates), not as a standalone Team resource. Group.ReadWrite.All alone covers it — no separate Teams permission (Team.Create, Team.ReadBasic.All, TeamTemplates.ReadAll) is needed.

Recommended permission bundles by use case

Use case	Permissions to grant
Import existing users only (no create/update/delete)	`User.Read.All` and `Group.Read.All`. `Group.Read.All` is required even in this read-only case — the sync engine reads the group list on every run regardless of scope.
Provision users, no groups, no reactivation	`User.Read.All`, `User.ReadWrite.All`, `Group.Read.All` (always required, even without group sync)
Full user lifecycle (create, update, disable/reactivate)	Add `User.EnableDisableAccount.All`
+ Group provisioning (incl. Teams-on-group)	Add `Group.ReadWrite.All` (or `GroupMember.ReadWrite.All` for membership-only)
+ Last-logon or MFA-status reporting	Add `AuditLog.Read.All`
+ MFA method management	Add `UserAuthenticationMethod.ReadWrite.All` (sensitive — review with security team)
+ Mailbox size reporting	Add `Reports.Read.All`
+ License reporting	Add `LicenseAssignment.Read.All`
+ Mail-enabled security groups / distribution lists	Add `Exchange.ManageAsApp` + Exchange Online role (see Advanced configuration)

Group.Read.All is always required, in every use case above — including the read-only import case — because the sync engine reads the full group list on every run as a technical dependency, independent of whether group provisioning or import is in scope. A strictly users-only integration with zero group access isn't possible today.

Last updated: October 22, 2026