Solved

Can't seem to restrict network access to a domain Win8-Pro PC folder from domain users on Win7 Pro PCs

Posted on 2013-11-22
13
269 Views
Last Modified: 2014-07-22
Hi everyone -

Here's my problem:


I have a Windows 8 Professional x64 PC on my 2003 Active Directory domain.

I have a folder on that Windows-8 Professional x64 PC that I need to restrict access/block for certain network domain users that are on other PCs on the LAN.  That folder is on the "G" drive of the Win8 PC in question.

The users are using Windows 7 Pro PCs on the same 2003 A/D domain.  The only A/D group they are members of is the default "Domain Users", but they are Local Administrators on their own Win7 PCs

I originally had the folder set as a share; I removed security inheritance from above it and Explicitly added the individual users I want to block, I selected "Full Control", then "Deny" on both the "Share" tab and the "Permissions" tab for the share.

These users, that should have been blocked, were still able to browse the network and access the share.

I stopped sharing the folder, making the only way to get to it to be by navigating to \\<Win8-Computer-name>\G$\<folder-name>.  I then similarly Explicitly added those users to the folder permissions by  selecting "Full Control", then "Deny" on the "Permissions" tab for the folder.  I also Explicitly added those users to the "G$" permissions by  selecting "Full Control", then "Deny" on the "Permissions" tab for G$.

The target users were STILL able to access the folder simply by navigating to \\<Win8-Computer-name>\G$\<folder-name>, even though they should still have been blocked.

This is my first encounter working with file access permissions relative to Win8 and Win7 PCs on a 2003 A/D domain (nothing but WinXP PCs have been on the domain up to this point)

I doubt that it matters, but the "G" drive on the Win8 PC is not an internal hard drive.  It is an iSCSI NAS box made operational and available specifically to the Win8 PC by the usual iSCSI Initiator on the Win8 PC.

Is this something new /peculiar with Win8 and Win7 PCs as to how they interact with network and file/folder security????  I've been working with networks and IT for a very long time and have never seen a situation where EXPLICITLY applied Deny-Access settings have had absolutely NO effect in blocking users.

What the heck am I missing?

Thanks in advance for any and all help.
0
Comment
Question by:aiico
  • 7
  • 6
13 Comments
 
LVL 53

Expert Comment

by:McKnife
ID: 39669815
First of all: your users are admins on their own pcs, not admins on the remote computer, so g$ will not be accessible. It is accessible, you say? Then they are admins on the remote computer also.
About the weird denied-but-nevertheless...-thing: please read the conclusion in my own thread: http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/2003_Server/Q_22108365.html
0
 

Author Comment

by:aiico
ID: 39669944
Since we all sometimes miss something right in front of our face, I went back and double-checked the admins on the Windows-8 PC,  The users I intend to block are emphatically NOT admins of that machine.  The only local admins on that machine are specifically my own A/D account, and the "Domain Admins" security group in A/D. and (of course) the local machine administrator account.  There are no other users in the local admin group, and even explicitly listed even as users at all.

