0

I am trying to help someone troubleshoot an extremely odd AD\ADFS issue and am about out of ideas.

We are using ADFS to return the security groups (among other things) that a user belongs to. If that user has a specific group, then we grant them access. This is something that works on several other systems\environments. In this case, ADFS is not returning any domain groups for the user (and I have checked a few users).

If I use

Get-aduser username -properties memberof | select -expandproperty memberof

nothing gets displayed. If I do

get-aduser username -properties memberof | measureobject

it does give me a count of one.

Here's where things get really interesting.

If I check the user in ADUC, I see that it is a member of domain users, but that's it. If I go look at the group in question in ADUC, it shows this user is also a member of that group (but does NOT show this group under memberof for that user.)

If I check get-adgroupmember it shows that this user is a member of the group that I truly need returned. The SID is the same for the user that it shows as belonging to the group as it is for when I use get-aduser to check the user in question (where this group doesn't show up).

Now, all of that aside - if I go and query ADFS - I don't get any domain groups returned for the user in question (neither Domain Users nor the other one that it SHOULD be in)

I assume this is LIKELY something security related, but am at a loss.

This same exact configuration for ADFS works absolutely perfect in several of my test environments.

Any advice\suggestions?

Gabriel Luci
  • 38,328
  • 4
  • 55
  • 84
Spartenos
  • 25
  • 4

1 Answers1

2

A few things:

memberOf shows you only:

  1. Groups in your AD forest with a group scope of Universal
  2. Groups on the same domain with a group scope of Global

It does not show:

  1. Groups with a scope of Domain Local on any domain
  2. Groups on other domains in your forest with a scope of Global

There's more: the Domain Users group is a bit odd. Members of that group are not usually in the members attribute of that group. User objects have an attribute called primaryGroupID, which contains the RID of that user's "primary group". The RID is the last portion of the SID. That's what makes them a "member" of that group.

All this means that you can't rely on memberOf. You can search the member attribute of groups for the user (using the user's distinguishedName):

Get-ADGroup -Filter { member -eq "distinguishedName" }

And if you need the primary group, find that separately too.

But there is a PowerShell cmdlet that does all this for you: Get-ADPrincipalGroupMembership

It returns group objects, so if you just want the name, then pipe it into Select:

Get-ADPrincipalGroupMembership username | Select -ExpandProperty Name
Gabriel Luci
  • 38,328
  • 4
  • 55
  • 84
  • Thanks - I have tried that, and it also doesn't return the "hidden\mystery" group. This has to be security somewhere, but where?! Edited to add - this DOES return Domain Users. Again, biggest issue is the fact ADFS isn't returning ANY groups at all. – Spartenos May 15 '18 at 14:51
  • Two questions: what is the group scope of your mystery group? And is it on a different domain than the user? – Gabriel Luci May 15 '18 at 14:56
  • group scope is Global, type is Security. Single domain – Spartenos May 15 '18 at 15:22
  • If you open the group in ADUC and use the 'Attribute Editor' tab, can you see the user listed in the `member` attribute? – Gabriel Luci May 15 '18 at 15:29
  • Yes - just verified – Spartenos May 15 '18 at 17:22
  • 1
    Does this work (if you use your `distinguishedName`): `Get-ADGroup -Filter { member -eq "distinguishedName" }` – Gabriel Luci May 15 '18 at 17:27
  • Ohhhh, that DID return it..... Please tell me that tells us something good, I am at my wits end with this. – Spartenos May 15 '18 at 17:32
  • So that just searches for groups that have the user in their `member` attribute. But I thought `Get-ADPrincipalGroupMembership` includes that. I don't know why the difference. – Gabriel Luci May 15 '18 at 17:44