Orchestration Server – PowerShell App – Sample Usecase For Active Directory User only works on Domain Controller

  • 5 November 2021
  • 7 replies
  • 306 views

Badge +3

I request you to add to for instructions article “Sample Usecase - Getting Custom Attributes For Active Directory User and parsing the attributes using the JSON Parser node”, the note, that ActiveDirectory cmdlets work only if the configured target server is a domain controller.

I spend almost a whole day to find out the ActiveDirectory cmdlets in a PowerShell remote session only work when the target server is a Domain Controller. Also, if the ActiveDirectory Module is installed correctly on a server and the commands work locally, in a PSSession they won’t work.

 

Please reproduce that for yourselves.

Here I’m on a standard domain member server, without Domain Controller role:

    Commands are working locally

Commands won’t work when connecting with a RemoteSession to the localhost:

Here I’m on a Domain Controller; commands are working in RemoteSession

 

Therefore the Orchstration Powershell App needs to have a Domain Controller as target configured to make the commands work you are showing in your article. Otherwise you receive the exact same error as result:

Regards


7 replies

Badge

Hi @m.rieder ,

Can you please raise a support ticket for the same and provide the ticket id via DM so our team will look in and update you with the solution for this asap. 

Regards
Atul Aggarwal

Badge +3

Sure, I will do that.

Regards

Badge +1

I spent a good bit of time on this myself and found the same thing. To me, it was easier to do the powershell in Azure DevOps Pipelines and trigger the releases via the ADO API through FS’s Webhook action.

Badge +3

Thank you for confirming the issue. Our issue was not that we can't get the command to work and we don't use Azure DevOps.
I just wanted to point out that a note should be included in the article, that the illustrated example only works if the domain controller role is installed on the target server.

Badge +1

Thank you for confirming the issue. Our issue was not that we can't get the command to work and we don't use Azure DevOps.
I just wanted to point out that a note should be included in the article, that the illustrated example only works if the domain controller role is installed on the target server.

Completely agree! I wish I had known before I spent 2 days troubleshooting it and involving another person on my team while 2 others were waiting on me.

Badge +3

I already have an open ticket on this. Support is checking.

Userlevel 3
Badge +2

I request you to add to for instructions article “Sample Usecase - Getting Custom Attributes For Active Directory User and parsing the attributes using the JSON Parser node”, the note, that ActiveDirectory cmdlets work only if the configured target server is a domain controller.

I spend almost a whole day to find out the ActiveDirectory cmdlets in a PowerShell remote session only work when the target server is a Domain Controller. Also, if the ActiveDirectory Module is installed correctly on a server and the commands work locally, in a PSSession they won’t work.

...

 

There is a known ‘issue’ (or feature’) that affects PowerShell remoting called the ‘Kerberos double-hop issue’. It means that if you are remoting onto one computer, you cannot then connect to another computer with the already provided credentials. This is by design, but makes things more difficult for us.

One way aound this is by providing credentials and a domain controller name when you run the AD functions 

e.g. Get-ADComputer -server DomainController -credential $MyPSCredential

Storing and obtaining that credential can be accomplished using PowerShell Secret Management modules - you can find an overview here: Overview of the SecretManagement and SecretStore modules - PowerShell | Microsoft Learn

Reply