INvoke-Command Get-ADPrincipalGroupMembership

Welcome Forums General PowerShell Q&A INvoke-Command Get-ADPrincipalGroupMembership

Viewing 10 reply threads
  • Author
    Posts
    • #209121
      Participant
      Topics: 68
      Replies: 72
      Points: 544
      Rank: Major Contributor

      I am trying to run a simple function that will utilize the Get-ADPrinciplaGroupMembership function on the Active directory server with the supplied AD Login name.

      I can run this command directly on the Server with no issue.

      When I invoke this command from a another server, I get the following error:

      $Login = 'tpemi'
      Invoke-Command -ComputerName 10.221.21.3 -ScriptBlock { Get-ADPrincipalGroupMembership -identity $Using:Login } -Credential $TPCred

      The operation being requested was not performed because the user has not been authenticated
      + CategoryInfo : NotSpecified: (tpemi:ADPrincipal) [Get-ADPrincipalGroupMembership], ADException
      + FullyQualifiedErrorId : ActiveDirectoryServer:1244,Microsoft.ActiveDirectory.Management.Commands.GetADPrincipalGroupMembership
      + PSComputerName : 10.221.21.3

      I verified the authentication by utilizing the Enter-PSSESION cmdlet and reproduced the error while running directly within the session.  That IP address in the Prompt is the DC, which I am authenticated to with domain admin level permissions.  Seems like there is something ‘special’ about this cmdlet when launching it from a remote session.  Don’t have an issue running other AD cmdlets remotely (get-aduser, get-adgroup, etc…)

      10.221.21.3]: PS C:\Users\administrator.XXXXX\Documents> Get-ADprincipalGroupMembership -Identity tpemi
      The operation being requested was not performed because the user has not been authenticated
      + CategoryInfo : NotSpecified: (tpemi:ADPrincipal) [Get-ADPrincipalGroupMembership], ADException
      + FullyQualifiedErrorId : ActiveDirectoryServer:1244,Microsoft.ActiveDirectory.Management.Commands.GetADPrincipalGroupMembership

       

       

    • #209130
      Participant
      Topics: 10
      Replies: 2481
      Points: 6,543
      Helping Hand
      Rank: Community MVP

      As far as I remember is there a difference between remoting using a computer name and using an ip address. This might help you a little:

      https://stackoverflow.com/questions/6587426/powershell-remoting-with-ip-address-as-target

    • #209151
      Participant
      Topics: 12
      Replies: 547
      Points: 1,345
      Helping Hand
      Rank: Community Hero

      is this a double-hop issue?

    • #210306
      Participant
      Topics: 68
      Replies: 72
      Points: 544
      Rank: Major Contributor

      No double hop.   As illustrated here, I have a direct session from one server to the domain controller.   Same command with one session authenticating via IP address and the other using hostname.

      The issue appears to be what OLaf indicated.  Using Kerberos authentication along with an IPAddress doesn’t work specifically for this command.  Other cmdlets work find using the IP address, but not this one.

    • #210321
      Participant
      Topics: 68
      Replies: 72
      Points: 544
      Rank: Major Contributor

      Like to amend what I said. It is not Kerberos that is the problem, it is the fact that NTLM is used instead of Kerberos when you authenticate using an IP address.

      “The ComputerName parameters of the New-PSSession, Enter-PSSession and
      Invoke-Command cmdlets accept an IP address as a valid value. However,
      because Kerberos authentication does not support IP addresses, NTLM
      authentication is used by default whenever you specify an IP address.

    • #210396
      Participant
      Topics: 68
      Replies: 72
      Points: 544
      Rank: Major Contributor

      Even after generating an SSL cert for the domain controller and then trying to run ‘Get-ADPrincipalGroupMembership’ on the server while authenticated via SSL, I am still having the same issue.   My objective is to be able to use Invoke-command from a domain that has a VPN to our datacenter domain controller to run Get commands, namely ‘Get-ADPrincipalGroupMembership’.

      I am referencing the steps outlined here:

      https://4sysops.com/archives/powershell-remoting-over-https-with-a-self-signed-ssl-certificate/

      1. I generated a SSL Cert on the domain controller
      2. From the domain controller (w16-dc1), I exported the cert to a file and then copied the file to a share that is accessible to my workstation (at the office on another domain than the server).   I also set the https listener, adding the Cert thumbprint.

      3. I verified that the cert file was located on the domain controller within MMC (Certificates[local computer] – Personal – Certificates

      4. I also verified all firewall settings on the Server.

      5. From my machine at the office (VPN to the domain controller), I added w16-dc1 in my hosts file which maps to the internal IP adderss of the domain controller.  I did this since my workstation cannot resolve w16-dc1 due to it being an another domain.

      6. I then imported the cert file on my local workstation.

      7. I then initiated a remote session to the domain controller via hostname.

      8. I was able to successfully enter a interactive session, however the problem with the Get-ADPrinciplalGroupMembership cmdlet still exists where it doesn’t like my mode of authentication.

      9. Other AD cmdlets work without issue.

      So not sure where to go from here.   End game is for our technicians to generate lists without having to remote to resources within the hosted network that is on the same subnet as our DC.

       

    • #210399
      Participant
      Topics: 0
      Replies: 15
      Points: 225
      Rank: Participant

      Have you tried running the Get-ADPrincipalGroupMembership cmdlet on your local machine but using the -Server parameter to point to the DC?

      You need RSAT installed on your local machine for the ActiveDirectory module to be available in PowerShell.

       

       

       

      • This reply was modified 10 months, 2 weeks ago by Stuart Squibb.
    • #210405
      Participant
      Topics: 0
      Replies: 15
      Points: 225
      Rank: Participant

      Is your target DC a Global Catalog? This is from the help for Get-ADPrincipalGroupMembership:

      “This cmdlet requires a global catalog to perform the group search.”

      If the DC is not a Global Catalog then the cmdlet may be trying to talk to another DC, thereby introducing a double-hop.

       

    • #210432
      Participant
      Topics: 68
      Replies: 72
      Points: 544
      Rank: Major Contributor

      I ran it with the ‘server’ parameter from a server on our network.  Same issue.

      • This reply was modified 10 months, 2 weeks ago by Brian Clanton.
      • This reply was modified 10 months, 2 weeks ago by Brian Clanton.
    • #210438
      Participant
      Topics: 68
      Replies: 72
      Points: 544
      Rank: Major Contributor

      I checked Active directory and both of the servers I tested were marked as ‘Global Catalog’.

       

      • Went into the AD ‘Domain Controllers’ container
      • Right clicked EACH domain controller I tested and then went to ‘NTDS Settings’
      • Both had the ‘Global Catalog’ radio checked.
    • #210447
      Participant
      Topics: 68
      Replies: 72
      Points: 544
      Rank: Major Contributor

      We actually have 4 DC’s…two of which are Win2008 we are eventually going to decommission. Just to Test, I remotely connected to the Win2008 box. It did not recognize ANY AD commandlets, so I imported the AD module and then I was able to run my command connected to the server via IP address.

      Not sure what that tells me about this server.

Viewing 10 reply threads
  • The topic ‘INvoke-Command Get-ADPrincipalGroupMembership’ is closed to new replies.