Skip to main content
Skip table of contents

How to Configure Azure AD for Integration

This guide describes how to prepare Microsoft Azure Active Directory (AD) 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 Azure AD application registration

  1. Log in to the Azure portal with an administrator account.

  2. Navigate to Azure Active Directory.

  3. Select App registrations from the left-hand menu, and then click + New registration.

  4. 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.

  5. Click Register to create the application.

  6. 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 Azure AD.

Part 2: Assign API permissions

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

  1. In your new application registration, navigate to API permissions in the left-hand menu.

  2. Click + Add a permission.

  3. Select Microsoft Graph.

  4. Choose Application permissions.

  5. 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

  6. 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.

    • UserAuthenticationMethod.ReadWrite.All: Required if eAdm will manage user MFA methods.

    • Team.Create: Required if eAdm will create new Teams.

    • Team.ReadBasic.All: Required if eAdm will read basic Team information.

    • Teamwork.Migrate.All: Required for certain migration scenarios.

    • TeamTemplates.ReadAll: Required if eAdm will use Team templates.

  7. After adding the permissions, click Add permissions.

  8. 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.

  1. Navigate to Certificates & secrets in the left-hand menu.

  2. Click + New client secret.

  3. Enter a description for the secret and set the expiration period to 24 months.

  4. Click Add.

  5. 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.

  1. In the Azure portal, navigate to Azure Active Directory.

  2. Select Roles and administrators.

  3. Find and select the User Administrator role.

  4. Click Add assignments.

  5. Search for and select the application you created earlier (e.g., Identum eFeide-eAdm User and Group Management).

  6. On the next screen, set the Assignment type to Active and provide a justification, such as "Required for eFeide to manage user passwords."

  7. 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.

  1. In your application registration, go to API permissions and click + Add a permission.

  2. Switch to the APIs my organization uses tab.

  3. Search for "Office" and select Office 365 Exchange Online.

  4. Select Application permissions.

  5. Choose the Exchange.ManageAsApp permission and click Add permissions.

  6. Grant admin consent for the new permission.

  7. Assign the application the Exchange Recipient Administrator role via the Roles and administrators panel in Azure AD. 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 Azure AD and use it to register the service principal within Exchange Online. This only needs to be done once per application.

CODE
PowerShell
CODE
# 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 Azure AD
$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.

CODE
PowerShell
CODE
# 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 Azure AD environment. This is typically used for advanced integrations and will be coordinated directly with you.

  1. A self-signed certificate will be generated. You will be instructed on how this is done.

  2. In the application registration, navigate to Certificates & secrets.

  3. Select the Certificates tab and click Upload certificate.

  4. 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.

Action

Permission

Description

Minimum Requirement?

Get Anchor, Get User

User.Read.All

Allows the app to read the full profile properties of all users in the organization.

Yes

Create, Update, Delete User

User.ReadWrite.All

Allows the app to read and write the full profile of all users.

Note: Updating sensitive data (e.g., phone numbers, email) or resetting passwords requires the app to also be assigned a high-privilege administrative role, such as "User Administrator".

Yes

Reactivate User

User.EnableDisableAccount.All

Allows the app to enable and disable user accounts.

Yes

Get Groups

Group.Read.All

Allows the app to list groups and read their properties and memberships.

Yes

Create, Update, Delete Group

Group.ReadWrite.All

Allows the app to create, read, and write all group properties and memberships. Requires User.Read.All to add users as owners or members.

Yes

Update Group Members

GroupMember.ReadWrite.All

Allows the app to read and update group memberships.

No

Get Last Sign-in Activity

AuditLog.Read.All

Allows reading the AzureLastLogOnTimeStamp back to eADM. If this doesn't work, Directory.Read.All can be an alternative.

no

Directory Access

Directory.ReadWrite.All

Allows the app to read and write data in the directory (users, groups). Does not allow deleting users/groups or resetting passwords.

No

Create Teams

Team.Create

Allows the app to create teams.

No

Get Teams

Team.ReadBasic.All

Allows the app to read the names and descriptions of teams.

No

Migrate Teamwork Data

Teamwork.Migrate.All

Allows the app to create chat and channel messages without a signed-in user.

No

Read Team Templates

TeamTemplates.Read.All

Allows the app to read all available Teams Templates.

No

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.