"Permission Denied" creating a new domain-based Dfs root as non-Administrator

Question

I have been tasked to delegate a number of everyday tasks in our domain to a group of technicians which does not have Domain Admins membership. One of these tasks is the creation of new domain-based Dfs roots (Server 2008 R2 Enterprise DCs). And this is where I am stuck.

Teh c0de

This is basically just trying to create a domain-based Dfs root, using an arbitrary (first-in-list) Domain Controller as the first Namespace Server:

$DfsnRootName="test"
$DCList = Get-ADDomainController -Filter * | ForEach-Object { ,$_.HostName } 
New-DfsnRoot -Path "\\domain.contoso.com\$DfsnRootName" -TargetPath "\\$($DCList[0])\$dfsnRootName" `
             -Description "Dfs-Root für $DfsnRootName" -EnableAccessBasedEnumeration $true -Type DomainV2
$DCList | ForEach-Object {
    New-DfsnRootTarget -Path "\\domain.contoso.com\$DfsnRootName" `
                       -TargetPath "\\$_\$dfsnRootName" -State Online
}

Teh err0r

The code above is throwing an exception mentioning missing access to a CIM resource. The path ROOT\Microsoft\Windows\DFSN\MSFT_DFSNamespace given in CategoryInfo looks like a WMI path:

New-DfsnRoot : Access to a CIM resource was not available to the client.
At line:1 char:1
+ New-DfsnRoot -Path "\\domain.contoso.com\$DfsnRootName" -TargetPath "\\$($DCList ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : PermissionDenied: (MSFT_DFSNamespace:ROOT\Microsoft\...FT_DFSNamespace) [New-DfsnRoot], CimException
    + FullyQualifiedErrorId : MI RESULT 2,New-DfsnRoot


PS Z:\> $Error[0].CategoryInfo


Category   : PermissionDenied
Activity   : New-DfsnRoot
Reason     : CimException
TargetName : MSFT_DFSNamespace
TargetType : ROOT\Microsoft\Windows\DFSN\MSFT_DFSNamespace

Teh helpless res0luti0n attempts:

I have "Delegated Management permissions" via the Dfs console for the entire domain:

which is effectively just adding a "full control" ACE for the added principal to the CN=Dfs-Configuration,CN=System AD container.

And as I was getting an error indicating missing permissions on the Service Control Manager using the "Add Dfs root" Wizard in dfsmgmt.msc, I used sc sdset scmanager to manipulate the SDDL string adding the respective group with "KA" (key access) permissions, analogous to the BUILTIN\Administrators ACE which exists by default.

This way, I can use the "Add Dfs root" wizard to walk through all the steps, but the creation of the root itself is still failing - "The namespace server \ADSRV0\Test cannot be added. Access is denied"

W00t?

Solution 1

Just Enough Administration (JEA) endpoints are well suited to your task. Designing a JEA endpoint requires three main decisions:

1. Who can call the JEA endpoint?
2. What can the caller do?
3. Who will the call run as?

The PowerShell endpoint in PS 5.1 isn't technically a JEA endpoint, but the mechanism is essentially the same.

Get-PSSessionConfiguration
Name : microsoft.powershell PSVersion : 5.1
StartupScript:
RunAsUser :
Permission : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote Management Users AccessAllowed

From this, the permission groups define who is allowed to call. There is no limitation on the PowerShell endpoint of what can be done, so you have full language capabilities. And lastly, with RunAsUser being blank - the code runs impersonated as the user or credentials provided.

With that basis, look at the help for Register-PSSessionConfiguration, and an overview of JEA.

For bonus points, consider using Group Managed Service Accounts (GMSA) as part of your solution, particularly as the caller.

In your case: You can restrict the endpoint to being called by your limited privilege users.

Then define specific cmdlets you want them to use. These can be built in, or exposed from custom modules you specify. Keep these specific to your task, to avoid elevation of privilege attacks with complicated arguments or too many low level commands exposed that can take advantage of being run as an elevated user.

You could use a RunAsUser of a Domain Administrator, or another account with sufficient privileges.

Solution 2

To create a domain-wide DFS namespace an account doing so should have a Local Administrator privilege on a namespace server, that is ADSRV0 in your case. Your last error message suggests to me that it isn't so in your case..

Comments

[the-wabbit]

"Local Administrator" on a DC is basically a Domain Admin. I am looking for a way to create Dfs roots without having to assign domain admin privileges to people executing this task. I am aware that the MS documentation is suggesting you would need local administrator rights on the namespace server, it just does not fit the use case here.

[Peter Zhabin]

Well, when you create DFS Root, in essence you create a share on a namespace server. To my knowledge there's no way to achieve this without being a local admin. You can circumvent other machinery around DFS Management, but the core issue will still stand.

[the-wabbit]

Technically, you can delegate the creation of shares. Also, as far as I can see, the privilege to create shares is at least not sufficient to create Dfs roots. I have granted "Server Operators" membership to the users in question, so they are able to create shares on DCs by default, yet they cannot add Dfs roots

[the-wabbit]

We have done exactly that - a Powershell Session Configuration running in the default scope of LocalSystem on the DC and exposed the module functions necessary to create Dfs namespaces. Works as expected, with the only problem of Import-PSSession being broken for PS 5.1 clients.

[Matthew Wetmore]

Did you re-configure the default endpoint, or create a new configuration name? Generally we create new configurations, then use -ConfigurationName on Invoke-Command or when creating a New-PSSession.

[the-wabbit]

I created a new restricted configuration. I also should mention that we ran into the problem of long-ish Kerberos tokens causing WSMan errors: support.microsoft.com/en-us/help/970875 which could be remedied by increasing MaxFieldLength/MaxRequestBytes to 65534. This one has been a bit tedious to debug as the error message returned by New-PSSession is not particularly helpful and we had to get a network trace of the HTTP exchange to get an idea about what was wrong.