Dando o segundo salto na Comunicação Remota do PowerShell

O "problema do segundo salto" refere-se a uma situação semelhante ao seguinte:

1. Você está conectado no ServerA.
2. No ServerA, você inicia uma sessão remota do PowerShell para se conectar ao ServerB.
3. Um comando executado no ServerB por meio de sua sessão de Conexão Remota do PowerShell tenta acessar um recurso no ServerC.
4. O acesso ao recurso no ServerC foi negado, pois as credenciais usadas para criar a sessão de Comunicação Remota do PowerShell não foram passadas do ServerB para o ServerC.

Há várias maneiras de resolver esse problema. A tabela a seguir lista os métodos por ordem de preferência.

CredSSP

Você pode usar o CredSSP (Credential Security Support Provider) para autenticação. O CredSSP armazena em cache as credenciais no servidor remoto (ServerB), portanto, usá-lo abre para ataques de roubo de credenciais. Se o computador remoto estiver comprometido, o invasor terá acesso às credenciais do usuário. O CredSSP é desabilitado por padrão nos computadores cliente e servidor. Você só deve habilitar o CredSSP nos ambientes mais confiáveis. Por exemplo, um administrador de domínio que se conecta a um controlador de domínio porque o controlador de domínio é altamente confiável.

Para saber mais sobre questões de segurança ao usar o CredSSP para comunicação remota do PowerShell, consulte Accidental Sabotage: Beware of CredSSP (Sabotagem acidental: cuidado com o CredSSP).

Para obter mais informações sobre ataques de roubo de credenciais, consulte Mitigando ataques PtH (Pass-the-Hash) e outro roubo de credenciais.

Para obter um exemplo de como habilitar e usar o CredSSP para comunicação remota do PowerShell, confira Habilitar a funcionalidade de "Segundo Salto" do PowerShell com o CredSSP.

Vantagens

• Ele funciona para todos os servidores com o Windows Server 2008 ou posterior.

Desvantagens

• Tem vulnerabilidades de segurança.
• Requer a configuração de funções de cliente e servidor.
• Não funciona com o grupo de Usuários Protegidos. Para obter mais informações, confira Grupo de segurança de usuários protegidos.

Delegação restrita de Kerberos

Você pode usar a delegação restrita herdada (não baseada em recursos) para realizar o segundo salto. Configure a delegação restrita de Kerberos com a opção "Usar qualquer protocolo de autenticação" para permitir a transição de protocolo.

Vantagens

• Não exige nenhuma codificação especial
• As credenciais não são armazenadas.

Desvantagens

• Não oferece suporte ao segundo salto para o WinRM.
• Requer acesso de administrador de domínio para configuração.
• Deve ser configurada no objeto do Active Directory do servidor remoto (ServerB).
• Limitado a um domínio. Não pode cruzar domínios ou florestas.
• Requer direitos para atualizar objetos e SPNs (Nomes de Entidade de Serviço).
• O ServerB pode adquirir um tíquete Kerberos para o ServerC em nome do usuário sem que este intervenha.

Delegação restrita de Kerberos com base em recursos

A utilização da delegação restrita de Kerberos baseada em recursos (introduzida no Windows Server 2012) permite que seja configurada a delegação de credencial no objeto do servidor no qual os recursos residem. No cenário do segundo salto descrito acima, você configura o ServerC para especificar de onde ele aceita credenciais delegadas.

Vantagens

• As credenciais não são armazenadas.
• Configurada usando cmdlets do PowerShell. Nenhuma codificação especial é necessária.
• Não requer acesso de administrador de domínio para configuração.
• Funciona entre domínios e florestas.

Desvantagens

• Requer o Windows Server 2012 ou posterior.
• Não oferece suporte ao segundo salto para o WinRM.
• Requer direitos para atualizar objetos e SPNs (Nomes de Entidade de Serviço).

Exemplo

Vejamos um exemplo do PowerShell que configura a delegação restrita baseada em recursos no ServerC para permitir credenciais delegadas de um ServerB. Esse exemplo pressupõe que todos os servidores estão executando versões com suporte do Windows Server e que há pelo menos um controlador de domínio do Windows para cada domínio confiável.

