UAC and Domain Admins Permissions Issue or Pocket Full of Kryptonite

When are Domain Admins NOT Domain Admins?

I stumbled across some strange errors when using the UAC as a Non-Default Admin (NDA). When logged in as an NDA and not the Built-In Administrator Account (BIAA) I ran into permission issues with the User Access Control (UAC) turned on. It appeared as if the w08 box (and w08r2) could not enumerate Domain Admins membership then the UAC is turned on. Even when I gave Domain Admins Full Control of a folder (or a drive) it would not recognize membership therein.

More info (than you might want) on that at my entry here: http://www.myfriedmind.com/techBlog/2009/10/14/UACAndDomainAdminsPermissionsIssueOnWindows2008.aspx.

This is the follow up to that, after I got a hold of MSoft. I called in and even though it was the middle of the night for the gentleman on the other end of the line (he was in India) he was very coherent and helpful. Or perhaps, helpful is not the right word since I found the solution that Msoft suggests rather, ummm, absurd. This should not reflect on him at all, he was great, it is just the, ummm, solution that is whacky.

After some testing with me he did verify that I was right and that the issue was with the Domain Admins membership enumeration. He then did some research and located this article: http://technet.microsoft.com/en-us/library/cc772207(WS.10).aspx.

This lays out what is triggering the issue, how w08 (and Vista) handle Admin Approval Mode (AAM). Again, you can read my earlier post for more background if you want. Basically, Domain Admins, unlike ALL OTHER USERS, are given two tokens. They have the full access token (like everyone else) and a second access token referred to as the filtered access token. This filtered access token has the administrative powers removed. Explorer.exe (ie the root of all) is started with the filtered access token, and thus everything is started with it.

Think of it is as RUNAS in reverse. Rather than being a Domain Admin you are reduced to peon status. It is, in effect, kryptonite.

The solution that MSoft gave was very simple – do not use the Domain Admins account. At least for file and folder permissions. Create a TOTALLY NEW group and assign the people that you would normally have as Domain Admins in there. Then give THAT group the permissions that you want.

You know, that answer still makes me chuckle. What a stupid, stupid solution. Here's why

1. It does not actually do the AAM thing. It does not ask me for consent, credentials, whatever I have it set to. It just says NO when I try to access a folder. No discussion. So UAC is not actually doing its job here.
2. I can access the share of the drive or the folder if I do it via shared drives. It is only an issue if I am logged on directly to the box. I really get using UAC to prevent malicious software install, but to stop me from opening a folder??? So now I need to be the Domain Admins to log on to the server, but something completely different to access a folder.
3. It has no affect on the Built-In Administrator Account.

I already have a group that I want to use for file and folder permissions or sensitive areas. The Domain Admins. And with good reason, because they are the DOMAIN ADMINS!!!!!!!! Now I have to track two groups. All because the UAC will not play well with others.

Here is my solution –> Hey UAC! Buh-bye!!!!!