This was my initial answer:
This really is not default behaviour, so you have something odd going
on. Either the default permissions have been changed (which IIRC isn't
easy with conventional weaponry) or they are members of administrators
(I know you said they are not but this might be an indirect
membership), power users, or backup operators. Possibly also Print
Operators.
I appreciate that isn't what you want to hear given how well you've
emphasised that users aren't admins, but I've looked into this kind of
thing dozens for times for people and it always turns out to be
something like "Oh, I guess my colleague added 'all_staff' to the
'administrators' group one day because the CEO was screaming at him
about not being able to RDP into the server from home".
And it's very wrong, but it deserves to stay as an illustration of a long-held belief not being tested often enough. I believe this is a change in behaviour from earlier versions of Windows, but I'm not sure when the change would have happened.
I've tested with Windows 10 Pro and Enterprise just in case they have different default settings, and Users can browse the local administrative shares and your options for controlling this seem rather limited I'm afraid. You can turn off Administrative shares as mdpc suggests (see https://support.microsoft.com/en-gb/help/954422/how-to-remove-administrative-shares-in-windows-server-2008) for a Microsoft source for this) but it may interfere with how various admin tools work on these computers (e.g. might prevent auto-deploying agents from deploying/updating) so I really would recommend against it.
Hiding the drive in the way you describe via GPO is nothing to do with permissions to the drive or share, by the way. This simply triggers a flag in Windows to hide certain drive letters. It's not reliable or robust and I've seen lots of admins in education, for example, go crazy trying to look this down against anything students can do but it is futile.
However... While users can access their local administrative share, they cannot access shares on other PCs, and their access via the share still only grants them the same access they would 'normally' have. Therefore, users cannot 'hack' the system this way; they cannot change things they don't already have the permissions to change.
You can and should lock down the root of the c:\ drive however. Here's some instructions for doing that:
- Go to your DC, Open ADUC, create a security group ('Lock down c
drive' say) for users who will not be able to save files to root
drive.
- Open GPMC, create a GPO which links to your target machines.
- Edit the policy and open [Computer Configuration | Policies |
Windows Settings | Security Settings | File System ] Right click
"File System", choose "Add File..." and select the "C:" drive,
enter.
- In the security page, click "Advanced" button. Add the
security group 'Lock down c drive'.
- With that group highlighted, click Advanced. In the Advanced Security Settings window, ensure that the correct group is still selected and click Edit.
- Change Type to 'Deny' and Applies To to 'This folder only'.
- Click the 'Show Basic permissions' / 'Show Advanced Permissions' toggle so you can see advanced permissions.
- Tick the Deny permission for the following items ONLY: 'Create files /Write data' and 'Create folders / Append data'.
- Click OK to exit the permissions editor, then click Ok again.
- In the warning window for Deny permissions, click Yes.
- Set the security policy setting to 'Configure this file or folder then', and choose 'Propagate inheritable permissions to all subfolders and files' (this is where you double-check that you got step 6 absolutely right before going live with this setting).
Give the GPO time to replicate and apply (gpupdate /force can help here if you're in a hurry) and you should now find that users can't create files in the root of the c drive. They should only really have permission to their own folder inside \users at this point.