Antes de configurar a delegação restrita, você deve adicionar o recurso RSAT-AD-PowerShell para instalar o módulo Active Directory PowerShell e, em seguida, importar esse módulo na sua sessão:

Add-WindowsFeature RSAT-AD-PowerShell
Import-Module ActiveDirectory
Get-Command -ParameterName PrincipalsAllowedToDelegateToAccount

Vários cmdlets disponíveis agora têm um parâmetro PrincipalsAllowedToDelegateToAccount:

CommandType Name                 ModuleName
----------- ----                 ----------
Cmdlet      New-ADComputer       ActiveDirectory
Cmdlet      New-ADServiceAccount ActiveDirectory
Cmdlet      New-ADUser           ActiveDirectory
Cmdlet      Set-ADComputer       ActiveDirectory
Cmdlet      Set-ADServiceAccount ActiveDirectory
Cmdlet      Set-ADUser           ActiveDirectory

O parâmetro PrincipalsAllowedToDelegateToAccount define o atributo do objeto do Active Directory msDS-AllowedToActOnBehalfOfOtherIdentity, que contém uma ACL (lista de controle de acesso) que especifica quais contas têm permissão para delegar credenciais à conta associada (em nosso exemplo, será a conta da máquina do ServerA).

Agora vamos configurar as variáveis que usaremos para representar os servidores:

# Set up variables for reuse
$ServerA = $env:COMPUTERNAME
$ServerB = Get-ADComputer -Identity ServerB
$ServerC = Get-ADComputer -Identity ServerC

O WinRM (e, portanto, comunicação remota do PowerShell) é executado como a conta de computador por padrão. Você pode ver isso examinando a propriedade StartName do serviço winrm:

Get-CimInstance Win32_Service -Filter 'Name="winrm"' | Select-Object StartName

StartName
---------
NT AUTHORITY\NetworkService

Para que o ServerC permita a delegação de uma sessão de comunicação remota do PowerShell no ServerB, é necessário definir o parâmetro PrincipalsAllowedToDelegateToAccount no ServerC como o objeto de computador do ServerB:

# Grant resource-based Kerberos constrained delegation
Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $ServerB

# Check the value of the attribute directly
$x = Get-ADComputer -Identity $ServerC -Properties msDS-AllowedToActOnBehalfOfOtherIdentity
$x.'msDS-AllowedToActOnBehalfOfOtherIdentity'.Access

# Check the value of the attribute indirectly
Get-ADComputer -Identity $ServerC -Properties PrincipalsAllowedToDelegateToAccount

O KDC (Centro de distribuição de chaves) Kerberos armazena em cache as tentativas de acesso negado (cache negativo) por 15 minutos. Se ServerB tentou acessar anteriormente o ServerC, será necessário limpar o cache no ServerB invocando o seguinte comando:

Invoke-Command -ComputerName $ServerB.Name -Credential $cred -ScriptBlock {
    klist purge -li 0x3e7
}

Você também pode reiniciar o computador ou aguardar pelo menos 15 minutos para limpar o cache.

Depois de limpar o cache, é possível executar com êxito o código do ServerA por meio do ServerB no ServerC:

# Capture a credential
$cred = Get-Credential Contoso\Alice

# Test kerberos double hop
Invoke-Command -ComputerName $ServerB.Name -Credential $cred -ScriptBlock {
    Test-Path \\$($using:ServerC.Name)\C$
    Get-Process lsass -ComputerName $($using:ServerC.Name)
    Get-EventLog -LogName System -Newest 3 -ComputerName $($using:ServerC.Name)
}

Neste exemplo, a variável $using é usada para tornar a variável $ServerC visível ao ServerB. Para obter mais informações sobre a variável $using, consulte about_Remote_Variables.

Para permitir que vários servidores deleguem credenciais ao ServerC, defina o valor do parâmetro PrincipalsAllowedToDelegateToAccount no ServerC em uma matriz:

# Set up variables for each server
$ServerB1 = Get-ADComputer -Identity ServerB1
$ServerB2 = Get-ADComputer -Identity ServerB2
$ServerB3 = Get-ADComputer -Identity ServerB3
$ServerC  = Get-ADComputer -Identity ServerC

