Windows networking not respecting permissions

The Lurker

The Lurker

Fully [H]
Joined
Jul 1, 2001
Messages
21,264
Up until now I have been using homegroups to share folders located from my server to several pc's on my home network. I realized that some folders contain a lot of information and with one wrong key press someone could inadvertently delete a lot of valuable data. Furthermore, I need to be able to quickly give and take away write rights in the event I need to drop something from a networked machine into a folder which is read only normally. So in the interest of protecting some folders I decided to turn off homegroups and use password based sharing. I created several user accounts on the server, shared the folders and added the users to the permissions with their respective rights to those folders. I went to the other machines, mapped the drives, it prompted me for login info which was accepted.

Now.

Those folders with users that have read only rights are properly read only when accessed over the network. However, some folders which were marked read\write are also read only. I cant figure out why windows is not respecting the permissions I set to a particular folder. I also have an entire drive shared in the same manner and it too does not respond to read/write permissions for users that have it.

When a drive is shared, does the permission set at the drive level by user apply to each folder on that drive as well? Is there a delay in permission changes taking effect when either granting or taking away rights?

Hope you guys can help, thanks.
 
If you want to have separate permissions on a folder and not inherit from its parent, you will need to deselect the top check box. Then set your permissions you want. If you want to propagate those permissions to all child objects, check the bottom checkbox afterwards.

ocOwFRf.png


For basic workgroup sharing, you will need to have the same User accounts on the file hosting machine as you do on your machines that you want to access from, unless you want to continuously enter in credentials.

Also, something you will need to be mindful is that the share permissions are not the same as your NTFS permissions. You will need to ensure these aren't conflicting. If you have the share as Everyone read and write, but NTFS security that says <hostname>\Users Read Only, you will run into a problem.
 
Where do I find those options?

Currently. On the disk as an example. The security box has the following entered "Authenticated Users, SYSTEM, Administrators, Users". The "Users" and "Authenticated Users" group have only read & execute, list and read rights. However, the user I had created is part of the Users group and was given read/write ability through the sharing permissions.

Can I safely assume that security permissions over-ride the sharing permissions? If so, that may be the issue.
 
Shares need both the Share and Security permissions to be set correctly for it to work.

Generally I just set the share to Everyone-Full and manage permissions in Security. Sure, it's not best practice....
 
By default Everyone gets read access to anything shared. This allows anyone to at least be able to browse it and view it.

Whether you can view files/folders inside is up to the NTFS security permissions.

If you right click a folder and go to "Properties" on the security tab this is the modification of the NTFS security.

Typically, yes, security permissions will override share permissions.

Unless you don't want anyone to see your porn in "\\hostname\schoolworklol\PORN", and \\hostname\schoolworklol\ is your share, you would remove "Everyone" from the share permissions and only give your user account read access to it.

If you wanted to have everyone be able to see your porn directory, but no one be able to open the porn directory then you would remove "users" group on the security tab and any other group that encompasses the users you are trying to deny.

EDIT: Do note that if you deny read permission to the "\\hostname\schoolworklol" but allow Read, Write, or Read and Write access to "\\hostname\schoolworklol\porn\" they will be able to browse to that. That is why inheritable permissions are important.

This is also why it's important to set permissions on a folder before copying a large amount of data to it so the copied folder structure will inherit the permissions and you don't have to wait forever for it to set new security after the fact.
 
Innocence said:
Shares need both the Share and Security permissions to be set correctly for it to work.

Generally I just set the share to Everyone-Full and manage permissions in Security. Sure, it's not best practice....
Click to expand...

I don't think anyone will hold your feet to the fire for this in a home setup, but a business... :eek:
 
You guys are the best, thanks to your information I was finally able to set up the permissions to work properly. I had security mismatching the share and it was over-riding everything I was setting. I have decided to manage the permissions at the folder level using the share instead of security.
 
Last edited:
Cmustang87 said:
I don't think anyone will hold your feet to the fire for this in a home setup, but a business... :eek:
Click to expand...

Actually, it's just the opposite. Share-level permissions are generally not needed and are usually not desired in a business environment. File-level permissions and an open share level is actually the correct setup for the vast majority of use cases.

I've been using that configuration since NT 3.51 with hundreds of users with zero issues.:p

As a best practice, it is most efficient to configure share permissions with Authenticated Users having Full Control access. Then, the NTFS permissions should configure each group with standard permissions.

http://www.windowsecurity.com/artic...ication_and_encryption/Share-Permissions.html
 
Last edited:
Glad it ended up working out for you, The Lurker.

Thank you squishy for that article, I'll give that a read.
 
Last edited:
Innocence said:
Shares need both the Share and Security permissions to be set correctly for it to work.

Generally I just set the share to Everyone-Full and manage permissions in Security. Sure, it's not best practice....
Click to expand...

Cmustang87 said:
I don't think anyone will hold your feet to the fire for this in a home setup, but a business... :eek:
Click to expand...

Ditto what Squishy said. As far as I've ever seen, this is best practice and it's how I set up shares.

I think you're more likely to give unintended or incorrect access levels when you're managing permissions in two places.
 
squishy said:
Actually, it's just the opposite. Share-level permissions are generally not needed and are usually not desired in a business environment. File-level permissions and an open share level is actually the correct setup for the vast majority of use cases.

I've been using that configuration since NT 3.51 with hundreds of users with zero issues.:p

As a best practice, it is most efficient to configure share permissions with Authenticated Users having Full Control access. Then, the NTFS permissions should configure each group with standard permissions.

http://www.windowsecurity.com/artic...ication_and_encryption/Share-Permissions.html
Click to expand...

