:::: MENU ::::

Windows NameSpace and ABE

Giving a bit of a face list to our File server we have decided to proceed with a Windows DFS Namespace.  One big reason for moving this direction rather than the traditional file shares is quite simply being able to present data in once space and still having the flexibility to distribute the data across several servers.  In this process we have elected to migrate our existing shared network drive to a new location so when we migrate each department we can talk thru storage best practices.  One major reason was to offload our Media storage to a separate server so there was less pain felt when mondo files were being archived on the servers from our Media folks.

NamespaceWe added DFS (2003R2) to our existing file server and configured it to host the name space.  In both 2003 and 2008 server this is a role that needs to be added for the service to be available.  A second server was named our media server and also was added to the namespace.  Here is a good article on the step by step to adding a Domain Namespace.

One item that wasn’t clear to me was DFS Creates a share that houses the links to your data when you add a server to the namespace the local location of the DFS Links SHOULDN’T be the location where your data exists.  The DFS Roots are simply a file structure that tells the namespace how to work and where to point… Don’t make the DFSRoots Shared folder your data location.

Now users can go do domain.orgNamespace and access their departments files even if those files live across two separate file servers. 

All was quickly working well except for one of our requirements for this project, enabling Access-Based Enumeration, Microsoft’s name for security trimming on a file server.  While the permissions were working and users couldn’t get to another departments data they could still see the other departments…. and learning from experience if people don’t have access to data then things are better if they can’t see that data is there…  So then started a quest to enable ABE on the namespace. 

We converted our new File server to Server 2008 since we read that DFS Namespaces support ABE.  The problem is the fine print, for ABE to run on a 2008 Namespace you have to have your domain functional level at 2008 to enable a 2008 Namespace.  We aren’t quite there yet since one of our DCs is still a 2003 DC so the quest continued.

Next we found this support document which explains the DFSRoots for each link in the namespace have to have the same ACL as the ACL on the target. 

From KB 907458

If the ACL on the DFS link is not set to match the ACL on the target, the following conditions may be true:

  • If the ACL on the link is more restrictive than the ACL on the target, the link will not be displayed. However, if the user knows the name of the link, the user can locate the appropriate path and see the contents of the target.
  • If the ACL on the link is less restrictive than the ACL on the target, the link is displayed. However, when the user locates the link, the user sees an “Access Denied” message.

One item wasn’t clear from the support document on our first attempt was fact that the default permissions on the DFS Roots directory overrides ADE and displays all directories to all users, even if they don’t have the rights to actually open those directories. This is because by default on the server ‘servernameusers’ (the local users account on the server) has read permissions on all directories in the DFSRoots directory.

Example:
Department 1
Has data living on Server 1 X:NameSpaceDataDepartment1 with Permissions DomainDept1: Full Control
Department 2
Has data living on Server 2 X:NameSpaceDataDepartment2 with Permissions DomainDept1: Full Control

We wanted to present both as directories in domainNamespace as
domainNamespaceDepartment1 and domainNamespaceDepartment2

Both appear in the namespace when ABE is enabled since the links to both directories (located in X:DFSRootsNameSpaceName) have rights for the local ‘users’.

Its good to now even though they could see the other departments the users without permissions to the other department get “Access Denied”

For our installation the DFSRoots were located e:DFSRootsNameSpaceName and the Data was located on the server on E:NameSpaceData.

We had to set the Permissions on e:DFSRootsNameSpaceName:
Administrator Full Control (This folder, subfolders and files)
LocalUsers: Read, List (this folder only, NOT This folder, subfolders and files)

Then use the CACLS utility to add read permissions to each department’s group to the appropriate link by navigating the command line to the e:DFSRootsNameSpaceName and running the following command:
cacls”DepartmentLinkDirectory” /E /G “DomainSecurityGroup”:R

This sets the ACL on the Department’s DFS Link to give the domain security group read permissions.  
The Switches
- /E edits the existing permissions vs. replaces the permission on the Link
- /G Grants Specified User access Rights and R is Read.

To set multiple groups:
cacls “DepartmentLinkDirectory” /E /G “DomainSecurityGroup”:R /G “DomainSecurityGroup2″:R

After the ACLs are set for the Target Data and the Links when you browse the namespace the user sees the department directories that are appropriate for that user.


One Comment

  • Reply Cyril |

    First off, great article.
    Second, I have a couple of questions:

    1) On the file server, how do you match the ACL with the target folder on the DC DFSroot directory? I run into an issue where FILESERVERNAMEAdministrators group is part of the ACL for the data folder and of course it cannot be also on the DC DFSroot as it is not a domain group?

    2) For redundancy, you want to have your DFS namespace hosted on more than one DC. What do you do then as it seems like when you run a command against contoso.microsoft.comdeptlegal you cannot select a specific DC and there is no replication of the DFSroot.

    Thanks for your input.

So, what do you think ?

UA-2932131-1