FAISAL RAHMAN'S BLOG

Sharing my experience to advance your IT career!

Entra ID SCIM provisioning with ECMA2 agent using PowerShell Connector and REST API to external system

Introduction

Most modern applications meet the SCIM standard for REST API integrations but there are situations with legacy applications where SCIM is not available but has REST API for user provisioning. You can leverage Extensible Connectivity Management Agent (ECMA2) deploying on the Windows Server and creating PowerShell connector for SCIM integration with Cloud IAM and External application.

Architecture Diagram

Prerequisites

Download and Setup On-Premise ECMA2 Agent

  • Sign in to the Microsoft Entra admin center as at least an Application Administrator.
  • Browse to Identity > Applications > Enterprise applications.
  • Select New application.
  • Search for the On-premises ECMA app application, give the app a name (example: “ECMA PowerShell MA”), and select Create to add it to your tenant.
  • Navigate to the Provisioning page of your application.
  • Select Get started.
  • On the Provisioning page, change the mode to Automatic. Click on On-Premise Connectivity and select Download and install link, then you can download the Microsoft Entra Provisioning Agent.

  • Install the Agent on the ECMA2Host Server (Windows Server 2016 or a later version.)




    Sign-in to Azure at least with Hybrid Identity Administrator role and Authenticate then Confirm.

  • After installation is successfully completed. Open the Microsoft ECMA2Host Configuration Wizard application. Then generate and create or import an existing SSL Certificate.

Setup PowerShell Connector

  • Download the PowerShell Connector Configuration Files.
  • In the example the Target Application, the anchor attribute is AzureObjectID, the unique identifier for the user and the other attributes as the flow attributes. The Schema.xml file will look like this:
  • The sample JSON.
  • Create folder “C:\Logs” on the ECMA Server
  • Edit the following files per your requirements
  • Copy the following files from your Scripts folder to locations below:
FileLocation
InputFile.txtC:\Program Files\Microsoft ECMA2Host\Service\ECMA\MAData
Schema.xmlC:\Program Files\Microsoft ECMA2Host\Service\ECMA

Configure Entra ID ECMA app

  • Open the “Microsoft ECMA2Host Configuration Wizard” application from the ECMA Server
  • Click “+ New Connector” then configure.

    ⦿ Secret Token is a 15 character password that will be needed later in the configuration.

    ⦿ User and Password is for the REST API endpoint

    ⦿ Copy “CommonModule.psm1” script to the “Common Module Script”
    ⦿ Copy “Schema Script.ps1” script to the “Schema Script”


    ⦿ Copy “Import Script.ps1” script to “Import Script”
    ⦿ Copy “Export Script.ps1” script to “Export Script”








Open the “ECMA PowerShell MA” Enterprise Application from Azure Portal

  • Navigate to “Provisioning -> Manage -> Provisioning” then select “Automatic”
  • Select the ECMA2Host Node from the list and enter the required information. Then click “Test Connection” and “Save”. (Secret Token is the previously defined in the “Microsoft ECMA2Host Configuration”).
  • Click “Edit provisioning” for mapping attributes.
  • Click “Provision Microsoft Entra ID users” link.
  • Validate the SCIM attributes by clicking “Show advanced options” and then clicking “Edit attributes list for ScimOnPremises” link.
  • Review all the attributes that was configured in PowerShell Connector are listed.
  • Configure new mappings by clicking “Add New Mapping”
  • Follow example below and then repeat for all. Note there are Direct and Constant for demonstrating the example.

Validate Connector

  • Add test users by clicking “Users and groups” link
  • Click “Provision On Demand” then validate by selecting the user and click “Provision”
  • Check the REST API https://samplerest.faisalrahman.com/Person that the user was provisioned. (Note: the JSON DB is refreshed nightly)

Resources

When Azure AD Dynamic Group is not so Dynamic

Special thanks to Annette Augustus for her contribution to this article.

Dynamic but not so dynamic. Azure AD has a powerful Dynamic Group feature that allows defining criteria with the User attributes to dynamically populate or un-populate a Security Group.

There are circumstances when the User attribute you want to filter by is not available in the list.

If you are in that situation Microsoft Graph API can be utilized to query the User object with the required filter and then with Power Automate to create a flow to populate the Security group with users who satisfy the criteria. The flow can be scheduled to run on a recurring basis and the interval between two consecutive runs can be configured as required.

Let’s solve this scenario.
GOAL:
• Configure Self-service password reset (SSPR)
• Criteria users must be Multi-factor (MFA) registered with a phone
Approach:
• Create a security group that will automatically populate/un-populate based on the criteria
• Assign the Security group for SSPR

Option 1: Using Power Automate Flow

Microsoft Graph API can be utilized to collect the list of users registered for MFA with Phone Number Authentication. Graph API can be utilized in Power Automate to create a flow to populate the users who satisfy the criteria for SSPR into an Azure AD group. The flow can be scheduled to run on a recurring basis and the interval between two consecutive runs can be configured as required.

NOTE: This approach has a limit of 100,000 on the number of users that can be processed in a single flow run. This limitation of 100,000 on the action requests in the flow cannot be lifted because it exists to protect the service. Detailed information here: Looping, concurrency, and debatching limits

Hence, option 1 is viable for use in an environment with less than 100,000 users.

Steps for Configuration:

  1. Go to Azure Active Directory -> App registrations and click the + New registration button.

