DFS namespace permissions

This is a common topic in the DFS_FRS field. Customers often describe how some users are unexpectedly denied access to targets in the namespace while other users can access the targets without problems. Customers also ask whether there are DFS permissions somewhere that must be adjusted. The answer is that DFS clients will respect the combination of NTFS and share permissions set on the particular target the client is trying to access.

Inconsistent access is often caused by the following configurations:

▪       For a given target, the NTFS and share permissions are in conflict, with one prohibiting access and the other allowing access.

▪       For a folder with multiple targets, NTFS and share permissions aren’t set identically on all targets, so users have different access experiences depending on which target they access.

▪       A combination of the previous two bullets can compound the problem.

So if your customers have unexpected access problems, check the share and NTFS permissions for all targets as described above. Also, when setting NTFS permissions, always use the path of the physical folder (\servernamesharename) instead of navigating through the DFS namespace to set permissions. This is especially important when you have multiple folder targets for a given folder. Setting permissions on a folder by using its DFS path can cause the folder to inherit permissions from its parent folder in the namespace.

In addition, if there are multiple folder targets, only one of them gets its permissions updated when you use the DFS path. KB article 842604 also covers this recommendation.

And finally, for any admin out there whose users are using Office 2000 against a domain-based namespace, the symptom might be permissions-related due to the inconsistent access problems when, in fact, the problem was something else entirely. See articles 272230 and 294687 for details.

-End-

Author:Jacky Liu