The other day, I was setting up my very first corporate Vista machine. It was a new laptop with Vista Business pre-installed that was to become the first live Vista machine on our corporate network. An exciting day it was. ... Okay, actually it was a pretty frustrating day because this machine was NOT cooperating. I had deployed test machines in our sandbox OU and thought I had ironed out all the problems, but not so... This laptop had one glaring horrible problem: I could not log on as a domain admin!
Now that's a big problem...
I was perfectly able, mind you, to log on as my normal account and then elevate to a domain admin when needed, but the domain admin logon itself failed. All I would get is a lonely empty black screen. It's as if Windows Explorer forgot all about me. How depressing! I named this experience the "Black Screen of Purgatory."
So what was the problem?
I went back to my regular logon, fired up Event Viewer and scoured the logs. This is the event that I found every time I tried to logon interactively as a domain admin...
Log Name: Application
Source: Winlogon
Event ID: 4006
Level: Warning
Description:
The Windows logon process has failed to spawn a user application. Application name: . Command line parameters: C:\Windows\system32\userinit.exe.
Interesting, eh? Winlogon was actually failing to spawn a process. I wonder why? It runs as SYSTEM, afterall, even in Vista. SYSTEM has full control over most everything.
I scoured the google and found only a few pages related to Vista and only one related to Vista and domain admins logging on. The culprit? UAC.
Oh that blessed security feature we all love to hate! (--or is it hate to love?) Apparently, UAC was trying to open an elevation prompt during logon. Well, no interactive session has yet been established (that's the job of Winlogon and userinit.exe afterall) so the UAC elevation prompt just gets lost in the ethos of the Black Screen of Purgatory.
Luckily, if you press Ctrl+Alt+Del, you still get the security menu. No, TaskMgr won't run. But you can log off without powering down your computer.
The article that discovered UAC was the culprit also noted that turning off UAC fixed this problem. Well, of course disabling a security feature and preventing it from doing it's job will make things work (just ask the developers at the company I work for), but that's the cheap way out. I want to figure out WHY this is happening and fix it.
So I started doing some tests. First, I tried a local administrator account. That works! Wow, domain admins don't, but local admins do. Interesting. So then I guessed that maybe a GPO was the problem, so I pulled the computer out of it's home OU and put it into a test OU which blocks all policies. I rebooted.
I was able to log on as a domain admin. Very interesting! It was a GPO. But which one?
After gradually adding and enabling all applicable policies, I found the culprit: Restricted Groups.
That's an unusual, culprit, isn't it?
In order to keep local groups clean, I use Restricted Groups to prevent unauthorized additions to the Users and Administrators groups on workstations. In XP, it was sufficient for Domain Admins to be members of only the Administrators local group to gain full access to the machine. This is not the case in Vista. For some reason, if Domain Admins are not ALSO in the Users local group, they cannot logon due to UAC trying to request an elevation prompt at pre-logon. Apparently, permissions are set okay from a traditional standpoint (disabling UAC "fixes" this issue), but UAC doesn't like tradition. The reason you don't commonly see this issue on Vista machines is because in Vista, the built-in principle INTERACTIVE is normally automatically a member of the Users local group, but I had overwritten the Users local group with my own members by policy. Why do I do this? Because I don't want, for example, role accounts getting interactive sessions on workstations. I'm just paranoid like that.
I also noticed that in Vista, Local Service and Network Service are automatically members of the Users local group, so I suggest also adding those to your Vista Restricted Groups policy to prevent future weirdness.
Mystery solved and case closed.