Unable to access admin shares (c$, d$, ADMIN$, IPC$) on Windows Server 2008 in a Workgroup
Sam McGeownIf you have a Windows Server 2008 box in a workgroup that you require access to one of the admin shares, it can be a little more complicated than with Server 2003. In my case, we had a SQL server on the back end which was trying to access the web server in the DMZ using PSExec.exe to remotely run a process. Executing PSExec and passing the correct credentials failed with “Access is Denied”.
Similarly, when I tried to access the c$, ADMIN$ shares on the server, it would deny me access, and would lock out my admin account when I tried. Creating a separate share would allow me access, but that’s no good for PSExec. To further confuse things, when I accessed the \server\c$ share from the server, it worked.
Checking the share properties using “net share c$” shows that the settings are all correct, Everyone has FULL access (this is default, it uses NTFS permissions to restrict access):
This issue does not affect domain member servers, I was able to browse to the c$ shares of several Windows Server 2008 servers on the domain.
The problem is caused by UAC and the elevated privileges required to access the administrative shares. This Microsoft KB article (951016) describes the issue in Windows Vista
To better protect those users who are members of the local Administrators group, we implement UAC restrictions on the network. This mechanism helps prevent against “loopback” attacks. This mechanism also helps prevent local malicious software from running remotely with administrative rights.
and the steps to resolve it, open a new PowerShell window as administrator:
New-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -name “LocalAccountTokenFilterPolicy” -value “1” -propertyType dword
A word of caution: this is opening up a security hole and it should only be done with careful consideration of the risks. The need to use PSExec to remotely run a process was an important part of the deployment, however the same result could be achieved using PowerShell remoting. Until it’s tested and we’re ready to deploy that, I’ll be using this method.