$servers = @(
    $ServerB1,
    $ServerB2,
    $ServerB3
)

# Grant resource-based Kerberos constrained delegation
Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $servers

Se você quiser fazer o segundo salto entre domínios, use o parâmetro Server para especificar o nome de domínio totalmente qualificado (FQDN) do controlador de domínio ao qual o ServerB pertence:

# For ServerC in Contoso domain and ServerB in other domain
$ServerB = Get-ADComputer -Identity ServerB -Server dc1.alpineskihouse.com
$ServerC = Get-ADComputer -Identity ServerC
Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $ServerB

Para remover a capacidade de delegar credenciais para o ServerC, defina o valor do parâmetro PrincipalsAllowedToDelegateToAccount no ServerC como $null:

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

Informações sobre delegação restrita de Kerberos baseada em recursos

• Novidades na Autenticação Kerberos
• Como o Windows Server 2012 Ameniza a Dificuldade da Delegação Restrita de Kerberos, Parte 1
• Como o Windows Server 2012 Ameniza a Dificuldade da Delegação Restrita de Kerberos, Parte 2
• Noções básicas sobre a Delegação Restrita de Kerberos para Implantações de Proxy de Aplicativo do Microsoft Entra com a Autenticação Integrada do Windows
• [MS-ADA2 Atributos de esquema do Active Directory, atributo M2.210 msDS-AllowedToActOnBehalfOfOtherIdentity]MS-ADA2
• [MS-SFU: Extensões do protocolo Kerberos: serviço para usuário e Protocolo de Delegação Restrita 1.3.2 S4U2proxy]MS-SFU
• Administração remota sem a delegação restrita usando PrincipalsAllowedToDelegateToAccount

Delegação Kerberos (irrestrita)

Você também pode usar a delegação Kerberos irrestrita para realizar o segundo salto. Como todos os cenários do Kerberos, as credenciais não são armazenadas. Este método não dá suporte ao segundo salto para o WinRM.

JEA (Administração Just Enough)

O JEA permite restringir os comandos que um administrador pode executar durante uma sessão do PowerShell. Pode ser usado para resolver o problema do segundo salto.

Para obter informações sobre o JEA, consulte Just Enough Administration.

Vantagens

• Não necessita manutenção de senha ao usar uma conta virtual.

Desvantagens

• Requer o WMF 5.0 ou posterior.
• Requer a configuração em cada servidor intermediário (ServerB).

PSSessionConfiguration usando RunAs

Você pode criar uma configuração de sessão no ServerB e definir o parâmetro RunAsCredential.

Para obter mais informações sobre como usar PSSessionConfiguration e RunAs para solucionar o problema do segundo salto, confira Outra solução para a comunicação remota do PowerShell com vários saltos.

Vantagens

• Funciona com qualquer servidor com o WMF 3.0 ou posterior.

Desvantagens

• Requer a configuração de PSSessionConfiguration e de RunAs em cada servidor intermediário (ServerB).
• Requer manutenção de senha ao usar uma conta RunAs de domínio

Passar credenciais dentro de um bloco de script Invoke-Command

É possível passar credenciais dentro do parâmetro ScriptBlock de uma chamada do cmdlet Invoke-Command.

Vantagens

• Não requer configuração especial do servidor.
• Funciona em qualquer servidor que executa o WMF 2.0 ou posterior.

Desvantagens

• Requer uma técnica de código complicada.
• Se estiver executando o WMF 2.0, necessita de uma sintaxe diferente para passar argumentos para uma sessão remota.

Exemplo

O exemplo a seguir mostra como passar credenciais em um bloco de script:

# This works without delegation, passing fresh creds
# Note $Using:Cred in nested request
$cred = Get-Credential Contoso\Administrator
Invoke-Command -ComputerName ServerB -Credential $cred -ScriptBlock {
    hostname
    Invoke-Command -ComputerName ServerC -Credential $Using:cred -ScriptBlock {hostname}
}

Confira também

Considerações de segurança de comunicação remota do PowerShell