INvoke-Command Get-ADPrincipalGroupMembership

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

Viewing 10 reply threads
  • Author
    Posts
    • #209121
      Participant
      Topics: 66
      Replies: 71
      Points: 510
      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.

      PS C:\Users\administrator.XXXX> Get-ADPrincipalGroupMembership tpemi | sort name | select name
      
      name
      ----
      Domain Users
      EMI-FaxNotifications
      Group-AcmeAccess
      Group-EMI_BizHubColor
      Group-EMI-Accounting
      Group-EMI-AccountingSub
      Group-EMI-Administration
      Group-EMI-AllUsers
      Group-EMI-CloudUsers
      Group-EMI-HR
      Group-EMI-Management
      Group-HAR-Drive
      Group-UCI-Drive

      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: 4
      Replies: 2249
      Points: 5,494
      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: 524
      Points: 1,219
      Helping Hand
      Rank: Community Hero

      is this a double-hop issue?

    • #210306
      Participant
      Topics: 66
      Replies: 71
      Points: 510
      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.

      [w16-dc2]: PS C:\Users\brian.clanton\Documents> Get-ADPrincipalGroupMembership tpemi | Select-Object Name
      
      Name
      ----
      Domain Users
      Group-EMI-AllUsers
      Group-EMI-Administration
      Group-EMI-Accounting
      Group-EMI-HR
      Group-EMI_BizHubColor
      Group-EMI-CloudUsers
      EMI-FaxNotifications
      Group-AcmeAccess
      Group-EMI-Management
      Group-HAR-Drive
      Group-UCI-Drive
      Group-EMI-AccountingSub
      
      [10.221.21.3]: PS C:\Users\brian.clanton\Documents> Get-ADPrincipalGroupMembership tpemi | Select-Object Name
      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
      
       
      
       
    • #210321
      Participant
      Topics: 66
      Replies: 71
      Points: 510
      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: 66
      Replies: 71
      Points: 510
      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.
      $Cert = New-SelfSignedCertificate -CertstoreLocation Cert:\LocalMachine\My -DnsName "w16-dc1"
      
      Export-Certificate -Cert $Cert -FilePath C:\utility\w16-DC1cert
      
      New-Item -Path WSMan:\LocalHost\Listener -Transport HTTPS -Address * -CertificateThumbPrint $Cert.Thumbprint –Force
      
      New-PSDrive -Name "X" -PSProvider "FileSystem" -Root "\\CFS06\XXXX$\TPModules\Cert"
      
      copy-item C:\Utility\w16-DC1cert X:

      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.

      Import-Certificate -Filepath "\\w12-tp\TPModules$\Cert\w16-DC1cert" -CertStoreLocation "Cert:\LocalMachine\Root"

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

      Enter-PSSession -ComputerName w16-dc1 -UseSSL -Credential (Get-Credential XXXX\administrator)

      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.

      [w16-dc1]: PS C:\Users\Administrator.XXXX\Documents> Get-ADPrincipalGroupMembership 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

      9. Other AD cmdlets work without issue.

      [w16-dc1]: PS C:\Users\Administrator.XXXXX\Documents> get-aduser tpemi
      
      DistinguishedName : CN=tpemi,OU=EMI,OU=Hosted,DC=XXXX,DC=local
      Enabled : True
      GivenName : tpemi
      Name : tpemi
      ObjectClass : user
      ObjectGUID : db584e87-f1f2-4c5c-bce8-ce3bfa20ecba
      SamAccountName : tpemi
      SID : S-1-5-21-1752468135-3490779455-4126847218-13041
      Surname :
      UserPrincipalName :

      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: 14
      Points: 142
      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 2 months, 2 weeks ago by Stuart Squibb.
    • #210405
      Participant
      Topics: 0
      Replies: 14
      Points: 142
      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: 66
      Replies: 71
      Points: 510
      Rank: Major Contributor

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

      PS C:\Users\administrator.TP> Get-ADPrincipalGroupMembership tpemi -server 10.221.21.3 -Credential XXXXX\adminis
      trator
      Get-ADPrincipalGroupMembership : The operation being requested was not performed because the user has not been
      authenticated
      At line:1 char:1
      + Get-ADPrincipalGroupMembership tpemi -server 10.221.21.3 -Credential xxxxx\adm ...
      + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      + CategoryInfo : NotSpecified: (tpemi:ADPrincipal) [Get-ADPrincipalGroupMembership], ADException
      + FullyQualifiedErrorId : ActiveDirectoryServer:1244,Microsoft.ActiveDirectory.Management.Commands.GetADPrin
      cipalGroupMembership
      
      
    • #210438
      Participant
      Topics: 66
      Replies: 71
      Points: 510
      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: 66
      Replies: 71
      Points: 510
      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.

      PS C:\Users\administrator.TP> Enter-PSSession -ComputerName 10.221.21.5 -Credential XXXXX\brian.clanton
      [10.221.21.5]: PS C:\Users\brian.clanton\Documents> get-adprincipalgroupmembership tpemi
      The term 'get-adprincipalgroupmembership' is not recognized as the name of a cmdlet, function, script file, or op
      erable program. Check the spelling of the name, or if a path was included, verify that the path is correct and tr
      y again.
          + CategoryInfo          :
          + FullyQualifiedErrorId : CommandNotFoundException
      
      [10.221.21.5]: PS C:\Users\brian.clanton\Documents> Import-Module activedirectory
      [10.221.21.5]: PS C:\Users\brian.clanton\Documents> get-adprincipalgroupmembership tpemi | select name
      
      name
      ----
      Domain Users
      Group-EMI-AllUsers
      Group-EMI-Administration
      Group-EMI-Accounting
      Group-EMI-HR
      Group-EMI_BizHubColor
      Group-EMI-CloudUsers
      EMI-FaxNotifications
      Group-AcmeAccess
      Group-EMI-Management
      Group-HAR-Drive
      Group-UCI-Drive
      Group-EMI-AccountingSub
      
      
      [10.221.21.5]: PS C:\Users\brian.clanton\Documents>
Viewing 10 reply threads
  • You must be logged in to reply to this topic.