Hey all, Figured I’d throw this out there to get some open discussion on the best way to tackle this. Typically speaking, most people use their DA accounts to create AD-integrated DFS Shares. However, per the Windows Server 2012/2012R2 Member Server STIG (Release 3, October 23 2015), Domain/Enterprise Admins should be set as “Deny access to this computer from a network.” Unfortunately, Domain Admin rights are typically used and needed when making changes to the AD DFS Container. And when you try to add the folder targets DFS Management Console can’t access them! (Because you’re using your DA Account, and you’ve denied access to this account on that server) So long story short, I said “Okay, I’ll just grant the ability for my server admin account to create AD-integrated DFS Namespaces” So I followed the MSKB here and created a security group to apply the permissions: https://support.microsoft.com/en-us/kb/258992 Easy enough! Threw my account into this new security group (DFS Admins) Done deal. I can now create AD-integrated DFS Namespaces from my Member Server account! Great….. But not so…. So it turns out, there’s a separate configuration in order to be able to create Replication Groups. So I looked around and can’t find exactly how to do this without using my DA account to delegate management to Replication Groups via the DFS Management Console. The problem is, the Replication Group I configured with my server admin account seems to not have inherited the security group permissions I set at the Replication Group Management level to allow my DFS Admins to manage Replication Groups… Any thoughts? Ideas? -Mike Cramer
Brainstorming Domain-based DFS with DISA STIGs
- 136 Views
- Last Post 08 April 2016
We ran into this about 18 months ago for our delegated domain-based DFS offering. See the DFS-R Support section at
I think the third permission noted in that section is the one you are seeking.
Of course, our documentation is specific to our groups and AD DIT, but it should be easy enough to translate to your scenario.