While investigating the effects of filtered tokens on my file permissions, I noticed that one of my global security groups is being filtered in addition to the regular system-defined filtered groups.
My Active Directory environment is a single-domain forest on the Windows Server 2003 functional level. I'll call the domain "mydomain.example.com". I am logged onto a Windows Server 2008 Enterprise Edition machine (not a domain controller) as a member of the "MYDOMAIN\Domain Admins" group and the "MYDOMAIN\MySecurityGroup" global security group (among others). When I run "whoami /groups" from an elevated command prompt, I see the full list of groups to which my account belongs as expected. When I run "whoami /groups" from a regular, non-elevated command prompt, I see the same list of groups, but the following groups are described as "Group used for deny only".
- BUILTIN\Administrators
- MYDOMAIN\Schema Admins
- MYDOMAIN\Offer Remote Assistance Helpers
- MYDOMAIN\MySecurityGroup
Numbers 1 through 3 above are expected based on Microsoft documentation; number 4 is not. The "MYDOMAIN\MySecurityGroup" global security group is a group that I created. It contains three non-built-in global security groups, and these security groups contain only non-built-in user accounts. (That is, I created all of the accounts and groups that are members of the "MYDOMAIN\MySecurityGroup" global security group.) There are other, similar groups of which my account is a member that are not being filtered out of my logon token, and this group is not granted any specific user rights in the security settings of this computer or in Group Policy.
What would cause this one group to be filtered out of my logon token?
This is odd, but I've got two avenues to try:
Grab a copy of Sysinternals Process Explorer and look at the security tab for a non-elevated process, is your group still being filtered out? I ask because apparently
Whoami.exe
is known to be buggy since Vista and up to at least the Windows 8 Release Preview (see Case of the unexplained: whoami.exe and the Deny flag).What is the SID (or at least the RID) of you group? Is there any chance it is one of the built-in groups? Or it somehow got a low enough RID that LSASS thinks it's a built-in group? I don't know if that's even possible, but who knows... See the Access Token Changes section in New UAC Technologies for Windows Vista and Well-known security identifiers in Windows operating systems for more info.
And just out of curiosity, can you set a file or folder to allow access to only your group and see if it is truly being filtered out? This would potentially go towards option 1 above.
Maybe I'm missing something, but once you are in a AD security group directly or via nesting, there is no "filtering" done at login or at any other time to remove you from that group or the effects of it. Once in a group, always in the group until removed.
Could it be that your attention is focused on the wordage of the whoami command at elevated vs. non-elevated and it doesn't actually affect anything dealing with your membership in the group?
What are your results for another group membership troubleshooting tool like gpresult /r.
I bet you're still in the group and all is fine.
Have a look at http://support.microsoft.com/kb/947223/en-us
HTH, Thomas