Powershell: Pipe problems when using import-pssession

Amdi Thomsen 21

I am a very fond user of Windows Terminal, and use it a lot for WSL, Powershell, etc.
I run it in my normal user context, but I sometimes need administrative privileges to our domain controllers.

Therefore I save my admin credentials and use them in a pssession command, and imports that pssession. But when doing this, piping does not work.

A simple command like: "get-aduser <username> | Get-ADPrincipalGroupMembership" throws an exception.

"Cannot validate argument on parameter 'Identity'. The argument is null or empty. Provide an argument that is not null or empty, and then try the command again."

From the error message, I conclude that the current object '$_' is for whatever reason not passed through to the next command, but why?
And is there some way to correct this?

Ian Xue (Shanghai Wicresoft Co., Ltd.) 29,486 Reputation points Microsoft Vendor

2021-03-10T07:17:03.707+00:00

Does get-aduser <username> return anything? If the username is a variable, make sure it's not empty or null.
Amdi Thomsen 21 Reputation points

2021-03-11T07:24:37.537+00:00

Hi. Yes, it does return a user object. I am able to save it in a variable, and use it afterwards. Even like follows: Get-ADPrincipalGroupMembership $user.samaccountname

Just to be clear. If I instead of importing the pssession, enters the session. Then the previous command does work and returns the users' group memberships.
Rich Matheisen 44,696 Reputation points

2021-03-11T15:18:57.58+00:00
From within the imported session (not the entered session), run this and post the results:

$x = Get-ADUser <username> $x.gettype() $x|gm|select -first 5
Rich Matheisen 44,696 Reputation points

2021-03-11T15:20:33.01+00:00
From within the imported session, does this work?

Get-ADUser "<username>" | Select-Object @{n='Identity';e={$_.distinguishedName}} | Get-ADPrincipalGroupMembership
Doug Maurer 1 Reputation point

2021-03-11T18:11:24.67+00:00

You're also not showing how you create or import your session, so you leave a lot for us to assume.

Amdi Thomsen 21

Here is the output :)

PS C:\Users\####> $x = Get-ADUser ####
PS C:\Users\####> $x.gettype()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     PSObject                                 System.Object


PS C:\Users\####> $x|gm|select -first 5


   TypeName: Deserialized.Microsoft.ActiveDirectory.Management.ADUser

