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

  • Artigo

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

  1. Tem sessão iniciada no ServerA.
  2. A partir do ServerA, inicia uma sessão remota do PowerShell para ligar ao ServerB.
  3. Um comando que executa no ServerB através da sua sessão remota do PowerShell tenta aceder a um recurso no ServerC.
  4. O acesso ao recurso no ServerC é negado porque as credenciais que utilizou para criar a sessão Remoting do PowerShell não são transmitidas do ServidorB para o ServerC.

Existem várias formas de resolver este problema. A tabela seguinte lista os métodos por ordem de preferência.

Configuração Nota
CredSSP Balanceamentos de facilidade de utilização e segurança
Delegação restrita de Kerberos baseada em recursos Maior segurança com configuração mais simples
Delegação restrita de Kerberos Alta segurança, mas requer Administrador de Domínio
Delegação kerberos (sem restrições) Não recomendado
Administração JEA (Just Enough Administration) Pode fornecer a melhor segurança, mas requer uma configuração mais detalhada
PSSessionConfiguration com RunAs Mais simples de configurar, mas requer a gestão de credenciais
Transmitir credenciais dentro de um bloco de Invoke-Command scripts Mais simples de utilizar, mas tem de fornecer credenciais

CredSSP

Pode utilizar o Fornecedor de Suporte de Segurança de Credenciais (CredSSP) para autenticação. CredSSP coloca em cache as credenciais no servidor remoto (ServerB), pelo que a sua utilização abre-o até ataques de roubo de credenciais. Se o computador remoto estiver comprometido, o atacante terá acesso às credenciais do utilizador. CredSSP está desativado por predefinição em computadores cliente e servidor. Deve ativar o CredSSP apenas nos ambientes mais fidedignos. Por exemplo, um administrador de domínio a ligar a um controlador de domínio porque o controlador de domínio é altamente fidedigno.

Para obter mais informações sobre questões de segurança ao utilizar o CredSSP para a Comunicação Remota do PowerShell, veja Sabotagem Acidental: Cuidado com CredSSP.

Para obter mais informações sobre ataques de roubo de credenciais, veja Mitigar Ataques Pass-the-Hash (PtH) e Outro Roubo de Credenciais.

Para obter um exemplo de como ativar e utilizar o CredSSP para comunicação remota do PowerShell, veja Enable PowerShell "Second-Hop" Functionality with CredSSP (Ativar a Funcionalidade "Segundo Salto" do PowerShell com CredSSP).

Vantagens

  • 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 de servidor.
  • não funciona com o grupo Utilizadores Protegidos. Para obter mais informações, veja Grupo de Segurança de Utilizadores Protegidos.

Delegação restrita de Kerberos

Pode utilizar a delegação restrita legada (não baseada em recursos) para fazer o segundo salto. Configure a delegação restrita de Kerberos com a opção "Utilizar qualquer protocolo de autenticação" para permitir a transição do protocolo.

Vantagens

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

Desvantagens

  • Não suporta o segundo salto para WinRM.
  • Requer acesso de Administrador de Domínio para configurar.
  • Tem de ser configurado no objeto do Active Directory do servidor remoto (ServerB).
  • Limitado a um domínio. Não é possível atravessar domínios ou florestas.
  • Requer direitos para atualizar objetos e Nomes dos Principais de Serviço (SPNs).
  • O ServerB pode adquirir uma permissão Kerberos para o ServerC em nome do utilizador sem intervenção do utilizador.

Nota

As contas do Active Directory que têm a Conta são confidenciais e não podem ser delegadas . Para obter mais informações, consulte Foco de Segurança: Analisar "A conta é confidencial e não pode ser delegada" para Contas Privilegiadas e Ferramentas e Definições de Autenticação Kerberos.

Delegação restrita de Kerberos baseada em recursos

Ao utilizar a delegação restrita de Kerberos baseada em recursos (introduzida no Windows Server 2012), configure a delegação de credenciais no objeto de servidor onde residem os recursos. No segundo cenário de salto descrito acima, configura o ServerC para especificar a partir do local onde aceita credenciais delegadas.

Vantagens

  • As credenciais não são armazenadas.
  • Configurado com cmdlets do PowerShell. Não é necessária codificação especial.
  • Não requer acesso de Administrador de Domínio para configurar.
  • Funciona em domínios e florestas.

Desvantagens

  • Requer Windows Server 2012 ou posterior.
  • Não suporta o segundo salto para WinRM.
  • Requer direitos para atualizar objetos e Nomes dos Principais de Serviço (SPNs).

