TechTutorials - Free Computer Tutorials  







NTFS vs Share Permissions 
 


Added: 08/10/2002, Hits: 6,811, Rating: 0, Comments: 0, Votes: 0
Add To Favorites | Comment on this article
By Brian Talbert

Question: I'm often confused by NTFS and SHARE permissions. How can I tell when each will be applied? I've heard suggestions about LEAST RESTRICTIVE and MOST RESTRICTIVE of the two but I simply get confused. My Brain Hurts! Can you please explain?

Short Answer:

The combined permissions of NTFS will be applied to a user requesting access unless NO ACCESS is specified in which case the user is denied.

The combined permission of a SHARE will be applied to a user requesting access unless NO ACCESS is specified in which case the user is denied.

When access an NTFS file through a SHARE, the most restrictive BETWEEN THE TWO OBJECTS will be in effect.

Long Answer:

Warning: May cause your brain to hurt even more ... study it, sleep on it. It will make sense... eventually!

It helps to think about how you obtain access to an object within NT.

The first component to be familiar with is the ACCESS TOKEN. It is built during the logon process and essentially contains YOUR user SID as well as the SIDs for any groups you belong to. All processes that you start get a copy of your access token and it is the access token that is used for object permission comparisons ... we'll see this in second.

All objects in NT have a "Security Descriptor" associated with them. The Security Descriptor contains the object owner and the Access Control Lists.

There are two Access Control Lists (ACL), the System ACL and the Discretionary ACL. The System ACL contains information regarding auditing and the Discretionary ACL contains the actual permissions of users and groups. ... It is the Discretionary ACL that we are interested in.

The Discretionary ACL contains Access Control Entries (ACEs). Each ACE associates the SID (unique identifier) of a user or group with a particular permission. For instance, an ACE may specify "Joe" having NO ACCESS, or Mary having "READ ACCESS", or the group ACCOUNTING with "Full Control".

Now, all ACEs that specify NO ACCESS are listed first ... this will become important.

When a user attempts to access an object (a resource), a call is made to the NT OBJECT MANAGER. The NT OBJECT MANAGER is informed of the type of access and the permissions requested (e.g. OPEN WITH READ ACCESS). The SECURITY REFERENCE MONITOR then does a comparison between the ACCESS TOKEN and the object's SECURITY DESCRIPTOR.

It essentially starts reading the ACEs within the Discretionary ACL. Remember that the ACE contains a permission and associated SIDs that get those permissions.

Remember that I mentioned that NO ACCESS is always listed first in the ACL? Well, if any NO ACCESS is found in the ACL with a SID that matches a SID in the users ACCESS TOKEN then permission is denied an all further process of the ACL is halted. This is an important point, not only because it means that NO ACCESS overrides any other setting, but also because it implies that otherwise the ENTIRE ACL is parsed. And this is exactly the case. So if a user has multiple permissions, for instance an individual user permission as well as a group permission, none of which are NO ACCESS, then the permissions are COMBINED.

OK ... now remember that everything in NT is represented by an object. This process of checking permissions is the same for all objects, including NTFS objects and file SHARE objects.

So, when accessing an NTFS file, the combined permissions will be in effect, unless of course a NO ACCESS has been found. This is irregardless of your method of accessing that NTFS object. It makes no difference if you are doing it from the local console or from a remote machine.

Further, the combined permission will be in effect when accessing a SHARE object ... again, unless NO ACCESS was specified. This also is irregardless of you method of access. Typically you only access SHARE objects from across the network ... but you certainly can access local resources through their associated SHARE objects, just as if you did remotely.

OK ... so far we know that when accessing an object, that a NO ACCESS permission denies all, but otherwise permission are combined. We also know that NTFS files and and folders are objects and SHARES are objects. And that HOW we access those objects doesn't really matter.

Now ... how about when you access an NTFS object THROUGH a SHARE object. This is fairly straight forward. Each is it's OWN object and therefore permissions are checked
INDEPENDENTLY!

This means that before NTFS permissions are checked SHARED permissions are checked. The two are not taken into consideration together. And all access to the NTFS object goes THROUGH the SHARED object. Therefore, if I want to READ an NTFS file through a SHARE I must have READ access to both the SHARE and then further to the NTFS file itself. Likewise to WRITE.

For instance, if I want to WRITE to an NTFS file ... I must first send the request to the SHARE. If the SHARE does not permit it then I will be denied ... even if the underlying NTFS file specifies that I can.

In other words, THE MOST RESTRICTIVE OF NTFS AND SHARE permissions will be in effect.

In summary:

The combined permissions of NTFS will be applied to a user requesting access unless NO ACCESS is specified in which case the user is denied. The combined permission of a SHARE will be applied to a user requesting access unless NO ACCESS is specified in which case the user is denied. When access an NTFS file through a SHARE, the most restrictive BETWEEN THE TWO OBJECTS will be in effect.





Comments (0)

Be the first to comment on this article


Related Items








7 Seconds Resources, Inc.




IT Showcase