IN2Windows: Case of the Unexplained Access Denied
2013-05-19 15:48阅读：
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?
Suppose there's a Windows 2012 server called 'MLSDATA', and it has
a local account named 'test', which has admin rights. If you try to
connect to
\\MLSDATA\D$ with its
local account 'test', you will be prompted to input credentials
more than once, and it will show 'Access denied' at the same time.
If we connect through CMD window, we can see something like
this:
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 manually created a new share on drive D: and named this
share as 'D', then used local account 'test' to access \\mlsdata\D, and this worked.
- 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:
To better protect users who are members of the local
Administrators group, UAC restrictions are implemented on the
network. This helps protect against 'loopback' attacks and helps
prevent local malicious software from running remotely with
administrative rights.
http://technet.microsoft.com/en-us/library/ee844186(v=ws.10).aspx
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.
