Case of the unexplained: whoami.exe and the Deny flag

In my TechEd sessions “Raiders of the Elevated Token” I used to demo the group memberships contained in the user token using whoami.exe. Whoami.exe is a part of Windows since Windows Vista and seemed a valid tool for this purpose until I started asking questions to Mark Russinovich.

Raiders of the Elevated Token is about User Account Control. Part of the session is about how Windows creates a restricted token for users who are a member of administrative groups. Mark Russinovich wrote a very interesting article about this subject in Technet Magazine. According to the documentation there is a fixed list of groups that are considered as administrative groups. These groups are therefore flagged for deny in the restricted user token. This way users are requested to elevated when trying to perform an action in Windows that requires membership of one or more of these groups.

For my presentation I create a domain user that I add to a number of administrative groups like Administrators, Power Users, Domain Admins, Schema Admins and Enterprise Admins. Running whoami.exe as a restricted user then shows how these groups are flagged for deny. That is for all those groups except Domain Admins. During last years TechEd I already mentioned this as unexpected behavior without further investigation.

This year I decided to go a little bit further for my presentation and I created the FoolAdmin user that I made a member of every administrative group that I could find. Then to my surprise, whoami.exe showed different results. To make a long story short. When FoolAdmin is a member of both Domain Admins and Group Policy Creator Owners, the Domain Admins group is flagged for deny according to whoami.exe. If the FoolAdmin is not a member of the Group Policy Creator Owners group, the Domain Admins group is not flagged according to whoami.exe.

Screenshots of the user token group status according to whoami.exe, Domain Admins with and without Group Policy Creator Owners

After some more testing I decided it was time to ask Mark Russinovich what’s going on. Knowing how busy Mark is and how big he is in the industry, I was very surprised to find Marks first response in my mailbox within an hour. He referred me to his article in Technet Magazine. After telling him that my findings did not reflect the behavior in the article, he asked me the obvious question: Can you send me the screenshots from Process Explorer? Well I had not used Process Explorer and I should have know that is a mistake when you start mailing Mark. Luckily Mark was willing to look at my screenshots from whoami.exe, even though he did not write that tool.

After a day Mark came back and reported that I found a bug in Whoami.exe and that I should use Process Explorer from now on to demo the contents of the user token. Process Explorer from the SysInternals site shows the correct contents of the user token. It’s a shame that Process Explorer still is a separate download and not provided with the OS.

It turns out that the results of whoami.exe regarding the deny flag status for groups in the user token are totally unreliable. And it has been that way from Windows Vista until the Windows 8 Release Preview that came out on May 31st. Let’s hope it will be fixed before Windows 8 RTMs later this year.

Thanks you Mark Russinovich for helping me solve this issue!

Raiders of the Elevated Token will be presented by Raymond Comvalius at TechEd NA on June 14th in Orlando and TechEd Europe on June 28th in Amsterdam.

This entry was posted in Windows 7, Windows 8, Windows Server 2008, Windows Server 2008 R2, Windows Vista and tagged . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s