Orchestration - Add user to AD Group getting Authentication Errors

[garyopela]

Hey guys, I've set up orchestration to add a user to a group in AD but am getting weird errors.

I have verified the following:

1) I am using the correct DC

2) The group and the account both exist which I'm using

3) The service-account under which my mid server service is running has sufficient rights to add the user I'm testing with to the group I'm testing with.   (I used ADUC and was able to manually add the account to the group

Yet, even trying two different ways, I still get the same error.

The first way I tried was using a Run - Powershell activity:

Add-ADGroupMember -Identity "group SAM Name" -Members "user SAM Name"

The second way was using what Chris posted:

ServiceNOW RBA (Orchestration) — Add an Active Directory user to an AD group — workflow activity. | ...

Unfortunately, the error I'm getting is:

Authentication failure with the local MID server service credential.

Failed to access target system.   Please check credentials and firewall settings on the target system to ensure accessibility: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

Any suggestions are appreciated. I'm not sure why I'm getting access denied. The account has the proper authority, I even logged in as that account and was able to update AD. I can still query AD, just not Update. For instance, If I put in a check to see if an account is locked or not, that works.

[Christopher_Mal]

Hey Gary,

I agree with both Eric and Kreg - great advice there.

Try using this in a Powershell activity:

(DLMem is the fulling qualified name 'CN=cmaloy, OU=ServiceNow, DC=ServiceNow, DC=org'

GrpDL = samAccount name of group)

Import-Module ActiveDirectory

$GrpDL = ${workflow.scratchpad.groupDL}

$DLMem = ${workflow.scratchpad.userDL}

Get-AdGroup -identity $GrpDL | Add-ADGroupMember -Members $DLMem   -Confirm:$false

Setting up MID server to use the Active Directory CMDLETS:

Running Active Directory CMDLETS in your workflow with Powershell

I find it easiest to make sure the service account the MID server runs with has access to run the above command locally.

[garyopela]

So I tried adding the Import-Module ActiveDirectory and got the following error:

Import-Module : The specified module 'ActiveDirectory' was not loaded because no valid module file was found in any module directory

My question, is is this an error generated by my AD or is this an error generated by Service-Now?

[garyopela]

Oh it looks like maybe I need to turn on some windows features on my mid-server.

http://stackoverflow.com/questions/19182497/import-module-the-specified-module-activedirectory-was-n...

[garyopela · Accepted solution]

Holy cow that worked.

Okay, i'll try to update my blog on how to get all this to work when I get time. Thanks for all the help guys, it is much easier now that we have powershell version2!!!

[JimCheffer]

Hello Gary,

I am struggling with the same issue and error. I have created a "Test" workflow where I hard code the user, group and AD server information then execute the workflow with PowerShell activity using my admin account.

HostName = ${workflow.scratchpad.domain} This is the IP address of active directory

Import-Module ActiveDirectory

$GrpDL = '${workflow.scratchpad.groupname}'

$DLMem = '${workflow.scratchpad.username}'

Get-AdGroup -identity $GrpDL | Add-ADGroupMember -Members $DLMem   -Confirm:$false -credential $cred

This process works and verified that user is added to AD group. Also able to remove as well.

Then I created another workflow with catalog request that allows user to request being added to a group. The workflow is failing with authentication error that you and others have been discussing.   The setup for the Powershell activity is the same I think.

HostName = ${workflow.scratchpad.domain}

Import-Module ActiveDirectory

$GrpDL = '${workflow.scratchpad.groupname}'

$DLMem = '${workflow.scratchpad.username}'

Get-AdGroup -identity $GrpDL | Add-ADGroupMember -Members $DLMem   -Confirm:$false -credential $cred

The only difference I see is that I execute the test workflow versus a catalog request running the workflow. I am running both from our development environment to our production AD using test users

Jim