"Permissão negada" criando uma nova raiz Dfs baseada em domínio como não administrador

Os endpoints Just Enough Administration (JEA) são adequados para sua tarefa. Projetar um terminal JEA requer três decisões principais:

1. Quem pode chamar o terminal JEA?
2. O que o chamador pode fazer?
3. Como a chamada será executada?

O endpoint do PowerShell no PS 5.1 não é tecnicamente um endpoint JEA, mas o mecanismo é essencialmente o mesmo.

Get-PSSessionConfiguration
Nome: microsoft.powershell PSVersion: 5.1 StartupScript
: Permissão: NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote Management Users AccessAllowed

A partir disso, os grupos de permissão definem quem tem permissão para ligar. Não há limitação no ponto de extremidade do PowerShell do que pode ser feito, então você tem recursos completos de linguagem. E, por último, com RunAsUser em branco - o código é executado representado pelo usuário ou pelas credenciais fornecidas.

Com essa base, consulte a ajuda para Register-PSSessionConfiguration, e uma visão geral do JEA .

Para obter pontos de bônus, considere o uso de contas de serviço gerenciado de grupo (GMSA) como parte de sua solução, especialmente como o chamador.

No seu caso: você pode restringir o terminal para ser chamado por seus usuários com privilégios limitados.

Em seguida, defina cmdlets específicos que você deseja que eles usem. Eles podem ser incorporados ou expostos a partir de módulos personalizados que você especificar. Mantenha-os específicos para sua tarefa, para evitar ataques de elevação de privilégio com argumentos complicados ou muitos comandos de baixo nível expostos que podem tirar vantagem de serem executados como um usuário elevado.

Você pode usar um RunAsUseradministrador de domínio ou outra conta com privilégios suficientes.

Para criar um namespace DFS em todo o domínio, uma conta que o faça deve ter um privilégio de administrador local em um servidor de namespace, ADSRV0no seu caso. Sua última mensagem de erro me sugere que não é assim no seu caso.

Apenas para adicionar alguns detalhes de implementação à ideia inicial de Matthew Wetmore aqui, criamos uma função configurando o namespace Dfs de acordo com nossos requisitos, expondo-o em um módulo Powershell LT-DFSManagemente criando uma configuração de sessão Powershell em execução em uma "conta virtual" (que está obtendo privilégios de administrador local) em um controlador de domínio restrito a chamar essa mesma função e acessível aos membros de um grupo de segurança de técnicos.

Estamos usando dfsutilo código como foi escrito para rodar em uma máquina Server 2008 R2, onde os Dfsn -cmdlets não estão disponíveis. Esteja ciente de que o código está usando algumas variáveis ​​globais que não serão definidas em seu ambiente por padrão, mas são vitais para a execução correta do código.