This may actually make my life even easier and sharing a little cleaner. Right now I have a a whole bunch of shared folders. Instead I can share the whole drive with read for everyone at the share level and write permissions at the security level to a select few.

Question in reference to the above quote. Does it imply that "Authenticated Users" should not be present at the security level since they are on the share level?
 
If you add folders to a folder you have already set NTFS permissions those folders will not inherit the top folders permissions by default, you have to manually do it.
 
squishy said:
As a best practice, it is most efficient to configure share permissions with Authenticated Users having Full Control access...
http://www.windowsecurity.com/artic...ication_and_encryption/Share-Permissions.html
Click to expand...


:eek: :eek: :eek:

Umm... no. Best practice is to block everything and selectively allow. Remember that Share permissions limit file-level permissions. For each share XYZ you probably want 4 groups:

S_XYZ_Full
S_XYZ_Change
S_XYZ_Read
S_XYZ_Deny

Of course, this is for organisations with thousands of users. It's overkill for a small office.
 
Quartz-1 said:
:eek: :eek: :eek:

Umm... no. Best practice is to block everything and selectively allow. Remember that Share permissions limit file-level permissions. For each share XYZ you probably want 4 groups:

S_XYZ_Full
S_XYZ_Change
S_XYZ_Read
S_XYZ_Deny

Of course, this is for organisations with thousands of users. It's overkill for a small office.
Click to expand...
By working only with NTFS file permissions, we're still blocking everything and selectively allowing, just at the file level only.

Are you applying these groups to the share and the NTFS permissions? Because share permissions alone they don't limit file-level permissions at all - they limit share-level permissions (and file access when using the share) . If you don't disallow log-on-locally, or it's a terminal server, they're still getting access to those files.

Also : http://technet.microsoft.com/en-us/library/cc754178.aspx

Microsoft suggests using file share permissions when dealing with "FAT32 or a file system other than NTFS".

Administering ONLY share level permissions is a really REALLY bad practice.
 
The Lurker said:
Instead I can share the whole drive with read for everyone at the share level and write permissions at the security level to a select few.
Click to expand...

If you only have "everyone - read" at the share level, nobody will be able to write no matter what you do at the NTFS (security) level.
 
The Lurker said:
This may actually make my life even easier and sharing a little cleaner. Right now I have a a whole bunch of shared folders. Instead I can share the whole drive with read for everyone at the share level and write permissions at the security level to a select few.

Question in reference to the above quote. Does it imply that "Authenticated Users" should not be present at the security level since they are on the share level?
Click to expand...

When combing SHARE and FILE level permissions, you end up with whatever is more restrictive. It's easier just to not combine the two at all (in practice).

What you want on the SHARE itself is "Authenticated Users" "Full Control".

What you want on the FILE permissions is whatever you actually want people to have access too and at what level. Think of the SHARE permissions as an irrelevant pass-through and the FILE permissions as exactly what the user's effective permissions will be. There's no combining or confusion. Whatever is set at the file level permissions is exactly what you're going to get (unlike a box of chocolates).
 
Thanks for that clarification.

Could you please let me know what I should do regarding the second line in the post you quoted.
 
Innocence said:
By working only with NTFS file permissions, we're still blocking everything and selectively allowing, just at the file level only.

Are you applying these groups to the share and the NTFS permissions?
Click to expand...

No, just the share level; file level permissions are a separate level. Basically you have three types of groups: groups of which users are members (e.g. U_ABC), groups which apply to shares (e.g. S_XYZ_Full), and groups which apply to files and folders (e.g. F_1234_Read). You put users in the first group, and user groups in the second two groups. This makes management vastly easier.
 
The Lurker said:
Thanks for that clarification.

Could you please let me know what I should do regarding the second line in the post you quoted.
Click to expand...

Having that just implies that pretty much every account can get into the share. Just ignore it when it comes to file level permissions. What it's saying is basically "let anyone that has authenticated INTO the share". You then restrict them at the file level after that. See what I mean? You're, in essence, opening up the share to "everyone" (it's not, but this is another discussion) but then restricting them once they actually go in and try to read/write/delete a file.

Using authenticated users on the share just keeps certain accounts out of the share, which generally shouldn't have access at all, like guest, or an IIS web server (see http://blog.varonis.com/the-difference-between-everyone-and-authenticated-users/).

Authenticated users doesn't need to be on the file level permissions unless that's something you specifically want. Generally, people would use more restrictive groups on the actual file permissions (like marketing, engineering, etc.) to give them what they want.

Does that make sense?
 
Completely and Quartz brought up something I also didnt know; groups of groups.
 
Quartz-1 said:
No, just the share level; file level permissions are a separate level. Basically you have three types of groups: groups of which users are members (e.g. U_ABC), groups which apply to shares (e.g. S_XYZ_Full), and groups which apply to files and folders (e.g. F_1234_Read). You put users in the first group, and user groups in the second two groups. This makes management vastly easier.
Click to expand...
I understand permissions by groups - what I don't understand is why you would choose to manage permissions on ONLY the share and not with the NTFS file permissions. :confused:

It's not a file server running Windows 95 is it? At least tell me it's 95c.
 
Innocence said:
I understand permissions by groups - what I don't understand is why you would choose to manage permissions on ONLY the share and not with the NTFS file permissions. :confused:

It's not a file server running Windows 95 is it? At least tell me it's 95c.
Click to expand...

I think you mis-read. He manages the permissions at the file level only while setting the share level to full access.
 
Last edited:
You must log in or register to reply here.
Back
Top