Link to home
Start Free TrialLog in
Avatar of hypercube
hypercubeFlag for United States of America

asked on

Which Security Group for a User is in effect? On the Domain? On the workstation where the User is logged on?

I'm working on a problem where switching User Security Group membership isn't doing what it should.
I'm using 3 commands to ascertain if a particular Security Group is actually in effect.
whoami /groups
gpresult /r | find [groupname]
net  groups [groupname] /domain
in that order.
I've researched it but haven't found a nice, clear statement of what is being reported for each.
Is it from the domain controller?  Or, is it from the local cache?

I can see when they disagree.  It is of course then 2:1 but sometimes it's a different "2".
So that's rather baffling.
I don't believe that I've ever seen whoami/ groups yielding the odd result.
Sometimes net  groups [groupname] /domain yields the odd result.
Sometimes gpresult /r | find [groupname]  yields the odd result.
I don't believe that I've ever seen whoami/ groups yielding the odd result.
Sometimes they all agree - which is what I want I should think!

Which reports from the domain controller?
Which reports from the local computer?
Now, I suppose that a report from the local computer may or may not agree with the domain controller but find it surprising / disturbing that two reports from either the domain controler or the local computer would disagree.

Any insights would be appreciated!


Avatar of Bembi
Bembi
Flag of Germany image

Hello
whoami list the memberships in all groups, so local or domain from the machine perspective.

gpresult analyses the GPO result and you search inside the result for a string.
Here you see domain groups and security principals, but no local groups

