Windows 10 1703 Access Denied to C$ RRS feed

  • Question

  • I have Recently started Deploying Windows 10 1703 Updating us from 14393 and we have discovered an issue any pc that is on 1703 we as Admins can't access the \\PCNAME\C$ share it gives us access denied but on 14393 and previous this works just fine is there something else that needs to be set? These PCs have been setup with the install.wim straight from the 1703 ISO Out Admin Group is added the Administrators Group of all the PCs and we have Admin Rights on the PCs but we cant access the C$ share
    Tuesday, April 18, 2017 2:55 PM

All replies

  • Not sure how this worked before for you afaik c$ has been disabled remotely by default for sometime due to remote UAC.

    "Disabling Remote UAC by changing the registry entry that controls Remote UAC is not recommended, but may be necessary in a workgroup. The registry entry is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy. When the value of this entry is zero (0), Remote UAC access token filtering is enabled. When the value is 1, remote UAC is disabled."

    From User Account Control and WMI

    So try adding the “LocalAccountTokenFilterPolicy” as a DWORD Value (32bit)”), set it to “1” reboot and see if that helps. 

    Tuesday, April 18, 2017 5:42 PM
  • We are on a domain. I saw this before and tried changing this reg key and rebooting but I still get Prompted for Credentials when I type \\PCNAME\c$ and if I enter my credentials I get access denied but I am an Admin on the PC
    Tuesday, April 18, 2017 7:35 PM
  • Also it looks like everytime I set the key to 1 and restart after restart its reset back to 0
    Tuesday, April 18, 2017 8:18 PM
  • Well just test the c$ on a standard 1703 Enterprise (domain member) and could connect. So wondering what is different.

    What does the resultant set of policies show for your 1703 machine? So run box or command prompt;


    Check what is applied. if a lot check under local computer security around that area.

    Wednesday, April 19, 2017 9:42 PM
  • Hi,

    Agree with Mr Happy, the domain policy should be the cause of your issue.

    In addition, You should provide a domain user account with permission to connect to the remote machine and it works.

    Please also confirm if the Allow remote setting has been enabled:

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Monday, April 24, 2017 1:28 AM
  • Zachery,

         I am experiencing the same thing.  We have several builds of Windows 10 Enterprise in our environment, from Build 1511 up through 1703.  I've noticed that accessing \\PCName\C$ which used to work, no longer works as I get a permission error, however, I AM able to go to \\IP Address of PC\C$ without issue on a 1703 PC.  This seems to be something that was changed in Build 1703, as I have Build 1511, Build 1607, and Build 1703 PC's all receiving the same Group Polices and only the Build 1703 machines are having this issue.

    Monday, May 1, 2017 11:19 AM
  • I'm seeing the same thing, trying to map a drive to *any* share on a machine running 1703, from other Windows 10 machines (physical, or VMs), whether running 1511, 1607, or 1703.  \\computername doesn't work, but \\IP address does.  That makes me think it's a DNS-related issue, like DNS can't look up the computername.  I don't see anything unusual in the network settings dialogs on 1703.

    Edit: I can ping the 1703 machine from another computer by computername (command prompt), so that part of DNS works, but just can't map a drive to the 1703 machine by computername.

    • Edited by dukeisduke Monday, May 1, 2017 10:16 PM
    Monday, May 1, 2017 10:04 PM
  • Hi All, 

    Have you all checked if the policy was configured in your environment? 

    Under Computer configuration\Windows settings\Security Settings\Local Policies\Security Options\User Account Control: Admin Approval Mode for the built-in Administrator account

    Make sure it is disabled. 

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Tuesday, May 2, 2017 6:41 AM
  • @Kate Li,

         This policy was "Enabled" in our environment, even prior to having any Windows 10 Enterprise Build 1703 clients, and accessing \\PCName\C$ worked/works just fine.  Just for testing, I disabled it, and performed a gpupdate /force on one machine that was having the issue.  I am still unable to access \\PCName\C$.

    Thank you

    Tuesday, May 2, 2017 12:48 PM
  • We have GPO setting "Microsoft network server: Server SPN target name validation level" set to "Accept if provided by client" according to Microsoft security baseline, if I change it to "off" I can access the share. Is this confirmed as a bug by Microsoft?
    • Proposed as answer by curtleyw Friday, May 5, 2017 3:54 AM
    Tuesday, May 2, 2017 1:24 PM
  • @ Andreas Hultman - We apply the Secure Host Baseline GPO's as well and I'm seeing the same result.  If I turn this setting "Off" I am now able to access \\PCName\C$.  

    For others, this GPO is located at:  Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Microsoft network server:  Server SPN target name validation level

    Tuesday, May 2, 2017 4:46 PM
  • Just to add a voice: We see the same thing on 1703. Disabling the referenced GPO fixes it.
    Wednesday, May 3, 2017 11:26 AM
  • We also had this issue after 1703 upgrade and as above had GPO's configured as per Microsoft Security Baseline.

    I was also unable to access the shares on the PC in question by going to \\locahost.

    Removing the GPO had no affect, however explicitly setting "Microsoft network server: Server SPN target name validation level" to "Off" worked.

    • Edited by curtleyw Friday, May 5, 2017 3:55 AM Clarified Win 10 Build
    Friday, May 5, 2017 3:54 AM
  • Hi, 

    I also noticed this policy will affect the SMB authentication during you access admin share:

    Please change  GPO: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Microsoft network server: Server SPN target name validation level to Off.  ran gpupdate /force and rebooted my system. 

    both with this registry HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system\LocalAccountTokenFilterPolicy and gave it a value of 1 which was mentioned as above post. 

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Tuesday, May 9, 2017 6:26 AM
  • Same issue here... Changing the GPO-Setting "Microsoft network server: Server SPN target name validation Level" to OFF did "resolve" it...

    I have additional Information:
    - We had this issue only when we did an OS-Upgrade (Inplace) from BUILD 1511 to 1703
    - When we staged Clients directly with Win10 BUILD 1703, we did not had this issue

    Also be sure, that you update your Microsoft Security Compliance Policy the same time as your Windows 10 BUILDs, because I noticed, that the Setting "Microsoft network server: Server SPN target name validation Level" was enabled in my "old" Microsoft Security Compliance Policy (for BUILD 1511), but it is set to "Not Defined" in the newest Microsoft Security Compliance Policy...

    Friday, June 16, 2017 9:28 AM
  • Has anyone been able to explain why this policy is creating an issue with 1703?
    Monday, August 21, 2017 2:52 AM
  • Originally I created another GPO that set the specific GPO setting to Off and had it overwrite for only a handful of users since it wasn't everyone having the issue at my company. I did read recently that the August 2017 Microsoft patches resolved this issue but I haven't had a chance to go back and confirm. 
    Thursday, August 24, 2017 7:24 PM
  • Same issue here. Changing the GPO-Setting "Microsoft network server: Server SPN target name validation Level" to OFF did "resolve" it.

    However I'm only seeing this on Windows 10 1709. I have systems on 1703 with the GPO-Setting "Microsoft network server: Server SPN target name validation Level" to Accept if provided by client and it works fine.

    Anybody figure out what's going on with this?

    Friday, January 5, 2018 9:45 PM
  • Thanks Mr Happy! It worked.... Thank You !
    Saturday, February 10, 2018 7:07 PM
  • What does remote desktop have to do with accessing a server share? You are a part of what makes technet the worlds most useless forum, take the time to read the question before pasting rubbish and then marking that rubbish as the answer.

    You should feel bad because your advice is bad!

    Tuesday, February 20, 2018 3:18 PM
  • Issue is not solved, have exactly the same problem with the 1703 Baseline GPO:

    - Have set Server GPO setting SPN target name validation level to OFF

    - Have set LocalAccountTokenFilterPolicy Reg Key to 1

    - Have disabled Windows Firewall on the test client

    Still getting an error "the user has not the requested logon type on this computer"

    But when denying the whole Windows 10 1703 Baseline GPO for the target client, accessing an admin share from a remote client works after Windows 10 presents the UAC prompt before.

    Tuesday, March 20, 2018 3:06 PM
  • This has nothing to do with the question about file share access!
    Wednesday, August 8, 2018 10:28 AM
  • If you try to open an admin shares (like c$) from Windows 10 (1703) and you have this error message :

    Follow this steps :

    Open the local Group Policy Editor (gpedit.msc)

    Computer Configuration => Windows Settings => Security Settings => User Right Assignement

    Under User Right Assignement check the security settings "Access this computer from the network"

    In our environment we have find this default settings : Administrators and Remote Desktop Users

    If you have the same settings and you try to connect with a standard user account on a Windows 10 admin shares (c$) maybe you have the same logon failure message.

    To fix this problem, deploy a Computers GPO on your domain with this settings :

    User Right Assignement : Administrators and Authenticated users

    (this is the default settings for Windows 7 and it's work fine for Windows 10).

    gpupdate /force /boot to refresh your GPOs and after that the Windows Security Prompt is back :

    Another quick solution find in the web is to use credential manager.
    Add a new Windows Credential (enter the hostname of your target computer in network location and your admin account).

    I hope this post help you !

    Wednesday, August 8, 2018 3:48 PM
  • This help to solve this issue for me:

    Disable UAC Admin Approval mode ^

    Another way to access Administrative Shares is to disable the Admin Approval mode for all administrator accounts. Note that this setting not only removes the remote UAC restrictions as described above, but it also affects UAC for logged-on administrator accounts.

    Note: Disabling UAC Admin Approval mode will also disable the Windows Store app.

    1. Launch Control Panel, type admin… in the search box, and then click Administrative Tools.
    2. Open the Local Security Policy application.
    3. Navigate to Local Policies > Security Options.
    4. Disable the policy User Account Control: Run all administrators in Admin Approval Mode.


    Friday, September 7, 2018 11:19 PM
  • Don't be too hard on them/him/her.

    They are only idiot responses pasted out by automated scripts. Admittedly, there are thousands of them with the Microsoft signature.

    What I mean is, nobody could be that STUPID to give advice like that ....or could they?


    Afflicted by same troublesome environment....

    Thursday, April 4, 2019 7:52 PM
  • This worked for me.  Thank you!
    Saturday, April 20, 2019 7:27 PM
  • This worked for me for an at home workgroup.  Thank you.

    Friday, June 7, 2019 4:31 AM