More Windows Filesharing Woes

Question

This has been bugging me now. I'm in the process of converting a standalone fileserver that was not joined to our domain into using AD Groups\Users for the file shares. This fileserver used to use local machine accounts for the Share permissions. I've gotten the fileserver joined to the domain so now I want to replace the Share permissions with the correct ones from AD.

Maybe I need this explained to me but for some reason I cannot get it to work. For example, I have a shared folder:

\\fileserver\jsmith

On this folder the Share permissions are set so that the AD user John Smith has Full Control. The NTFS permissions (That's what's in the Security Tab right?) are set to this:

FILESERVER\Adminstrators -- Full Control
CREATOR OWNER -- Special Permissions is checked and greyed out
SYSTEM -- Full Control though it's greyed out (as well as the other check boxes in the Allow column)
FILESERVER\Users -- Read & Execute, List Folder Contents, and Read (all greyed out)

From my understanding (and maybe I'm wrong) the user John Smith should be able to access \\filserver\jsmith and be able to open any files and folders there as well as create files and folders.

However, this is not the case. John Smith gets an Access Denied message when trying to access this share.

EDIT: To clarify, when John Smith types in the UNC path to the share (\\fileserver\jsmith) into Windows Explorer and hits Enter he gets the Access Denied message.

Maybe I'm not understanding this whole thing. So, what would be the "proper" way to accomplish what I want: An AD user or group to have Read & Write access to a shared folder.

Answer 1

The "DOMAIN\JSmith" user should not be getting "Access Denied" upon trying access the share, but should be getting "Access Denied" when trying to create or modify files hosted there. Can you clarify what you mean by "John Smith gets an Access Denied message when trying to access this share." with my prior statement in mind?

In general, "Share Permissions" should always be set to "Everyone / Full Control". They're a brain-damaged misfeature from back in the days when people might share out folders hosted on non-NTFS volumes. (Anybody wanna argue about it? Heh heh...)

"Share Permissions" are enforced by the "Server" service. If users are able to access files via some other method (a "Share" higher up in the filesystem with different "Share Permissions", files exported via IIS with some other protocol, etc) then the "Share Permissions" won't apply. Specify your permissions in the NTFS permissions, and then no matter how users access the files the NTFS driver will enforce the desired permissions.

For academic purposes, I'll explain how "Share Permissions" work (but I'd still encourage you to always set them to "Everyone / Full Control"): The "Server" service (which handles exporting "Shared" folders via the SMB protocol) verifies that the underlying NTFS allows the user's attempted access (read, write, etc) and then checks the user's attempted access against the "Share Permissions". If either permission doesn't allow the desired access then the access attempt fails. Setting "DOMAIN\JSmith" with "Full Control" permission at the "Share Permissions" doesn't change the underying NTFS permission. At the filesystem level, "DOMAIN\JSmith", a member of the "DOMAIN\Domain Users" group, has Read, Execute, and List Folder Contents permission by way of the default nesting of "DOMAIN\Domain Users" into the "FILESERVER\Users" group when you joined the domain.

You shouldn't ever name individual users in permissions except for folders that are specifically created for that user only, such as roaming user profile folders or home directories. Since this share is named "JSmith" I'm going to guess it's a home directory. Add "DOMAIN\JSmith" with either "Modify" or "Full Control" (depending on whether you want JSmith to be able to modify the permissions on the folder and subfolders or not-- "Full Control" will give him that right) to the folder's ACL and you should be good to go.

If a shared folder is for some other purpose (i.e. for a "job role" or sharing between users) the Right Way^(tm) to apply permission is to create a group that describes the role associated with the access (like, say, "Purchasing Department"), grant permission to the NTFS folder for the resource to the group (like, say, "Modify"), and place the appropriate users into that group.

When a job role changes or turnover occurs you need only put the "new person" into the proper groups and their access to resources is assured. If you'd named individual users in permissions then the only way to insure access for a new user would be to visit each resource and add new permissions (possibly removing the old permission if a job role changed). If you don't keep good documentation of where you applied various permissions to individual users then you'll never be able to create a new user with the "same rights" as an existing user w/o a massive investigation effort on all your resources.

Even if a group is going to have a single member, create a group anyway. You'll thank yourself later when you have to assign someone else to the group.

Edit:

An Access Control List (ACL) is the list of Access Control Entries (ACEs) applied to a resource. The ACL is what you're seeing on both the "Security" tab of a Properties sheet, and in the "Advanced" dialog. Each line of the ACL is an ACE. (I thought I'd bring "ACE" into it, just in case you see it in documentation somewhere and wonder what it means...)

You're seeing the same thing in the "Security" tab and in the "Advanced" dialog, just presented differently (with more detail in the "Advanced" dialog).

I'm having trouble coming up w/ why you might be seeing an "Access Denied" upon accessing the share as you describe. With JSmith logged-on to his client computer with his domain account, and the FILESERVER computer joined to the domain, you should not be getting an "Access Denied". Are you certain JSmith is logged-on with his domain account on the client computer?

Answer 2

You actually get dinged for the most restrictive of the security policies in question. Thus, if you have a share that has read-only permissions on a folder with read-write, you get read-only. Similarly, if you have a share with read-write permissions but the folder is read-only, you get read-only.

I'm not saying it's the right way to do things, but I regularly see shares with Everyone RW, with all security on the NTFS permissions of the folder being shared.

Answer 3

Do the necessary user accounts have, at minimum, Traverse Directory if the shares aren't in the root of the drive?

For example: If you have a folder called D:\Users and then the folders in there, then those accounts need to be able to traverse D:\ and D:\Users, otherwise they will receive an access denied.

Answer 4

Update: removed incorrect statements after feedback from Evan.

When you're working with shared folders you need to think about two sets of permissions:

First, the permissions on the share itself. These are like the bouncer at the nightclub door. If the connecting user doesn't have permissions at this level, he's going to be denied access no matter what the permissions are on the folder itself.

Second, you have the permissions on the folder. If the user has enough access to get through the share but not access to the folder, he'll be denied. Folders do not, in any way, inherit permissions from the share.

At both levels, you can use local or domain level accounts. On a typical file server, you won't have any local accounts other than those required by Windows.

If you're setting up this share for multiple users, you'll want to grant permissions to a security group that contains all of the users that will need access. Then you use NTFS level permissions on the underlying file system for fine-grained control over who can do what.

Answer 5

What you need to do, rather than setting up a separate share for each user, is to set up a single top-level share called "Users". Add sufficient permissions to this at Sharing level so that all of your Domain users can access it. Then under this share, create a subdirectory for each user. Don't share this, just set the required NTFS permissions on it. Users will then access it via \\servername\users\username.