Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Tuesday, April 18, 2017 2:55 PM | 1 vote
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
All replies (30)
Tuesday, April 18, 2017 5:42 PM | 11 votes
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 7:35 PM | 1 vote
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 8:18 PM | 1 vote
Also it looks like everytime I set the key to 1 and restart after restart its reset back to 0
Wednesday, April 19, 2017 9:42 PM | 2 votes
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;
rsop
Check what is applied. if a lot check under local computer security around that area.
Monday, April 24, 2017 1:28 AM | 1 vote
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 [email protected].
Monday, May 1, 2017 11:19 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 10:04 PM
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.
Tuesday, May 2, 2017 6:41 AM | 1 vote
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 [email protected].
Tuesday, May 2, 2017 12:48 PM
@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 1:24 PM | 4 votes
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?
Tuesday, May 2, 2017 4:46 PM | 3 votes
@ 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
Wednesday, May 3, 2017 11:26 AM | 1 vote
Just to add a voice: We see the same thing on 1703. Disabling the referenced GPO fixes it.
Friday, May 5, 2017 3:54 AM | 1 vote
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.
Tuesday, May 9, 2017 6:26 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 [email protected].
Friday, June 16, 2017 9:28 AM | 1 vote
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...
Monday, August 21, 2017 2:52 AM | 1 vote
Has anyone been able to explain why this policy is creating an issue with 1703?
Thursday, August 24, 2017 7:24 PM
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.
Friday, January 5, 2018 9:45 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?
Saturday, February 10, 2018 7:07 PM | 1 vote
Thanks Mr Happy! It worked.... Thank You !
Tuesday, February 20, 2018 3:18 PM | 7 votes
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, March 20, 2018 3:06 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.
Wednesday, August 8, 2018 10:28 AM | 2 votes
This has nothing to do with the question about file share access!
Wednesday, August 8, 2018 3:48 PM | 1 vote
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 !
Friday, September 7, 2018 11:19 PM | 2 votes
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.
- Launch Control Panel, type admin… in the search box, and then click Administrative Tools.
- Open the Local Security Policy application.
- Navigate to Local Policies > Security Options.
- Disable the policy User Account Control: Run all administrators in Admin Approval Mode.
Source:
https://4sysops.com/archives/access-denied-to-administrative-admin-shares-in-windows-8/
Thursday, April 4, 2019 7:52 PM | 1 vote
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?
Signed,
Afflicted by same troublesome environment....
Saturday, April 20, 2019 7:27 PM
This worked for me. Thank you!
Friday, June 7, 2019 4:31 AM
This worked for me for an at home workgroup. Thank you.
Wednesday, September 25, 2019 9:41 PM
Hello,
Have you found a solution to this issue?
I have discovered that there are multiple instances of the LocalAccountTokenFilterPolicy which can be found by selecting F3 after modifying the first and subsequent keys. However It appears HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system
LocalAccountTokenFilterPolicy still resets to 0 on resart. Have you cracked this nut? Thanks, NorikiX
Sunday, December 1, 2019 5:41 AM
Thank you, this worked to fix a similar issue, but with a home network/workgroup, and win ver 1903.
When inputting credentials for local admin account (for \computername\c$) it would not accept the password although it was most certainly the correct password, even tried the built in admin account with no luck.
Monday, December 23, 2019 7:32 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.
- Launch Control Panel, type admin… in the search box, and then click Administrative Tools.
- Open the Local Security Policy application.
- Navigate to Local Policies > Security Options.
- Disable the policy User Account Control: Run all administrators in Admin Approval Mode.
Source:
https://4sysops.com/archives/access-denied-to-administrative-admin-shares-in-windows-8/
Thanks Alexey, I came to say this worked for me after trying my hand at all the other attempts in this thread to no avail.