Servicenow Integration with ADManager Plus

[Community Alums]

We want to integrate ServiceNow with ADManager Plus so that ServiceNow can trigger on‑prem Active Directory actions (like adding users to security groups for Power BI access). We need clarity on what exact integration setup is required between the two systems—specifically how to securely connect ServiceNow to ADManager Plus using a MID Server, how the authentication/token exchange works, and what is needed to enable automated operations using ServiceNow REST APIs and ADManager Plus inbound webhooks. Essentially, we want to confirm the correct integration architecture and requirements for enabling fully automated AD actions from ServiceNow via ADManager Plus. Where tool itself can perform actions like create a user, disable a user.

[himanjaiswal]

The correct pattern is:

ServiceNow → MID Server → ADManager Plus → On-prem Active Directory

That means ServiceNow should act as the request/orchestration layer, the MID Server should provide the secure bridge to the on-prem network, and ADManager Plus should be the execution layer that actually performs AD operations such as:

• create user
• disable user
• unlock user
• reset password
• add/remove user from security groups (for example, Power BI access groups)

For this integration, ServiceNow should not directly perform the AD action itself. Instead, ServiceNow should trigger ADManager Plus, and ADManager Plus should execute the AD change using its delegated permissions in Active Directory.

Recommended architecture

The standard setup is:

1. A request, catalog item, Flow Designer flow, or business rule in ServiceNow triggers an outbound REST call.
2. That REST call is routed through a MID Server, since ADManager Plus is hosted on-prem/private network.
3. The MID Server securely connects to ADManager Plus over HTTPS.
4. ADManager Plus receives the request and performs the required AD task.
5. The result is returned back to ServiceNow for status tracking, auditing, or fulfillment updates.

Why the MID Server is needed

The MID Server is required when ServiceNow must communicate with a system that is not publicly exposed. In this case, ADManager Plus sits inside the internal network, so the MID Server acts as the secure broker between ServiceNow and ADManager Plus.

Authentication model

This is typically not an OAuth-style token exchange between ServiceNow and ADManager Plus.

Instead:

• ServiceNow authenticates to ADManager Plus using an ADManager Plus API auth token (or the authentication method supported by the ADManager Plus endpoint you expose).
• The MID Server simply transports the request; it does not replace the application-level authentication.
• ADManager Plus then uses its own service/delegated rights in AD to perform the requested operation.

So the important distinction is:

• ServiceNow is authorized to call ADManager Plus
• ADManager Plus is authorized to act in Active Directory

What must be configured

To enable fully automated operations, you typically need all of the following:

In ServiceNow

• A working MID Server
• Network path from MID Server to ADManager Plus
• An outbound REST Message or integration action
• Credential storage for the ADManager Plus auth token
• Flow logic to send the required payload for each action
• Error handling and response parsing

In ADManager Plus

• A reachable API / inbound webhook endpoint
• A dedicated integration token/account
• Delegated permissions to perform the required AD actions
• Any templates, workflows, or policy mappings needed for actions like create user or disable user
• Logging/auditing enabled for traceability

How inbound webhooks fit

If you want ServiceNow to trigger AD actions, the main requirement is that ServiceNow can call an ADManager Plus endpoint through the MID Server.

“Inbound webhooks” on the ADManager Plus side are useful if ADManager Plus is set up to receive action requests from ServiceNow. In practical terms, that just means ADManager Plus must expose an endpoint that ServiceNow can call with the right payload and authentication.

So yes, inbound webhooks can be part of the design, but the key point is that they are just the entry point into ADManager Plus. ADManager Plus still needs the internal configuration and AD rights to execute the action.

For Power BI access

If the requirement is “give user Power BI access,” the AD-side action should usually be modeled as:

• add user to a specific security group

That is cleaner than trying to treat Power BI access as a separate identity action.

Bottom line

If the goal is fully automated on-prem AD actions from ServiceNow, the correct setup is:

• ServiceNow initiates the request
• MID Server securely carries it into the internal network
• ADManager Plus receives the request through API/webhook
• ADManager Plus performs the AD action using its delegated permissions

If those components are in place, then actions like create user, disable user, and add users to security groups can be automated end to end.

My recommendation is to validate the design using one simple use case first — for example, add user to Power BI AD security group — and then extend the same pattern to create/disable user operations.