INvoke-Command Get-ADPrincipalGroupMembership

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

 

 

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

is this a double-hop issue?

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

 

 

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. '

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

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

  2. 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.

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

Import-Certificate -Filepath "\\w12-tp\TPModules$\Cert\w16-DC1cert" -CertStoreLocation "Cert:\LocalMachine\Root"
  1. I then initiated a remote session to the domain controller via hostname.
Enter-PSSession -ComputerName w16-dc1 -UseSSL -Credential (Get-Credential XXXX\administrator)
  1. 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
  1. 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.

 

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.

 

 

 

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.

 

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

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.

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>