Name               MemberType   Definition
----               ----------   ----------
GetType            Method       type GetType()
ToString           Method       string ToString(), string ToString(string format, System.IFormatProvider formatProvi...
PSComputerName     NoteProperty string PSComputerName=<#domain_controller#>
PSShowComputerName NoteProperty bool PSShowComputerName=False
RunspaceId         NoteProperty guid RunspaceId=9e970d14-5cd2-4303-8229-075e40f7254d

Amdi Thomsen 21

PS C:\temp> Get-ADUser "<username>" |
>> Select-Object @{n='Identity';e={$_.distinguishedName}} |

>> Get-ADPrincipalGroupMembership

Cannot validate argument on parameter 'Identity'. The Identity property on the argument is null or empty.
+ CategoryInfo          : InvalidData: (@{Identity=CN=A...DC=v####,DC=##}:PSObject) [Get-ADPrincipalGroupMembership], ParameterBindingValidationException
+ FullyQualifiedErrorId : ParameterArgumentValidationError,Microsoft.ActiveDirectory.Management.Commands.GetADPrincipalGroupMembership
+ PSComputerName        : <domain controller>

Amdi Thomsen 21 Reputation points

2021-03-11T21:02:22.747+00:00
Sorry about that.
Here is how i create and establish a connection to the pssession.

$credentials = Get-Credential $ADsession = New-PSSession -ComputerName "<domaincontroller>" -Credential $credentials Import-PSSession -Session $ADsession -module ActiveDirectory

In this example where I wanted to see if the situation was the same when entering the session i simply ran
Enter-PSSession -Session $ADsession
Amdi Thomsen 21 Reputation points

2021-03-11T21:07:54.47+00:00

I've tried running these commands without the last Get-ADPrincipalGroupMembership part, and it does return the DN as Identity.
Amdi Thomsen 21 Reputation points

2021-03-11T21:29:35.307+00:00

Not to clutter things up, but I have similar results with other commands like:
(works when entering a session but not importing)

Get-ADGroup <group> | Get-ADGroupMember

Get-ADComputer <computername> | Get-ADPrincipalGroupMembership

Get-ADComputer <computername> | Get-ADObject
Rich Matheisen 44,696 Reputation points

2021-03-11T22:16:16.877+00:00

Okay, that answers the question "why doesn't piping the output of Get-ADUser work when piped to Get-ADPrincipalGroupMembership?" The object type isn't one that the Get-ADPrincipalGroupMembership will match as a suitable type. It is, as I first suspected, a deserialized version of the actual User object. I.e. all the properties are simple strings and there are only NoteProperty properties in the PSObject. Neithere are there any except a few basic methods in the object.

So, you need a "Select-Object" in the pipe between Get-ADUser and Get-ADPrincipalGroupMembership and the Select-Object needs to create a calculated property named "Identity".
Rich Matheisen 44,696 Reputation points

2021-03-11T22:43:54.137+00:00
Phooey! The value of the NoteProperty named "distinguishedName" is, itself, a complex object. You only want the value, not the complex object itself. That takes one more Select-Object:

Get-ADUser "<username>" | Select-Object @{n = 'Identity'; e = { $_.distinguishedName } } | Select-Object -ExpandProperty Identity | Get-ADPrincipalGroupMembership
Amdi Thomsen 21 Reputation points

2021-03-12T07:14:51.367+00:00

Thanks :D That is some next level "powershelling".

That does indeed work!

I think I learned a thing or two. There is definitely something for me to play with.
Why it returns a de-serialized object I still don't quite get. But now I can at least get my scripts working.
Rich Matheisen 44,696 Reputation points

2021-03-12T16:18:29.003+00:00

When you're returning objects from another machine (i.e., you're accessing the other machine 'remotely'), the object is deserialized because moving a complete object over a network is not easy (you might be returning data from a "big-endian" machine to a "little-endian" machine), And it's costly (in terms of network traffic). In addition, the object (usually) contains things that make no sense on the 'local' machine (like a process identification), or the object contains code (methods) that not work on the local machine, or the object contains a property that has a complex structure.

Almost all of those issues can be overcome by not returning code, and by "stringifying" data.

If you really, really, really need the object then use Invoke-Command and have the code you execute on the remote machine return the data in XML format. From that you should be able to reconstruct the original data.

Accepted answer

Rich Matheisen 44,696 Reputation points

2021-03-09T16:06:28.177+00:00

I don't think the problem is that piping doesn't work. I think your problem is that you probably receive a deserialized version of the user object. The Get-ADPrincipalGroupMembership may depend on the object in the pipeline having a specific object type, or it may be trying to find the "Identity" property in the object that it receives from the pipeline.

Start by having a look at the properties in the user object returned by Get-ADUser. Have a look at the "Inputs" section of the cmdlet's help. Is the object type you got from the Get-ADUser an "ADPrincipal" or one of the derived types? If not, is there an "Identity" property in the object?
Please sign in to rate this answer.
Amdi Thomsen 21 Reputation points

2021-03-11T07:32:43.53+00:00

Thank you for your answer.

I have looked at the properties of both commandlets, and there are multiple properties that matches. On the help page for the get-adprincipalgroupmembership commandlet it states that it can receive ADPricipals of the following types:

Microsoft.ActiveDirectory.Management.ADUser

Microsoft.ActiveDirectory.Management.ADComputer

Microsoft.ActiveDirectory.Management.ADServiceAccount

Microsoft.ActiveDirectory.Management.ADGroup

This shoud be what the get-aduser cmdlet returns. As mentioned above, I am able to save the output in a variable and use it like this ex: Get-ADPrincipalGroupMembership $user.samaccountname.

If I instead of importing the pssession, enters the session. Then the previous command that includes the pipe, does work and returns the users' group memberships.

I hope I am making sense :)

Rich Matheisen 44,696 Reputation points

2021-03-11T15:32:57.71+00:00

Yes, you are making sense, but I don't think you understand what may be happening. One possibility is that the Get-ADPrincipalGroupMembership cmdlet might not be properly matching the object in the pipeline to the list of types in the documentation. That's a bug and deserves reporting, at least through the link on the cmdlet's web page.

Another is that if there is no match for the expected property type of the pipline object, that there's no "Identity" property in the pipeline object either. In this case the cmdlet throws an exception.

I created a comment earlier asking you to post the results of running a three-line script. I created another comment giving you a way that should work regardless of the pipeline object's type -- as long as the object has a distinguishedName property.

Amdi Thomsen 21 Reputation points

2021-03-12T07:17:18.45+00:00

I've marked this as an answer because you were on point.

For anyone who finds this, there are more details in the thread above.
Sign in to comment

Powershell: Pipe problems when using import-pssession

0 additional answers