Problem solve Get help with specific problems with your technologies, process and projects.

Checking access permissions with Server Share Check

Windows Server security permissions can get confusing. Contributor Brien M. Posey explains why NTFS permissions are better than share level permission and how to check permissions with Server Share Check.

One of the most confusing aspects of Windows Server security is the way that access control entries (ACEs) can be applied at both the share level and at the file system level. Granted, both types of permissions have their place, but using both types of permissions simultaneously can cause some interesting problems. I'll explain those problems and how to use Server Share Check to solve them.

The problem with using both share level permissions and NTFS permissions together is that any time administrators need to change a permission, they must remember to change the permission in two different places. Should an administrator forget to make the change in both places, it is possible for the share permissions and the NTFS permissions to become contradictory. Windows has its own way of dealing with contradictions, but it is often difficult for inexperienced administrators to manually sort out the resulting set of permissions.

I personally tend to advise people to grant everyone full access at the share level and to assign more restrictive permissions only at the file level. In doing so, the file level permissions will be effective because they are more restrictive than the wide open permissions you assign at the share level.

In addition to helping to avoid confusion, there is at least one more reason why I advise people to avoid using restrictive permissions at the share level: Depending on your directory structure, share level permissions can be easy to circumvent.

Share level permissions work fine as long as there are no other shared folders above or below a share in the directory structure. However, if another share exists above or below a particular share, and that share is assigned different permissions, then the shares are overlapping and a user could use one share to get to the other.

For example, suppose you have a directory called \Files\Finance. Now, suppose you give the user full access to Files and read-only access to Finance by using share level permissions. In such a situation, the shares would overlap because Finance is a subdirectory of Files. If a user tried to access the Finance directory through the Finance share, she would receive the appropriate read-only permissions. If she attempted to go in through the Files share and drill down to the Finance directory, she would have full access to the finance files because of the permissions assigned to the Files share.

You can easily avoid the problems associated with overlapping shares and contradictory permissions just by assigning everyone full control at the share level and using NTFS permissions to secure the individual files or folders. The problem is that some administrators don't like the idea of leaving a share wide open because they believe that doing so constitutes a security risk.

As I have already pointed out, the consequences of having permissions assigned at both the share and the file levels is that you could potentially have the confusion associated with contradictory permissions. However, Microsoft designed a little known tool that helps administrators determine which permissions are actually in effect.

The tool is called Server Share Check and is part of the Windows Server 2003 Resource Kit tools. If you don't already own a copy of the resource kit you can download it for free.

The Server Share Check tool is designed for Windows Server 2003, but it also works with Windows 2000 and Windows XP. After you download the resource kit tools, just double click on the file that you downloaded, and all of the tools will be extracted to the \Program Files\Windows Resource Kits\Tools folder. There are a lot of different files included in the resource kit tools. The Server Share Check tool uses SRVCHECK.EXE as a file name.

The Server Share Check tool doesn't have a GUI interface, so you will have to run it within a Command Prompt window. To do so, just enter the following command, where servername is the name of the server that you want to test:

SRVCHECK \\servername

When you run the command, the utility will examine every share on the server, including built-in shares. The utility will then display each group's effective rights at the root level of the share. You can see an example of this in Figure A.

Figure A

The SRVCHECK tool reveals effective permissions for shares.

Of course this utility only reveals the effective permissions at the root level of a share. If you need to know the effective permissions for a specific folder within the share, you can determine those permissions through the Windows GUI.

To do so, right click on the folder in question and select the Properties command from the resulting shortcut menu. When you do, you will see the folder's properties sheet. Select the properties sheet's Security tab and click the Advanced button. This will cause Windows to reveal the folder's Advanced Security Settings properties sheet. Now, just go to the properties sheet's Effective Permissions tab and enter a group or user name. When you do, the effective permissions for that group or user will be displayed, as shown in Figure B.

Figure B

Having contradictory permissions at the file and share level can be confusing. However, if you insist on implementing restrictive permissions at the share level, then there are tools you can use to reduce the confusion regarding effective permissions.

Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit his personal Web site at

Dig Deeper on Windows Server troubleshooting