Get-ADGroupMember $Group fails when $Group contains principals from other domains

I've noticed that when I use Powershell to get the group membership of an Active Directory domain security group, the Powershell cmdlet Get-ADGroupMember $Group fails with the error message:

PS C:\> get-adgroupmember MyGroup
get-adgroupmember : An operations error occurred
At line:1 char:1
+ get-adgroupmember MyGroup
+ ~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (MyGroup:ADGroup) [Get-ADGroupMember], ADException
    + FullyQualifiedErrorId : ActiveDirectoryServer:8224,Microsoft.ActiveDirectory.Management.Commands.GetADGroupMember

I have tried specifying the -server $DC parameter so that the cmdlet targets a specific DC, and then I check the Security logs on that DC as I reproduce the error and no relevant security failure audits are generated. I turned up all the Diagnostics registry entries in the services\NTDS\Diagnostics key and that doesn't produce anything interesting in the Directory Services logs either.

If I remove the group members that reside in the other domain from MyGroup, the cmdlet works no problem.

Interestingly, I notice that if I run the command locally on the DC itself, it works. But when I run the command remotely from a member server, using the same user account, (who is a Domain Admin,) it fails.

Any idea what's wrong?

Solution 1:

Active Directory Powershell cmdlets such as Get-ADGroupMember use Active Directory Web Services (ADWS).

A statement such as

"it works fine when I run the command locally on the server, but it fails when I run it from a remote server"

is often a red flag that the underlying problem is Kerberos Delegation.

Many services take advantage of Kerberos delegation, and ADWS is no exception.

So let's look at my Kerberos ticket-granting-ticket (TGT):

C:\> klist tgt

Current LogonId is 0:0x95ec6

Cached TGT:

ServiceName        : krbtgt
TargetName (SPN)   : krbtgt
ClientName         : Administrator
DomainName         : FABTOSO.COM
TargetDomainName   : FABTOSO.COM
AltTargetDomainName: FABTOSO.COM
Ticket Flags       : 0xe10000 -> renewable initial pre_authent name_canonicalize
Session Key        : KeyType 0x12 - AES-256-CTS-HMAC-SHA1-96
                   : KeyLength 32 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
StartTime          : 4/21/2016 18:42:34 (local)
EndTime            : 4/22/2016 4:42:34 (local)
RenewUntil         : 4/28/2016 18:42:34 (local)
TimeSkew           :  + 0:00 minute(s)
EncodedTicket      : (size: 1109)
0000  61 82 04 51 30 82 04 4d:a0 03 02 01 05 a1 0d 1b  a..Q0..M........
0010  0b 46 41 42 54 4f 53 4f:2e 43 4f 4d a2 20 30 1e  .FABTOSO.COM. 0.
0020  a0 03 02 01 02 a1 17 30:15 1b 06 6b 72 62 74 67  .......0...krbtg
0030  74 1b 0b 46 41 42 54 4f:53 4f 2e 43 4f 4d a3 82  t..FABTOSO.COM..
0040  04 13 30 82 04 0f a0 03:02 01 12 a1 03 02 01 02  ..0.............
.........

Turn your attention toward the Ticket Flags field. Something is missing. This ticket is not forwardable.

Why would a ticket not be forwardable?

I uncheck that checkbox, flush my Kerberos tickets with klist purge, get a new tgt by performing any sort of network activity that requires getting a new tgt if I don't already have one, (gpupdate is a good example,) inspect the TGT again, and I notice that it now includes the forwardable flag.

Now the Powershell cmdlet works as expected from a member server.

When the group contains security principals (users or groups) from another domain, a referral is returned that must be chased. In order to chase that referral, ADWS must impersonate the user who made the original call. If Kerberos delegation is disabled on that user account, impersonation/delegation cannot happen.

Solution 2:

This behavior has changed with recent Windows Server security updates.

• Changes to Ticket-Granting Ticket (TGT) Delegation Across Trusts in Windows Server (PFE edition)
• Updates to TGT delegation across incoming trusts in Windows Server
• Can't enumerate group membership of groups with FSP members after running netdom /EnableTGTDelegation:No

The secure default is now to disable TGT Delegation across forest trusts. Because of this Get-ADGroupMember will fail on groups with cross-forest Foreign Security Principals until Microsoft decides to fix the issue. Until then, one workaround is to use: Get-ADGroup -Properties member