Assign a name to the Application, and fill the URL with the value https://auth

  1. Register the application:
  2. Once the application is created, go to the API Permissions tab.
  3. Add the following permissions for the Microsoft Graph:
Permission typePermissions
DelegatedReports.Read.All, AuditLog.Read.All, Group.Read.All, GroupMember.Read.All, User.Read.All, Directory.Read.All Directory.AccessAsUser.All UserAuthenticationMethod.Read UserAuthenticationMethod.Read.All
ApplicationReports.Read.All, AuditLog.Read.All, Group.Read.All, GroupMember.Read.All, UserAuthenticationMethod.Read.All
  1. Grant Admin Consent once the permissions are added:
  2. Go to the Certificates & secrets tab, and create a new client secret. Copy the secret value and save it on a notepad for use later. Also, take note of the Tenant & Client ID on the Overview page.
  3. To pull the data out of the Graph API, an Azure AD Group is required to assign the users. Created an Assigned Security group in Azure AD and leave it as is. For later use, take note of the Object ID of the group.
  4. Import the below flow into Power Automate: https://flow.microsoft.com.
    Download Code Sample
  5. To import a flow, first click on the import button in the top right-hand corner of the screen.
  6. Next, upload the package file and wait for the screen to show up the package details
  7. When configuring the flow settings, choose to create a new flow
  8. Select the appropriate connections required to set up the flow as part of the import process.
  9. Click on the “Select during import” option as you see below.
  10. Click on “Create new”
  11. Click on “New Connection” on the left top corner of the page that loads:
  12. Search for Azure AD, and click on the connection named “Azure AD” from the search results:
  13. Login with “Global Administrator” credentials.
  14. Also, add “Office 365 Users connection”
  15. Now, go back to the Flow import page, and choose the right connections, save and submit:
  16. The Import button will light up once all the required settings have been successfully configured. Once imported successfully, Edit the flow and modify all the HTTP activities inside the flow and update the appropriate values:
    Tenant: <provide your Tenant ID>
    Client ID: <Client ID of the application created in Step 2 above. Client ID can be found in the app overview page>
    Secret: <Noted in Step 6 above>
    There are 4 HTTP activities to be updated, namely: HTTP: Get List of Users, HTTP 2, HTTP 3, HTTP 4



  1. Once updated, update the recurrence pattern for the flow in the first activity named “Recurrence”:
  2. Save the flow, test, and resolve any errors.
  3. Once the flow is created, run the flow manually to check if the Azure AD group is populated with the right membership.

    Configuring Password Reset for the Azure AD Group:
  4. For enablement of Password Reset, the members have to be part of a single group. Since we have multiple groups, based on the “Country” attribute, all these groups need to be added to a main group, which will be configures for SSPR. Eg: The Azure AD Group for each region should be member of an Azure AD Security Group (eg. “TestSSPR Group” below) which will be mapped for Password Reset.
  5. Once the group membership is mapped, go to Azure Active Directory>Password Reset. Map the group created above for Password Reset or add the group as member of the current group mapped for Password reset:

Option 2: Using PowerShell to populate custom user attribute and then utilizing the attribute for creating Azure AD Dynamic Group criteria

In Azure Active Directory (Azure AD), attribute-based rules can be used to enable dynamic membership for a group. Dynamic group membership adds and removes group members automatically using membership rules based on member attributes. Extension attributes and custom extension properties are supported as string properties in dynamic membership rules. 
For list of supported properties in Azure AD Dynamic Groups, refer link

Steps

  1. Create a PowerShell script that checks if
    • User is MFA registered (and) has at least one authentication method registered (and) has a non-null Phone Number (if Phone authentication is registered). If yes, then set the custom extension property value in Azure AD to “True” for the user. If not, then set the custom extension attribute to “False”

Schedule to run this script using Task Scheduler on a recurring basis so that the extension attribute value is refreshed.

  1. Create Dynamic Security Groups in Azure AD for each of the BU as described below:
    BS-GraphAPI-BU1
    BS-GraphAPI-BU2
    BS-GraphAPI-BU3
    BS-GraphAPI-BU4
    BS-GraphAPI-BU5

    Click on “Add dynamic query” and create two criteria inside the group as below, where “extension_<application_id>_customAttribute” (in pic below) should be the custom extension attribute that is being set through the PowerShell script and “country” should contain the Business Unit value for each user:
  1. Group membership will get auto-populated based on the criteria defined and these groups can be added as members to the Azure AD group mapped for Password Reset.

Deploy or not deploy Domain Controller in Azure IaaS?

I would recommend not to deploy on-premises Active Directory Domain Controller (AD DS) in the Cloud. Of course, there are cases where an organization has requirements to fulfil for supporting some legacy applications requiring legacy authentication that are not able to use modern authentication.

If you are in that situation and deploying Domain Controller in the Cloud is a must then do it securely. Use a hardened device such as Privileged Access Workstation (PAW). The PAW configuration includes security controls and policies that restrict local administrative access and productivity tools to minimize the attack surface to only what is absolutely required for performing sensitive job tasks. 

Using the PAW to access Azure Portal or Infrastructure as Code (IaC) to deploy the Virtual Machine (Windows Server) for configuring it as Domain Controller. Assuming you have VPN, Express Route or other mechanism to your on-premises network that you can resolve your Domain Controller.

High-level architecture diagram.

Assumptions you have deployed PAW-CSM, Azure Bastion, configured VNets and NSGs to restrict access to the VM only from Azure Bastion subnet.