Discussion Forums/General/General Documentation

Can't access ADMIN$ share using a local user account

Shane Corellian
posted this on December 30, 2011 09:52

If you are attempting to access (either with PDQ Inventory or PDQ Deploy) a Windows 7, Windows 8, Vista or Server 2008 computer you may get  the" Access Denied - Failed to connect to ADMIN$ share" error , even when supplying the appropriate local user credentials that have Administrator access. If the target computer is not a member of a Windows 2003 or later Domain then this is most likely because the target system has Remote UAC enabled. Remote UAC prevents local administrative accounts from accessing ADMIN$. (more appropriately Remote UAC prevents local accounts from running in an elevated mode when connecting from the network) If you need to be able to access the ADMIN$ using a local account then you will need to disable Remote UAC. You can accomplish this by editing the registry. 

Assuming you have all your other ducks in a row (Firewall exceptions, appropriate credentials of local administrative user, etc) then you just need to add a quick entry in the registry of the target computer. In the registry, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System. Create a DWORD value called LocalAccountTokenFilterPolicy and assign it a value of 1.

A reboot will be necessary (actually you can just restart the Server service but a reboot is ideal). See image.

LocalAccountTokenFilterPolicy.png

* By default, when local credentials are used to access a Windows Vista (or later) system that is a member of a Windows Domain this problem does not exist. Your Windows domain may still disable Remote UAC.

** By default Remote administrative access is denied to local accounts when a Windows Vista (or later OS) is NOT a member of a Windows 2003 or later domain.

Further reading:

http://support.microsoft.com/kb/942817

http://support.microsoft.com/kb/951016

 

Comments

User photo
Matthew Newton
Basic Subscription

Will your bundled "remote repair tool" fix this?

April 23, 2014 07:59
User photo
Don Chino

I know this is OLD, but lately I have been noticing something "afoot" in our Network Domain because I have made this change on various Windows 7 machines although after a few days and some reboots suddenly the ADMIN$ share is no longer accessible. This then requires me to log onto these machines to perform a "Remote Repair" with the tool, since this cannot be accomplished from a central location, which REALLY needs to be fixed because this is extremely time consuming.

Anyway, as I was saying the ADMIN$ get blocked, I check the registry and the changes are not touched; but when I run the "Remote Repair" tool locally suddenly everything is working again, so what exactly is the "Remote Repair" tool fixing to make the ADMIN$ share work. We need to know this, because it is possible some sort of routine is being run on the domain somehow locking this share and then I have to constantly run the tool to re-open it, but this also begs the question if this share is being closed as a security measure.

1) Provide us what the tool is fixing to get the share working so we can run some sort of script at some set time interval.

2) Maybe stop using the ADMIN$ share because someone from Enterprise Security might eventually contact us about why we keep opening up this share.

 

Once again, this behavior is ONLY appearing on my Windows 7 machines and ONLY those machines registered on the DOMAIN, so it looks to me like someone in my company is pushing something enterprise-wide.Thanks... :)

April 24, 2014 16:05
User photo
SelfMan
Basic Subscription

Check for the folloving registry keys if they exist

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters]
"AutoShareServer"=dword:00000000
"AutoShareWks"=dword:00000000

 

April 24, 2014 16:43
User photo
SelfMan
Basic Subscription

Oh please note that these setting prevent the re-creation of the default admin shares.

April 24, 2014 16:44
User photo
Don Chino

Well, I already ran the "Remote Repair" tool, so it is possible the tool updated these settings but I guess I will have to check next time I get an ADMIN$ error and post here because at the moment BOTH these values are set to "1". That means, according to you, that the system allows re-creation of the default admin shares, but I already ran the "Remote Repair" tool on ALL machines so this will have to wait until next time to see if "something" is setting these to "0" and then after a reboot or something this disappears.