net groups runs on a DC, therefore you see the groups on the DC (a DC doesn't have local groups, they are mapped into AD, but not shown here) . So the groups are coming from the AD. Your exampe is to findout the members.

Be aware that group memberships on a client make  take a reboot to come into effect. For kerberos it may play a role, when the kerberos token is created. So there may be a delay waht the tool show as the data has different sources.

Be ware that windows has direct memberships as well as indirect memberships.
Direkt = a user is member in a group
Indirect = a user is member of a group, which is member of another group.  
And there are also permissions connected to a security pricipal, like Authenticated users or Interactive.

According to your question "which groups are in effect"...
There all in effect, anywhere, if they are in effect (see above)
With the exception you defined a deny permission.

I'm not quite clear, if I could catch your question. Maybe an example may clarify  you question behind the question :-)
I've seen gpresult be wrong about group memberships, even long after replication delays were factored in. Flat out wrong.

I've never seen "whoami /groups" or "net group" be wrong except while waiting for replication to happen.
Avatar of hypercube

ASKER

Bembi:
The situation is this:
The workstation User can be the member of ONE of TWO security groups in AD.  
Those security groups have file read only and file write privileges on some local stores respectively.
The workstation is headless and the User logon is assured.
The User's group membership is switched from one to the other at least 2 times each 24-hour period.  
This is done with a script on the Domain Controller which removes the current membership and subsequently adds the other membership.  
This is working on 2 out of 3 workstations (each associated usually with a different / local Domain Controller).  
The Domain Controllers are replicated after each change.
The workstations are rebooted after each change and after the DC replication.

The process isn't working on but one of the workstations.
So, I've been trying to analyze and fix.
Thus the log results I reported here are of interest.
When I asked: "which groups are in effect", I meant "which groups *being reported* are actually in effect".
It can only be one or the other I believe.

Michael B. Smith:
Interesting about gpresult!!
Of these commands taken one after the other via a single script, at each log entry:
whoami /groups
gpresult /r | find [groupname]
net  groups [groupname] /domain
I have *many cases* where whoami /groups and net groups [groupname] /domain do disagree.
both whoami and net groups query AD for group membership of the current security principal. the only difference that should be shown would be due to replication delays.

check your replication health if they aren't consistent within 15 minutes after a group change.
Michael B. Smith:
both whoami and net groups query AD for group membership of the current security principal. the only difference that should be shown would be due to replication delays.
Thank you!  
Well, perhaps this gets to the crux of my original question and it serves as a boost to this discussion!
I should think it relatively unlikely that the same information from the same source could differ within milliseconds AND be consistent every half hour (which is what this is doing)  The results seem stable after a change.  Changes are from 6 to 18 hours apart.
So, when you say: "query AD for group membership of the current security principal", I assume you mean "at the DC in both cases".  
So, how could they be different at the same time and for a long time?  
There is something fundamental going wrong here - and I shouldn't preclude any dumb mistakes on my part.  But the other two workstations and their local DCs seem to be just fine.  
Depends on replication, as I wrote.

You are assuming that both commands get their information from the same DC. I don't make that assumption.

And without source code (which I don't have) I can't tell you how each utility chooses its DC.

You could, using something like portqry, determine the various DCs each is using.
OK, lets try to reproduce the behaviour.
You change the membership of a computer device from one AD Group to another (directly, not via GPO)
- you have to wait until the DCs are in sync (to make sure the client cannot catch a not synced DC)
- you reboot the machine...
- the client reads it group memberships as well as GPOs during boot.
The effect should be, that the computer account as well as the user account should reflect the group memberships in AD.
Doesn't matter which method of proof you use at this point, they should not differ.
And all methods should report the effective memberships.  

If you change settings while the client is online, they may differ due to the different sync times.
DCs are usually syncing fast, dependend form you infrastructure.
GPOs are snycing +- 90 minutes by default

After this change, the different methods will differ, until all syncs have happened.
And all three method may not reflect, what is really in effect at this moment.

Not all settings can be applied at once, expecially group memberships apply usually if the affected account (computer or user) recreates their token or relogon (for computer accounts = reboot). While NTLM authentication allways is checked for every access against the DC, Kerberos permissions need to recreate the token, which can take several days (dependend from the account policy).

The reverse effect of kerberos is also, that a client may still have access to resources even you have changed the group memberships until the user log off, or the machine is rebooted.

My question would be now:
The clients, which do not catch the group change, do they catch them, if you reboot the machine later again? Lets say after 2h? Also not excluded, that there is an account problem or duplicate SID or whatever.

From your description:
Due to the authentication mechanisms, if you have to change permission several times a day, you should change them from the permission perspective and not from the user / group perspective. With kerberos, it can not work reliable. 

Michael B. Smith:  Yes, I've been assuming that all of the commands get their information from the same DC if at all.
While it's possible this is incorrect, it's hard to imagine it would be.  One might ask: how?  All of the treatments I've seen seem to be looking for THE DC and not ANY DC.  But, yes, that could be wrong.  But then, the work on replication would have had to be fruitless as well.
Bembi:  Thank you!!
You change the membership of a computer device from one AD Group to another (directly, not via GPO)
- you have to wait until the DCs are in sync (to make sure the client cannot catch a not synced DC)
Part of the script that changes the membership also forces replication.  This seems to be working.

- you reboot the machine...
- the client reads it group memberships as well as GPOs during boot.
The effect should be, that the computer account as well as the user account should reflect the group memberships in AD.
Doesn't matter which method of proof you use at this point, they should not differ.
But they do.

And all methods should report the effective memberships.  
So, they can't as they differ.
An interim reboot hours after the change didn't change anything.

As you suggested, i checked for duplicate SIDs and found none.
Due to the authentication mechanisms, if you have to change permission several times a day, you should change them from the permission perspective and not from the user / group perspective. With kerberos, it can not work reliable.

WOW!  That seems rather significant.




The reason I was checking using various tools was because it had been suggested that the one workstation could not get it's AD-based information before it defaulted to cached information.  
The only thing I can say about that (and I'm not sure it's even likely) is that this one workstation is somewhat further removed geographically (50 miles on fiber interconnect) from the other 2 DCs.  However, it has a local DC that has been replicated.
I have seen
echo %logonserver% run on this workstation occasionally reporting a more distant DC and don't know why that happens or if it might not be an indicator.....
Maybe the good news is that the problem is consistent over a few days: i.e. if I force the membership "state" to be one thing then it seems to live for a few days before reverting back to the problem state where it doesn't effectively change membership.

ASKER CERTIFIED SOLUTION
Avatar of Bembi
Bembi
Flag of Germany image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
There are actually 4 groups with one each in a separate OU.  
One is in an enterprise-wide group and is used by all workstation Users for this process.
In a perfect world, all 3 site Users would be in this group at the same time.
(Future plans aside for now).
The other 3 are each in one of 3 separate OU's.  One per site.
So, it's the one site that is intermittent in changing as I've said before.
I can't imagine that being in different OUs would afftect the switching dynamics would it? Here, Groups1-4 are each in different OUs.
User generated image
What have group memberships to do with OUs?
With the exception you struggled the OU permissions, the OU is corrupt or other bad things.

OUs may have somthing to do with policies. But they first at all have an organizational aspect.
Just to make it clear...
We talk about user accounts, right? Not computer accounts?

Yes, User accounts.
The OUs do have an organizational aspect here.
The question was: would this matter?  I didn't think so.  But in the sense of completeness, I simply mentioned it.

For group membership they don't matter.
Do you now need next steps or are you able to test what I wrote before?
I should have a better idea in a day or two.  Some testing has to be done at night.
Thank you!!