Some days ago I encountered some fun with UAC. I wrote up some email with some examples for some collegues. Today I stumbled upon the following: http://thoughtsonopsmgr.blogspot.com/2009/11/srs-uac-ie-esc-to-name-few.html
To be honest, I'm not against enabling/disabling UAC. However sometimes I hate the way it alters expected output. Commands simple behave in an other way instead of just telling you: "hey you need to run me elevated". In the end of this post I'll give some examples.
As an answer to the behavior of the reporting website:
Suppose you got SRS (SQL reporting server) and OS (Other Server)
If you start IE on SRS, you do it with a "deny group membership" for the following --built-in--- groups: SRS\Administrators, SRS\backup operators, SRS\power users and SRS\network configuration operators.
So, IF the reporting services website require you to have local administrator rights (membership of SRS\administrators), things will go wrong because those are stripped of your token (actually a deny group membersip) and you are accessing the website as a memberof SRS\users
However IF you visit the website remotely from the server "OS", the group OS\Administrators will be denied (due to UAC being enabled to), but the group SRS\Administrators will be in your token this time. Hence you have enough rights to actually see the required Items.
If you execute "whoami /groups" whether in a normal and elevated prompt, you can actually see what is denied.
Withouth elevation:
With elevation:
Other examples of UAC behaviour:
repadmin /showrepl (on a domain controller):
With elevation:
slmgr -dlv (show license information, determine which KMS server activated your server):
More on UAC: http://technet.microsoft.com/en-us/library/cc512679.aspx
1 Response to Explaining UAC related behavior
Hi Thomas!
Great posting. Thanks so much. It certainly explained the matter I bumped into.
Best regards,
Marnix Wolf
Add Your Comment