4

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".

  1. BUILTIN\Administrators
  2. MYDOMAIN\Schema Admins
  3. MYDOMAIN\Offer Remote Assistance Helpers
  4. 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?

Jay Michaud
  • 3,973
  • 4
  • 23
  • 36
  • 2
    Wow. This one looks like fun. Are you _certain_ that there aren't any specific user rights / privileges being granted to that group in any GPO (i.e. you've checked from an RSOP console)? I'm having a hard time coming up w/ any other ideas. (Obviously, the source code for the SID filtering functionality would crack this one wide open, but since we don't have that, we're stuck poking at a black box. I love closed-source software... *sigh*) – Evan Anderson Jun 25 '09 at 22:59
  • On second thought, I don't think that having any privileges granted by virtue of that group's membership matters. Your aggergate privilege-bundle is filtered separately from the group membership, from what I cna tell. From the descriptions I've read of the algorithm for deciding which groups to filter I can't find anything that leads me to believe that any groups other than the built-in list of well-known SIDs / RIDs will be filtered. This is damned perplexing. Perhaps somebody with access to the code will read this and clue us in. – Evan Anderson Jun 25 '09 at 23:51
  • I used the Group Policy Management console to run the Group Policy Results wizard for the user account and server in question. If I had any special user rights assigned any place, I think that it should show up at "Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies/User Rights Assignment", but this did not exist in my settings listing. (Good idea, though; I forgot to use this tool in this case. I had checked the individual GPOs that I knew were being applied, but this is the better way!) – Jay Michaud Jun 26 '09 at 16:06
  • Do you still have access to the environment where you were seeing this happen? I did some testing a couple of months ago and I found that I was able to reproduce the behavior you were seeing once. If you can still get at the environment I'd be interested in knowing the value of the "adminCount" attribute on the group that you're seeing getting filtered. – Evan Anderson Jan 14 '13 at 03:04
  • I left the company where this was occurring about two months after posting this question, so I unfortunately no longer have access to that environment. – Jay Michaud Jan 15 '13 at 15:31
  • Damn. Oh, well. This is a question I think about when I'm having trouble sleeping. I was able to replicate the behavior in one scenario w/ a group that had an "adminCount" of "1" but I couldn't get the group to stop being filtered even after resetting the adminCount back to 0. I'd _love_ to see pseudocode for the security-token group filtering code in Windows. I suppose I could throw IDA at it but, much as I do sometimes enjoy reverse engineering, that doesn't sound like a fun time. Do you recall if the group you were seeing filtered would've have ever been subject to adminmSDholder? – Evan Anderson Jan 15 '13 at 17:51
  • @EvanAnderson That's an interesting idea. I was looking for ANYTHING that pointed to the idea that the list of filtered groups being customizable and only found the static list in [*New UAC Technologies for Windows Vista*](http://msdn.microsoft.com/en-us/library/windows/desktop/bb756960.aspx). Now I'm going to have to at least try the adminSDholder theory. Otherwise this is going to end up on the list of bugs that got away (P.S. they haunt me as well!) – charleswj81 Jan 16 '13 at 03:04

3 Answers3

1

This is odd, but I've got two avenues to try:

  1. 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).

  2. 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.

  3. 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.

charleswj81
  • 2,453
  • 15
  • 18
  • Your first point is interesting information, and I would pursue it if I could. Unfortunately, I no longer have access to the environment where this problem occurred because I left the company about two months after posting this question. – Jay Michaud Jan 15 '13 at 15:34
  • 1
    No problem, if nothing else, maybe it's helpful to the next person who stumbles along via search. One other bit as well: While troubleshooting a recent issue, I ended up using `tokensz.exe` (download [here](https://www.microsoft.com/en-us/download/details.aspx?id=1448)) which is similar but seemingly more low-level and technical. I recommend at least looking at it if you are troubleshooting token/Kerberos ticket issues. While I've never personally seen the issue I mentioned in #1, it may behave more consistently. – charleswj81 Jan 16 '13 at 03:00
-1

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.

Bret Fisher
  • 3,973
  • 2
  • 21
  • 25
  • You are confusing group membership with access tokens. See [*If I’m an Administrator, Why Do I Get Access Denied?*](https://blogs.msdn.com/b/patricka/archive/2010/05/13/if-i-m-an-administrator-why-do-i-get-access-denied.aspx?Redirected=true) – charleswj81 Jan 12 '13 at 06:57
-2

Have a look at http://support.microsoft.com/kb/947223/en-us

HTH, Thomas

user3084
  • 27
  • 1