- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Hello Everyone,
I am trying to use the “Add User to Group” orchestration action. When I run this action, I encounter the following errors:
IPaaSActionProbe | Access denied. Script returned status 3 using the local MID Server service account.
Timestamp: 2026-01-07 13:08:53Error: Failed while executing ActionAddUserToADGroup.ps1 (Access denied).
Timestamp: 2026-01-07 13:08:53Error: Access denied. Script returned status 3 using the local MID Server service account.
Please help !
Please find the screenhot for refernce :
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Hi there,
The error message gives away the root cause: "Access denied... using account local MID server service credential."
This indicates that Orchestration failed to find or use a specific Windows Credential from the ServiceNow discovery_credentials table. Consequently, it fell back to trying to execute the PowerShell script using the MID Server's own Windows Service account. This local service account usually does not have permissions to modify Active Directory groups, hence the "Access Denied" (Status 3) error.
Here is how to fix it:
1. Create/Verify the Windows Credential
Navigate to Orchestration > Credentials (or discovery_credentials.list).
Ensure you have a Windows Credential record created.
Username: Must be in the format DOMAIN\User or User@domain.com.
Permissions: This user must have rights to add members to groups in Active Directory (e.g., a Domain Admin or a Delegated Admin).
2. Test the Credential
Open the credential record.
Click the "Test Credential" related link.
Enter the IP address or Hostname of the Domain Controller (the target host where this action is running).
If the test fails here, the Orchestration activity will definitely fail.
3. Check Target Host Matching
Orchestration selects the credential based on the target IP/Hostname. Ensure the "Target Host" input in your workflow/flow matches the IP/Domain Controller where this credential is valid.
Once ServiceNow finds a valid credential for that target, the log will stop saying "using local MID server service credential" and will instead use the impersonated admin user you configured.
Hope this solves the access issue!
If this response helps you achieve your requirement, please mark it as Accepted Solution.
This helps the community grow and assists others in finding valid answers faster.
Best regards,
Brandão.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Hi there,
The error message gives away the root cause: "Access denied... using account local MID server service credential."
This indicates that Orchestration failed to find or use a specific Windows Credential from the ServiceNow discovery_credentials table. Consequently, it fell back to trying to execute the PowerShell script using the MID Server's own Windows Service account. This local service account usually does not have permissions to modify Active Directory groups, hence the "Access Denied" (Status 3) error.
Here is how to fix it:
1. Create/Verify the Windows Credential
Navigate to Orchestration > Credentials (or discovery_credentials.list).
Ensure you have a Windows Credential record created.
Username: Must be in the format DOMAIN\User or User@domain.com.
Permissions: This user must have rights to add members to groups in Active Directory (e.g., a Domain Admin or a Delegated Admin).
2. Test the Credential
Open the credential record.
Click the "Test Credential" related link.
Enter the IP address or Hostname of the Domain Controller (the target host where this action is running).
If the test fails here, the Orchestration activity will definitely fail.
3. Check Target Host Matching
Orchestration selects the credential based on the target IP/Hostname. Ensure the "Target Host" input in your workflow/flow matches the IP/Domain Controller where this credential is valid.
Once ServiceNow finds a valid credential for that target, the log will stop saying "using local MID server service credential" and will instead use the impersonated admin user you configured.
Hope this solves the access issue!
If this response helps you achieve your requirement, please mark it as Accepted Solution.
This helps the community grow and assists others in finding valid answers faster.
Best regards,
Brandão.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
You are Rockstar . Thanks Buddy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Hi,
This error usually happens because the MID Server service account does not have enough permissions in Active Directory.
The Add User to Group action runs using the MID Server account, not the logged-in user. If that account doesn’t have permission to modify AD group membership, the script fails with Access denied (status 3).
Please check:
MID Server is running with a domain service account (not Local System)
The service account has permission to add users to the target AD group
Try running the same PowerShell script manually using the MID Server account
Once the correct AD permissions are given, the action should work.
Thanks!