Function Add-DfsNamespace() {
<#
.SYNOPSIS
Creates a new Dfs namespace
#>
    Param(
        # Name of the namespace to create
        [string]$Name,
        # name of the security group to delegate management permissions to
        [string]$DelegationTo = "ACL-$Name-Dfs-management",
        # list of the servers to set up as namespace servers
        $NamespaceServerList = $global:DomainControllersList
    )

    $ErrorActionPreference = "Stop"

    Try { 
        $DelegationIdentity = (Get-ADGroup $DelegationTo -Server $global:THKDomainControllerToUse).SID
    } Catch {
        Throw "Unable to set up delegation permissions for $DelegationTo: $_"
    }
    $NamespaceServerList | ForEach-Object {
        Try {
            $NamespaceServer = $_
            Write-Debug "Create a directory for the namespace: \\$NamespaceServer\c$\DfsRoots\$Name"
            New-Item -Type Directory "\\$NamespaceServer\c$\DfsRoots\$Name" | Out-Null
        } Catch {
            Write-Warning "Creation of \\$NamespaceServer\c$\DfsRoots\$Name failed: $_"
        }

        # Create a new share through WMI
        $share = [wmiclass]"\\$_\root\CimV2:Win32_Share" 
        Write-Debug 'WMI call to create the share `"$Name`" on $_' 
        $result=$share.Create( "c:\DfsRoots\$Name", $Name, 0) 
        Switch ($result.returnValue) {
           0 { Write-Debug "\\$_\$Name share created successfully" }
           22 { Write-Warning "Share \\$_\$Name already present" }
           default { Throw "Share creation failed, return value of Win32_Share.Create: $result.returnValue" }
        }
    }
    Write-Verbose "Creating Domain Dfs namespace $Name on namespace servers $($NamespaceServerList -join "; ")"
    dfsutil root addDom "\\$($NamespaceServerList[0])\$Name"
    $NamespaceServerList | ForEach-Object {
        If($_ -ne $NamespaceServerList[0]) {
            dfsutil target add "\\$_\$Name"
        }
    }
    Write-Debug "Enabling Access-Based Enumeration"
    dfsutil property abde enable "\\$global:sADDomainFQDN\$Name"
    Write-Debug "Granting delegation rights for Namespace $Name to $DelegatedTo"
    $adsiDfsNamespace = $null
    $adsiDfsNamespace = [adsi]"LDAP://$global:THKDomainControllerToUse/CN=$Name,CN=Dfs-Configuration,CN=System,$sADDomainDN" 
    # Query ADSI for the ACL of the namespace AD object until we get a response
    $retries = 0
    Do {
        $namespaceACL = $adsiDfsNamespace.PSBase.ObjectSecurity
        If ($namespaceACL) {
            # here we've got the ACL, loop will end hereafter
        } Else {
            Write-Debug "Waiting another round ($retries/$ADSImaxRetries) as ADSI has not yet provided a security descriptor for $($adsiDfsNamespace)"
            Start-Sleep 1
        }
        $retries+=1
    } Until (($retries -gt $ADSImaxRetries) -or ($null -ne $namespaceACL))

    Write-Debug "Creating a new ACE for $DelegationTo ($DelegationIdentity)"
    # Construct a new Full Control ACE for $DelegationIdentity 
    $newAce =
        New-Object System.DirectoryServices.ActiveDirectoryAccessRule(
            $DelegationIdentity,
            [System.DirectoryServices.ActiveDirectoryRights]::GenericAll,
            [System.Security.AccessControl.AccessControlType]::Allow,
            [System.DirectoryServices.ActiveDirectorySecurityInheritance]::All
        )

    Write-Verbose "Updating the ACL of the Namespace $Name"
    $namespaceAcl.AddAccessRule($newAce)
    $adsiDfsNamespace.PSBase.CommitChanges()
}

O arquivo PSSessionConfiguration define o grupo de segurança para o qual esta configuração de sessão estará disponível:

@{
    'Author' = 'the-wabbit';
    'RunAsVirtualAccount' =  $true;
'GUID' = 'cfe0ea5f-9d19-406d-90aa-d26df4bc840f';
    'TranscriptDirectory' = 'C:\ProgramData\JEAConfiguration\Transcripts';
    'SchemaVersion' = '2.0.0.0';
    'RoleDefinitions' = @{
                            'DOMAIN\ACL-DFS-Technicians-AD-JEA-Remoting' = @{
                                                                                'RoleCapabilities' = 'AD-JEA-DFS' }
                        };
    'SessionType' = 'RestrictedRemoteServer' }

e o AD-JEA-DFSarquivo de capacidade de função restringe o terminal apenas à função Add-DfsNamespace:

@{
GUID = 'b17b282d-a656-41c8-a7d4-cc6a1fbc17e4'
Author = 'the-wabbit'
CompanyName = 'Looney Tunes'
Copyright = '(c) 2017 the-wabbit. All rights reserved.'
ModulesToImport = 'LT-DFSManagement'
VisibleFunctions='Add-DfsNamespace'
}

Um registro final da configuração coloca as coisas no lugar:

Register-PSSessionConfiguration -Name "DFS" -Path "C:\ProgramData\JEAConfiguration\DFS.pssc"