Read the whole series

The first two parts of my series on using permissions in Windows 2000 covered how to set up and troubleshoot file-sharing permissions and NTFS permissions. Before reading on, you might want to review these Daily Drill Downs: “File-sharing permissions in Windows 2000” and “NTFS permissions in Windows 2000.”

In this concluding Daily Feature, I cover the tricky subject of what happens when you combine permissions. After reading this series, you should be able to set up and troubleshoot permission on your network and client more quickly.

Rules for combining permissions
Understanding how permissions interact is not difficult, if you stick with these rules.

Same permission type (either sharing or NTFS)
When working within a certain permission type (sharing or NTFS), permissions are cumulative. The most lenient setting wins for a particular user or group. Deny always overrides Allow and negates any permission with which it conflicts.

Mixing sharing and NTFS permissions
When there’s a difference between the sharing permission and the NTFS permission, the most restrictive setting wins.

Permissions across groups
Permissions are not cumulative across groups; each group’s permission is calculated separately. For example, if a user is a member of Group A that has Full Control sharing permission but no NTFS permission for an object and of Group B that has Full Control NTFS permission but no sharing permission for the object, that user has no permission for the object.

Let’s look at some examples. Let’s say that on Tim’s PC, there is a folder called FOLDER-A containing a file called PRIVATE.DOC. Tim has shared FOLDER-A with the Marketing group with Change permission and with the Everyone group with Read permission. In the NTFS permissions for the folder, he has allowed for the Marketing group to have only Read access. He has removed the default permissions to the folder for the Everyone group.

If Sarah from Marketing accesses PRIVATE.DOC, will she be able to make changes to it? The Marketing group has Change (for Sharing) and Read (for NTFS), with a net result of Read. The Everyone group has Read (for Sharing) and None (for NTFS), with a net result of None. So Sarah’s permissions are the least restrictive of Read and None—in other words, Read. So no, she cannot make changes.

  Sharing permission NTFS permission Net permission
Marketing group Change Read Read
Everyone group Read None None
Cumulative permission     Read

Now, suppose Tim adds another group to his list of NTFS permissions: Managers. He gives the Managers group Modify access to FOLDER-A. If Sarah is a member of the Managers group, will she now be able to make changes to PRIVATE.DOC? The answer is still no, because even though permissions are cumulative within a type, they are calculated as a whole on each group. As you can see below, the new Managers group has no net permission to the folder because it has no Sharing permission, so it doesn’t help Sarah to be able to modify the file.

  Sharing Permission NTFS Permission Net Permission
Marketing group Change Read Read
Managers group None Modify None
Everyone group Read None None
Cumulative permission     Read


Hint: Permission changes don’t take effect until the end user logs off and back on

By the way, after Tim changes the permissions, Sarah must log off and back on again or close the network connection to Tim’s PC and reopen it in order for his permission changes to take effect on Sarah’s end.

If Tim wanted to make sure Sarah had the ability to modify the file, he could :

  • Give the Marketing group Modify (or better) permission under NTFS permissions.
  • Give the Managers group Change permission under sharing permissions.

Tim takes the first option and changes the Marketing group’s NTFS permission to Modify. Now the chart looks like this:

  Sharing Permission NTFS Permission Net Permission
Marketing group Change Modify Change/Modify
Managers group None Modify None
Everyone group Read None None
Cumulative permission     Change/Modify

Sharing and NTFS permissions use two different terms, Change and Modify, but both allow Sarah to make edits to the file.

Now, suppose Tim uses the NTFS special permissions to deny the Managers group the Write permission. Will Sarah be able to edit the file? No, because the Deny option settings override any Allow settings. Even though the Marketing group still has the rights to edit the file, Sarah is also a member of the Managers group which is specifically denied access.

  Sharing Permission NTFS Permission Net Permission
Marketing group Change Modify Change/Modify
Managers group None Deny Write Deny Write
Everyone group Read None None
Cumulative permission     Deny Write

If Tim wanted Sarah to be able to change the file but nobody else from the Managers group, he could either remove Sarah from that group or create a separate group containing everyone from Managers except Sarah and deny that group the Write access instead of denying the Managers group.

The best way to get more confident in your understanding of permissions is to play around with them. Try re-creating the preceding scenario on two client PCs on your network and then experimenting with more “what if” scenarios. For example, what if:

  • Tim turns off Deny Write for Managers and simply deselects the Allow checkbox for the Managers group? Can Sarah then edit the file?
  • Sarah then tries to delete the file PRIVATE.DOC? Can she do it with her current permissions?
  • Tim removes all permissions from the folder? Can he still read and modify the file himself?
  • Sarah creates a subfolder within FOLDER-A on Tim’s PC? Can Tim delete it?

In this conclusion of my three-part series on Windows 2000 permissions, you learned what the rules are when different sets of permissions interact. You also gained some practice in determining net permissions when NTFS and sharing permissions conflict for a user in multiple groups. You now have my permission to set up your network and client machines for the most robust security obtainable in a Windows environment.

Editorial disclaimer

The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.