We received a strange case in April which is about "access denied" encountered when user tries to connect to a file share with a local admin account. In this case study, I will use a simplified and abstracted model from original case, to show you more details of the problem.
What's the problem?
What did we do to investigate?
We called corporate IT helpdesk to check if they have any known solutions. They said they had received such kind of cases, but there's no escalation path, and they think it should be sporadical glitches, and they don't know under what kind of conditions this problem will happen. Emm… Since our customer said this problem happens on every new server on their team, I believe there must be a reason, so we did more tests.
Queried IPSec enforcement, and all of the servers were enforced with IPSec policy.
Tested with corporate (domain) credentials, and those work fine.
Tested with server local account (even with accounts that have admin rights), do not work.
Examined security logs, user authentication used NTLMv2, authentication passed, IPSec connections in the context worked fine, and local account accessed IPC$ named pipe successfully. But accessing administrative share "D$" was not even logged.
We can see the user's network logon gained privileged tokens like SeTakeOwnershipPrivilege, it should have admin rights.
We used Remote Desktop to connect to that server with server local account "test", worked.
Based on all the tests we performed, we believe the problem is not an authentication issue because we saw user get appropriate security tokens, but something just happened in the authorization check phase. We can conclude this issue like this: There might be some restrictions implemented to restrict local user from accessing administrative shares remotely.
What we found later?
In the next day, an idea suddenly struck me that UAC might restrict admin users' rights according to LUA principles. But I was not very sure, because if the user is restricted, the user won't gain some of those security tokens. Maybe there's a technique that filtered user's tokens when system does authorization check to see if the user should access the hidden administrative share "D$".
And finally we found this:
According to this article, we just created a new registry key called "LocalAccountTokenFilterPolicy" under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System, and assigned a value of "1". And then rebooted the server. After that, everything works fine.
And we found more…
Since it is UAC that implemented this restriction, I believe that turning UAC off can always help solve this problem. I turned UAC off on Server 2012 through UI, and rebooted. But after it boots up, I see there's no effect. I launched a CMD window, and it's still running in a protected admin context with less security tokens. So I search the Internet, and found we need to use registry keys to turn UAC off on server 2012.
They key is called "EnableLUA", and is under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system. To turn UAC off, we need to change the value from 1 to 0.
The trends
We can see that Windows team believe UAC is an effective technique to help reduce risks caused by privileged user rights, though UAC is not a security boundary (because it can be bypassed somehow). And it seems that they will continue to implement and improve UAC in next generations of Windows and Windows Server.
Since this time we see the UAC is mandatorily enforced in Windows Server 2012 UI, I think this is a trend, and will be implemented primordially in Windows server and client later. (If one day it will be less annoying to users, I think it will enforce implementation on client OS.)
Well, last but not least, we encourage people to use corporate credentials in corporate IT environment.
本文轉自 hbycscc 51CTO部落格，原文連結:http://blog.51cto.com/mvperic/1203744