Like previous versions of Windows server, Windows Server 2003 allows access to resources at a very granular level. This means that you can determine specifically who should be allowed access to a particular resource and be confident that only those intended to have access will in fact have access. One caveat: You’ll need a thorough understanding of share permissions, NTFS permissions, and permissions inheritance. The following are problems you may run into that are related to accessing shared resources and some suggestions on how you might fix them.
When you run across a client that is unable to access a share point or a printer on your Windows Server 2003 system, the problem is generally in one of three areas: network connectivity, share permissions, and NTFS permissions.
Network connectivity problems resulting in difficulty accessing shared resources could be located at either the client or the server. A symptom of a problem with network connectivity at the server level includes the inability for multiple clients to access a particular resource. In these instances, make sure that the network cable is properly attached to the server and to the network equipment and that the cable is good.
However, don’t automatically assume there’s a problem with the resource server if multiple clients can’t access a resource, as the problem may be related to a problem with another network service such as DHCP. If the problem is only affecting a single client, also check the network cabling and hardware.
If the physical network is good, there could be a problem with an IP address or another service such as DNS. First, if the server gets its IP address via DHCP, make sure that service is functioning properly. Likewise, make sure that DHCP related to clients is also working. Of course, if it’s not, you’ll usually know fairly quickly, since DHCP problems tend to result in complete outages rather than spots here and there.
Additionally, make sure that the server and client IP addresses and subnet masks are properly configured. If you’ve mistakenly assigned an IP address or subnet mask to a client or server that doesn’t match the rest of the network, you’ll never be able to access the shared resources until you correct the problem.
Finally, as Windows has matured as a product, it has grown ever more reliant on DNS. If client DNS settings are not configured correctly or the DNS service is not available, clients might have problems accessing services for shared resources that are dependent on the inaccessible DNS.
With potential physical problems and client configuration problems out of the way, you can start to focus on the resource itself to determine the cause of the problem. The first place to check is the share information, including shared permissions. If your users are having trouble writing to a shared folder, for example, make sure that the share permissions are configured to allow them to write files to the shared location.
When you create a new share on a new Windows Server 2003 installation, by default, the assigned permissions grant Read access to Everyone. To modify the default permissions, right-click the shared folder and choose Properties. On the properties page, click the Permissions button. You’ll then see the screen shown in Figure A.
|This share allows Everyone to read the files|
To assign (or deny) a specific permission for a user or group, select the user or group from Active Directory by clicking the Add button. To allow both Change and Read access, use Full Control. Otherwise, select the appropriate rights and click Apply.
A second potential problem related to share permissions is if you limit the number of concurrent users on a particular share. This is done on the Sharing tab on the properties page for the share. If you have some users that can access the share and others that can’t, make sure the user count isn’t set too low. In Figure B, the allowed user count is set to 10 concurrent users.
|Concurrent user count for the share|
To change the count, either select the Maximum Allowed setting or provide the number of users that should be able to access the share.
In many environments, administrators simply assign Full Control permission to all shares and then use NTFS permissions to lock down the files and folders. For these administrators, it’s easier to keep track of one set of permissions than two.
If users are either unable to access a resource or are allowed to do too much, NTFS permissions and inheritance settings are a good place to look. For this demonstration, I’m using a subfolder under a shared folder in the examples I’ll go over with you. The parent folder is named Shared Folder while the subfolder inside this folder is named Subfolder.
If you’ve done any Active Directory or Novell Directory Services administration, the concept of inheritance should be familiar to you. NTFS also uses inheritance, as permissions from a parent folder flow down through the subfolder hierarchy. This means that a folder three levels down in the hierarchy will have the same permissions as the top-level folder unless explicit permissions have been assigned to subfolders or you’ve blocked permissions at some point.
Figure C shows the advanced security settings for subfolder. It also shows where the permissions came from. In many cases, in this example, the permissions were inherited from C:\.
|Permissions for subfolder|
If you want to disable these permissions from flowing down through the folder hierarchy, deselect the box Allow Inheritable Permissions From The Parent To Propagate To This Object And All Child Objects. Include These With The Entries Specified Here.
When you do this, you’ll see a message box like the one in Figure D indicating that parent permissions will no longer be applied to this folder. You’ll get two options. First, you can choose to copy the permissions and explicitly apply them to this folder, or you can choose to remove the inherited permissions and use only the explicitly assigned permissions.
|You can choose to either copy or remove the inherited permissions|
In Figure E below, I’ve opted to remove the inherited permissions.
|The inherited permissions have been removed from subfolder|
The second option you have related to inheritance is to apply the permissions from the current folder to all subfolders. This is accomplished by selecting the box marked Replace Permission Entries On All Child Objects With Entries Shown Here That Apply To Child Objects. This is useful in cases where you’ve been working on permissions on a child object and totally screwed them up. It, at least, gives you a baseline with which to start.
NTFS permissions are pretty easy to troubleshoot. Either a user has rights or he doesn’t. A very quick way to determine if a user is allowed access to a resource is to determine that user’s effective permissions for the resource, including how inheritance affects the user’s permissions. In Windows Server 2003, this is a quick task with the help of the Effective Permissions tool available on the advanced security settings screen for a resource.
To see the effective permissions tab, right-click a resource and select Properties. From the Security tab on the window, click the Advanced button and select the Effective Permissions tab. You’ll then see the screen shown in Figure F.
|The Effective Permissions tab|
Once you’re on this tab, to see the effective permissions for a particular user, click the Select tab and choose the user or group for which you would like to see the effective permissions. In Figure G, I have shown the effective permissions for the Guests group.
|Effective permissions for Guests|
A method before your madness
In a few places—and particularly with the help of the Effective Permissions tool—you can quickly isolate the cause of an access problem on a shared resource. First, track down the scope of the problem and figure out if anything was recently changed. After that, look at the network and share permissions for wide scope problems and the NTFS permissions and inheritance for smaller scopes.