Customers need to set up a webhook based on their Active Directory (AD) environment on premise to perform actions from Atomicwork. This guide explains the process, required permissions, and endpoint configuration.
Understanding the Webhook Requirement
The webhook must be provided by the customer as per their AD setup.
The endpoint and API will vary for each customer.
The webhook requires access control, meaning specific permissions need to be granted to Atomicwork.
Steps to Configure the Webhook
Step 1: Identify the Webhook Endpoint
Customers should determine the appropriate endpoint within their AD environment. This typically follows Microsoft’s documented process for setting up webhooks with external services.
Step 2: Grant Necessary API Permissions
To enable Atomicwork to interact with AD for provisioning or synchronization tasks, customers must:
Grant access to the Inbound Provisioning API in Microsoft Entra ID.
Configure API permissions to allow external services (like Atomicwork) to provision users and sync data securely.
Follow Microsoft's access control guidelines.
Step 3: Configure the Webhook and Synchronization Settings
Depending on the customer's AD setup, they may need to:
Set up a bulk user data upload process for synchronization jobs (Graph API bulk upload).
Define attribute mappings and configure the provisioning API settings in their app (Inbound provisioning API configuration).
Step 4: Provide Endpoint Details to Atomicwork
Once the webhook is set up and permissions are granted, customers must share:
The webhook URL
Any authentication credentials or tokens required
The expected request format (if customized)
Step 5: Test and Validate
Atomicwork will send test requests to confirm that the integration is working correctly. Any required adjustments can be made at this stage.
Additional Resources
OnPrem AD Permissions for Atomicwork
Permission | Description | Workflows / Actions | Permission Type |
| Read and update signed-in user's profile | Allows users to manage their own account data (e.g., profile updates). Useful for self-service portals. | Delegated |
| Read all user profiles in the directory | Required for reporting, auditing, or apps that list users. Needed for read-only access across org users. | Application |
| Read and write user lifecycle info (e.g., hire date) | Enables automation of onboarding/offboarding processes; required for HR integrations. | Application |
| Read and write access to all users' mailboxes | Used for migration tools, compliance archiving, or automated email access by apps or services. | Application |
| Reset passwords and manage user password settings | Required for password reset workflows, helpdesk tools, or automation of account recovery processes. | Application |
| Read and update users' phone numbers | Enables management of MFA contact info, user phone sync from HR systems, or mobile-based workflows. | Application |
| Enable or disable user accounts | Critical for access control automation – e.g., disabling leavers or suspending compromised accounts. | Application |
| Manage user identities and federated/external identities | Used in B2B/B2C apps, federated identity systems, or hybrid AD setups. Enables complex identity tasks. | Application |
Additional permissions for removing users from Azure AD
Your personal Microsoft account must be tied to a Microsoft Entra tenant to update your profile with the User.ReadWrite delegated permission on a personal Microsoft account.
To update the employeeLeaveDateTime property:
In delegated scenarios, the admin needs the Global Administrator role; the app must be granted the User.Read.All and User-LifeCycleInfo.ReadWrite.All delegated permissions.
In app-only scenarios with Microsoft Graph permissions, the app must be granted the User.Read.All and User-LifeCycleInfo.ReadWrite.All permissions.
To update the customSecurityAttributes property:
In delegated scenarios, the admin must be assigned the Attribute Assignment Administrator role and the app granted the CustomSecAttributeAssignment.ReadWrite.All permission.
In app-only scenarios with Microsoft Graph permissions, the app must be granted the CustomSecAttributeAssignment.ReadWrite.All permission.
User-Mail.ReadWrite.All is the least privileged permission to update the otherMails property.
User-PasswordProfile.ReadWrite.All is the least privileged permission to update the passwordProfile property.
User-Phone.ReadWrite.All is the least privileged permission to update the businessPhones and mobilePhone properties.
User.EnableDisableAccount.All + User.Read.All is the least privileged combination of permissions to update the accountEnabled property.
User.ManagedIdentities.All is required to update the identities property.
As part of our SCIM-based provisioning integration, attribute mapping in the Microsoft Entra setup may prevent users from being provisioned into the correct Organizational Unit (OU) in on-premises Active Directory.
Request:
To enable OU-specific provisioning from our SCIM payload, please update the attribute mapping for parentDistinguishedName as follows?
On-Prem AD Attribute: parentDistinguishedName
API Attribute: urn:microsoft:onprem.distinguishedName
This change will ensure Microsoft Entra correctly reads the OU we pass in the SCIM payload and places the user accordingly.