Home / server / Questions / 70484
Accepted
Tom Werner
Asked: 2009-10-02 09:09:18 +0800 CST

Troubleshooting Windows Group Policy Permissions

  • 772

I have got stumped on a privileges issue on a Windows AD Domain.

I have a Windows Server 2008 Server (with Several Windows Server 2003 vms) which are all members of a domain (but in no way backup controllers etc - this is dealt with via another server). Some of these servers need administering by people who normally have just Domain USer rights, so I created a new group (VMAdmins) added them to it and started to build a specific GPO to be applied to the machines.

The VMs are in their own OU for Group Policy and Tidyness reasons and I have created a GPO linked to that specific OU.

I have assigned various privileges to test the theory under Computer Configuration>Windows Settings>Security Settings>Local Policies>USer Rights Assignment to the group mentioned above.

I have gpupdate /force and bounced the servers and run rsop.msc to determine the applied policy. The tool correctly shows the GPO that is being applied under 'Source GPO' and the group is listed as having that privilege.

However, the crux of the problem;

whoami /priv is inconsistent with what rsop.msc says, for example rsop says that the user has the Shutdown privilege, yet under whoami it says 'Disabled'.

Can anyone shed some light onto why this might be happening?

Many thanks,

Tom

windows

2 Answers

  1. Best Answer

    whoami /priv shows the current STATE of the privilege, not the actual privilege. You'll see the same thing using the "administrator" of the domain's account. It gets "enabled' when you actually do it.

    A good explanation is here: http://alt.pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsAPrivilege.html

    Quote from there:

    The normal pattern of usage for a privilege can be demonstrated by an example. Say you want to reboot the system. You know that this is a privileged operation, so you reach up into your process token and try to enable SeShutdownPrivilege. If you've been granted this privilege by policy, your token should have it, and so you'll be permitted to enable it. If you haven’t been granted this privilege, your attempt to enable it will fail, at which point you'll need to deal with the fact that you're not allowed to reboot the system (in a desktop app, you could inform the user of her lack of privilege with a message box, for example). Assuming you've succeeded in enabling the privilege, you'll call the Win32 function ExitWindowsEx to request a reboot. Finally, you should disable the privilege. Notice the pattern here: enable, use, disable—just like the policeman with his lightbar.

    Because you're rebooting the system, you might argue that disabling the privilege is a waste of time. But just as you should never get lazy and allocate memory without freeing it, you should never enable a privilege without disabling it as soon as you're done using it. You never know who will cut and paste your code in another project! Besides, how does the routine know that the reboot will actually happen and that your program will actually exit? Often users initiate a reboot only to cancel it when they realize they need to save some work first. It's tough to know all these things deep down in a routine that's responsible for actually implementing the reboot. Make sure each of your security primitives (like privilege usage) follows best practices. Don't take shortcuts.

    Some privileges are meant to be enabled all the time if they’re granted. SeChangeNotifyPrivilege (also known as "Bypass Traverse Checking"3) and SeImpersonatePrivilege are notable examples. These are like the policeman's handgun — he’s granted the right to carry it on the street, and he's never on the job without it. If you're granted any of these privileges by policy, the operating system will enable them by default in that first token you get at login time, so you shouldn't need to worry about messing with them at runtime. Many Win32 functions (but not all) incorporate the enabling and disabling of privileges as a convenience. Furthermore, I expect that, as the .NET Framework continues to abstract more of the Win32 API, you'll have less and less need to worry about enabling privileges manually. But this is a technical detail. Security policy will still control who can and cannot perform privileged operations, so you should be aware of the privileges defined by Windows so that you know what requirements your programs will have with respect to security policy.

    • 1

  2. Is Loopback Processing enabled?

    Are you applying the Security Filtering to the right objects/users/groups?

    • 0