Understandably, the administrative share for the G-drive, "G$" should only be accessible by admins, non-admins are still accessing it.  I did just notice, however, that the group "everyone" is apparently assigned (by default by Windows 8 I'm guessing, as I would never assign such a setting) "read & execute" permission to G$ !!!
0
 
LVL 53

Expert Comment

by:McKnife
ID: 39669965
Ok, but have you ever seen anyone being able to access an administrative $-share without being admin at the remote machine? No, because these share permissions of the builtin administrative shares even cannot be changed. So my guess is you made all of them domain admins. Please check the domain admins group and see whether any group is nested there in that might house the user(s) in question or the users themselves.

At least I can say this has nothing to do with the type of OS you use.
0
 

Author Comment

by:aiico
ID: 39670011
I agree with you about non-admins accessing the root $ admin share, so that's why this is confusing.

To be a little more carefully specific, I should have said that I noticed that when looking at the properties of the "G" drive, as shown in Windows file explorer, on the Security tab, drilling into the Advanced Security Settings, the "everyone" group seems to be granted by default "read & execute" permissions at that level.  I definitely did not assign that myself.  (I did misspeak when I said it was on the G$ admin share.)

In my Domain Admins group, the only two user accounts in there are my own and the default built-in "administrator" account, and there are no other groups nested inside it.

I removed the "everyone" group from the advanced security settings for the G: drive and users are still able to access and traverse G$.  Doesn't make any sense.
0
 
LVL 53

Expert Comment

by:McKnife
ID: 39670054
Your last sentence: ...g$... again the $-share? Or is there a g-share as well and we are talking about a share named "g"? Please set that straight, first.
Then please tell me if you understand what my other thread was about and how it turned out.
0
 

Author Comment

by:aiico
ID: 39670111
To clarify:  

First, in the "Properties-->Security-->Advanced" settings of the G-Drive, when viewed in windows explorer, there WAS the "everyone" group in there by default with Read & Execute access rights (screenshot image named "G1.jpg" uploaded)

Second, A non-admin user on another PC can navigate to and thru G$ from their PC (screenshot image, named G-1.jpg attached)

I hope this clarifies what I am very badly explaining.
G1.jpg
G-1.jpg
0
Complete VMware vSphere® ESX(i) & Hyper-V Backup

Capture your entire system, including the host, with patented disk imaging integrated with VMware VADP / Microsoft VSS and RCT. RTOs is as low as 15 seconds with Acronis Active Restore™. You can enjoy unlimited P2V/V2V migrations from any source (even from a different hypervisor)

 

Author Comment

by:aiico
ID: 39670118
I'm re-reading your other thread now again...
0
 
LVL 53

Accepted Solution

by:
McKnife earned 500 total points
ID: 39670150
Ok, so it's the g$ share. That should under no circumstances be accessible at all by non-admins. So the only possible reason is, that on your win7 box, you are using saved credentials.
Please look at the saved credentials you have, delete them, log your user off and on again and retry.
0
 

Author Comment

by:aiico
ID: 39670158
I did log the user on and off once, but I will check the saved creds.  Good thought.
0
 

Author Comment

by:aiico
ID: 39670319
McKnife -

You rock.  Thanks for the second pair of mental eyes on this.  It was Saved Creds on the user's Win7 PC.  One of my network admins had used their own creds there a while ago to connect to the network share to make it easier on themselves at the time instead of setting up proper access for the user.

Always turns out to be something basic :-)

Thanks again.
0
 
LVL 53

Expert Comment

by:McKnife
ID: 39670359
You're welcome.

> Always turns out to be something basic :-)
Yes, mostly. Also think about changing the support strategy: your network admin has obviously used a domain admin account to service a workstation (or at least an account that is in the admin group of other workstations as well). This is dangerous, especially if the users are local admins. They could use hacker tools like mimikatz and don't even need to crack anything... they get your domain admin pw in plaintext instantly - even after the network admin has logged off and cleared eventually saved creds. [Unless you already run win 8.1 which has changed that game a bit].
0
 

Author Comment

by:aiico
ID: 39670383
Thanks for that tip.  I'd think using the user's PC local admin account would be an improved strategy over using domain admin logons.
0
 
LVL 53

Expert Comment

by:McKnife
ID: 40212855
0

Featured Post

Highfive + Dolby Voice = No More Audio Complaints!

Poor audio quality is one of the top reasons people don’t use video conferencing. Get the crispest, clearest audio powered by Dolby Voice in every meeting. Highfive and Dolby Voice deliver the best video conferencing and audio experience for every meeting and every room.

Join & Write a Comment

It’s 2016. Password authentication should be dead — or at least close to dying. But, unfortunately, it has not traversed Quagga stage yet. Using password authentication is like laundering hotel guest linens with a washboard — it’s Passé.
Read about achieving the basic levels of HRIS security in the workplace.
This video shows how to remove a single email address from the Outlook 2010 Auto Suggestion memory. NOTE: For Outlook 2016 and 2013 perform the exact same steps. Open a new email: Click the New email button in Outlook. Start typing the address: …
This video demonstrates how to create an example email signature rule for a department in a company using CodeTwo Exchange Rules. The signature will be inserted beneath users' latest emails in conversations and will be displayed in users' Sent Items…

759 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

18 Experts available now in Live!

Get 1:1 Help Now