Nota

As contas do Active Directory que têm a Conta são confidenciais e não podem ser delegadas . Para obter mais informações, consulte Foco de Segurança: Analisar "A conta é confidencial e não pode ser delegada" para Contas Privilegiadas e Ferramentas e Definições de Autenticação Kerberos.

Exemplo

Vejamos um exemplo do PowerShell que configura a delegação restrita baseada em recursos no ServerC para permitir credenciais delegadas de um ServidorB. Este exemplo pressupõe que todos os servidores estão a executar Windows Server 2012 ou posterior e que existe pelo menos um Windows Server 2012 controlador de domínio a cada domínio ao qual qualquer um dos servidores pertence.

Antes de poder configurar a delegação restrita, tem de adicionar a RSAT-AD-PowerShell funcionalidade para instalar o módulo do PowerShell do Active Directory e, em seguida, importar esse módulo para a sua sessão:

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

Vários cmdlets disponíveis têm agora 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 de objeto do Active Directory msDS-AllowedToActOnBehalfOfOtherIdentity, que contém uma lista de controlo de acesso (ACL) que especifica quais as contas que têm permissão para delegar credenciais à conta associada (no nosso exemplo, será a conta de computador para ServerA).

Agora, vamos configurar as variáveis que iremos utilizar 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, a comunicação remota do PowerShell) é executado como a conta de computador por predefinição. Pode ver isto ao observar a propriedade StartName do winrm serviço:

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

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

Para o ServerC permitir a delegação de uma sessão remota do PowerShell no ServidorB, temos de definir o parâmetro PrincipalsAllowedToDelegateToAccount no ServerC para 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 Centro de Distribuição de Chaves Kerberos (KDC) coloca em cache tentativas de acesso negado (cache negativa) durante 15 minutos. Se o ServerB já tentou aceder ao ServerC, terá de limpar a cache no ServerB ao invocar o seguinte comando:

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

Também pode reiniciar o computador ou aguardar, pelo menos, 15 minutos para limpar a cache.

Depois de limpar a cache, pode executar com êxito o código do ServerA através do ServerB para o 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 $using variável é utilizada para tornar a $ServerC variável visível para ServerB. Para obter mais informações sobre a $using variável, veja about_Remote_Variables.

Para permitir que vários servidores deleguem credenciais ao ServerC, defina o valor do parâmetro PrincipalsAllowedToDelegateToAccount no ServerC para 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 quiser fazer o segundo salto entre domínios, utilize o parâmetro Server para especificar o nome de domínio completamente qualificado (FQDN) do controlador de domínio do 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 ao ServerC, defina o valor do parâmetro PrincipalsAllowedToDelegateToAccount no ServerC como $null:

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

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

Delegação kerberos (sem restrições)

Também pode utilizar a delegação kerberos sem restrições para dar o segundo salto. Como todos os cenários kerberos, as credenciais não são armazenadas. Este método não suporta o segundo salto para WinRM.

Aviso

Este método não fornece qualquer controlo sobre onde são utilizadas as credenciais delegadas. É menos seguro do que CredSSP. Este método só deve ser utilizado para cenários de teste.

Administração JEA (Just Enough Administration)

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

Para obter informações sobre JEA, consulte Administração Suficiente.

Vantagens

  • Sem manutenção de palavras-passe ao utilizar uma conta virtual.

Desvantagens

  • Requer o WMF 5.0 ou posterior.
  • Requer configuração em todos os servidores intermédios (ServerB).

PSSessionConfiguration com RunAs

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

Para obter informações sobre a utilização de PSSessionConfiguration e RunAs para resolver o problema do segundo salto, consulte Outra solução para a comunicação remota do PowerShell de vários saltos.

Vantagens

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

Desvantagens

  • Requer a configuração de PSSessionConfiguration e RunAs em todos os servidores intermédios (ServerB).
  • Requer manutenção de palavra-passe ao utilizar uma conta RunAs de domínio

Transmitir credenciais dentro de um bloco de script Invoke-Command

Pode transmitir credenciais dentro do parâmetro ScriptBlock de uma chamada para o cmdlet Invoke-Command .

Vantagens

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

Desvantagens

  • Requer uma técnica de código incómoda.
  • Se executar o WMF 2.0, requer sintaxe diferente para transmitir argumentos para uma sessão remota.

Exemplo

O exemplo seguinte mostra como transmitir credenciais num 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}
}

Ver também

Considerações de Segurança da Comunicação Remota do PowerShell