Once again, it is not after every single reboot but seems to occur over a prelonged period of time where I am rebooting machines, such as weekend service and whatnot so I have not paid attention to how often this occurs and only now noticed that it was a specific set of machines always repeating this behavior. I will make a note and come back with any findings, but I do believe they might have to move away from the ADMIN$ share if someone in Enterprise Security is pushing some sort of script on the domain to close what they see as a "security hole" or I will have to run some sort of script at boot and shutdown to counter the counter... :(

April 24, 2014 16:53
User photo
Don Chino

Ok, so a minor update, but it has been confirmed. Once again, I performed a "Remote Repair" on several machines, but then after a week or so suddenly various Windows 7 machines lost their ADMIN$ share and Admin Arsenal was unable to perform it's duties. The only difference this time is that I am noticing some Windows 2008 R2 machines also being affected, so previously I thought it was limited to Windows 7 plus I am noticing that some non-Domain machines are being affected.

This leads me to believe that this is not something being pushed by Enterprise Security, but rather something being modified possibly by Microsoft when Windows Updates are being applied, because I am noticing that it is occurring with some Domain and non-Domain machines regardless of Windows version. I do not apply Windows Update consistently across ALL machines, but rather based on grouping so this might explain why I am noticing different types of machines behaving differently at different times although I am surprised others have not complained about this, so I will go ahead and check my Local Group Policy as well.

Always possible the WSUS implementation did something "weird" although I doubt it, since my settings are still preserved but SelfMan's registry setting have been reset to 0 while the LocalAccountTokenFilterPolicy is still set to 1 which means it is not enough to simply set the above. So others cant take note and I might end up having to add a script to the Shutdown/Startup group to make sure this setting is not manipulated by some random gnome...

May 02, 2014 15:40
User photo
SelfMan
Basic Subscription

Its time to "go deeper" and check for few things. Use NirSoft's RegScanner to view the mentioned registry keys. You can see the modification time of the key, which might help you to narrow down the culprit. http://www.nirsoft.net/utils/regscanner.html

The other thing is that you can start the sysinternals process monitor and let it monitor the required keys to see what is changing them.

May 03, 2014 00:15
User photo
Matthew Newton
Basic Subscription

I'm curious. Any update Don?

May 12, 2014 14:00
User photo
Don Chino

Just a quick update, since Matthew asked; but basically I have a series of scripts that run on boot, login, logout, shutdown so I am able to add some registry modifications at any of these points. Anyway, so what I did was add the registry mods that set the following to 1 - AutoShareServer, AutoShareWks, LocalAccountTokenFilterPolicy - this occurs at every boot and every 15 minutes just to make sure nothing is foobar'ing my work. Might be overkill, but sadly today I logged on after Memorial Day Weekend and 3 machines have ALL their admin shares missing C$, ADMIN$, IPC$, etc...

Registry mods are in place. Remote Repair cannot repair remotely. I run Remote Repair locally and all works again, so I can only assume that Remote Repair is running some sort of command to "recreate" these shares manually and not really modifying any registry entries. Either way, my script "fix" is technically working, because all the above mentioned registry keys are correct, but the ADMIN shares STILL disappear which means there is a gnome somewhere that is removing these shares. AntiVirus is working and nothing detected, so my initial suspicion was that Enterprise Security is running some sort of script turning these shares OFF as a security measure, but it is not occurring on ALL machines so that somewhat rules that out and obviously someone might say malware.

I guess I have to start noting down which machines are misbehaving, because it seemed to me that it was random machines but after these script "fixes" it seems to have calmed down a LOT but now it is still a few machines acting up so I now have to try SelfMan's suggestion to "go deeper" to pinpoint root cause. As you all know, that means MORE TIME, MORE EFFORT so that is my update for now, since I was "busy" with the onset of summer but I will just post back if I finally resolve this unless Admin Arsenal moves away from ADMIN shares... :P

May 27, 2014 13:48
User photo
SelfMan
Basic Subscription

Please check if the "Homegroup" feature is installed/enabled. It disables the admin$ share.

  1. Open the control panel.
  2. Go to Network and Internet.
  3. Go to HomeGroup.
  4. Click on the blue link Leave the homegroup.

May 27, 2014 15:14
User photo
Don Chino

Homegroup only applies to the Windows 7 Machines, plus only when the Network Location is set to HOME so mine are under DOMAIN which means Homegroup is not activated anyway. Checked, just to be sure, and yep all turned off, disactivated by default...

Just to clarify, the shares that are disappearing are ADMIN$, C$, D$ so IPC$ and any other shares I DEFINED stay in place, which makes me wonder if it just "auto-generated" shares that are being removed by some gnome. I will now create the shares manually and see if they disappear, maybe add this to the script "farm" of hacks but like I said it is not as bad as before where machines were dropping like flies every couple of days so at least now it is just 3 Windows 7 machines.

So if I fix this then the only outstanding problem will be the timeout on the machine with dozens of shares, but that is in another post... :)

 

May 27, 2014 18:57
User photo
SelfMan
Basic Subscription

hmm then the AutoRuns from sysinternals is your best friend now. Still I would take one of the machines offline, boot from an external PE media and check it with multiple antivirus engines just to be sure. According to Microsoft, these problems are mostly caused by some malware or malware leftovers.

May 28, 2014 00:01
User photo
Don Chino

Ok, a little annoyed now. Ran 3 different Virus Scans and the machine is clean. I have all the correct Registry entries. I even set it up where if the ADMIN$ share is missing the machine will reboot, but still no shares appearing ... BUT ... BIG BUT...

When I run Remote Repair, somehow it is working again. No reboot needed and C$, D$, ADMIN$ shares reappear, so what exactly is Remote Repair running because something is making these shares disappear even when everything is configured correctly. I am testing across different machines and I am even building a new machine template with Windows 7 to see if it is something that was altered after I joined the domain, but the fact is that Remote Repair recreates those shares with the push of a button so can someone share the "secret".

Remote Repair cannot repair this remotely and it must be run locally, but I either have to know what command Remote Repair is running to recreate these shares OR Admin Arsenal should share the command line way of calling Remote Repair and automatically correcting errors. I tried to see if RemoteRepair had some sort of help interface, but there seems to be none and this little utility has to be run interactively, so I would suggest that Admin Arsenal make this a command line utility where we can pass parameters/switches to basically perform this repair from a script.

I could dig "deeper" but I think this should be allowed in case this is something that is being done purposefully, such as Enterprise Security; which means a headache for me as I will have to question the Windows Security guys and they will not tell me squat, if they even know. At least with the command line interface, I can run a periodic check and then run RemoteRepair locally as a scheduled task which does not seem possible at the moment.

May 28, 2014 22:18
User photo
SelfMan
Basic Subscription

Make a list of running services - NET START > services-list1.txt. Run remote repair locally. Create a new list of running services - NET START > services-list2.txt and compare it using WinMerge or other file compare tool. (excel does it too) This sounds like a service should be running but its not and its set to manual.

May 29, 2014 00:19
User photo
SelfMan
Basic Subscription

Particullary, check if the "Server" service is running. If yes, try to restart it.

May 29, 2014 00:24
User photo
SelfMan
Basic Subscription

Oh and also check the event log for RPC related errors.

May 29, 2014 00:27