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.

[azenith_moreno]

Hi Jim,

Good day! Were you able to make this one work? Almost having the same issues.

Thank you very,

[JimCheffer]

Hello, yes it works some of the time. I just had several today that indicated user was added to the group but it was not. Workflow indicates success but in reality it failed. I am also using the OOB Query AD that fails to connect sometimes. I have built in a WF loop to try 5 times to Query AD which helps but still have connection issue. I am more concerned about success does not mean success. It appears our issue is between Mid Server and AD. I am working with SNC support as well. Jim

[azenith_moreno]

Thanks Jim,

I'm facing the same issue as well , workflows shows as success but the users are not added on AD. Also working with SNC support on this.

Thank you,

Azenith

[JimCheffer]

Hi Azenith, we have stood up a new mid server and issues with timeouts connecting to AD have gone away. This server is dedicated to Orchestration. Have not seen the false success issue but it has only been two days. Plan is to have two midservers one for Orchestration and the other for LDAP and SCCM (Discovery). Our old midserver software was out of date as well which I need to update. If I change Orchestration to use old midserver timeout errors back to new midserver all is well. SNC support helped us. Jim. .

[garyopela]

The way to get it to work is this:

1) First look in your ecc queue to see the agent on the powershell entry. Verify it is the correct mid server. If you are getting it to work sometime, i would assume that you probably have multiple mid servers for multiple domains, and sometimes it grabs one, others it grabs another.

2) you need to ensure that you have an orchestration credential set up. It uses the windows credentials for powershell.

3) you need to make sure that you hae the domain controller in the CMDB. then set up an ip range for that domain controller and assign that to the mid server.

        make sure the ci is in the cmdb

        go to cmdb_ci_ip_address and verify there is an entry in that table for your ip address of the domain controller you are hitting

        if not, create one. set nic to eth0 and tie it to the ci of the domain controller

        go to ecc_agent_ip_range, create a new range for that ip address entry

        go to ecc_agent_ip_range_m2m and create an entry to link the ip address range to the mid server.

        This is the step that fixed it for me, it forced it to use the correct mid server.

These steps should get you up and running and past that nasty error.