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

  • Artigo

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

  1. Você está conectado ao ServerA.
  2. A partir do ServerA, você inicia uma sessão remota do PowerShell para se conectar ao ServerB.
  3. Um comando executado no ServerB por meio da sessão de comunicação remota do PowerShell tenta acessar um recurso no ServerC.
  4. O acesso ao recurso no ServerC é negado, porque as credenciais usadas para criar a sessão de comunicação remota do PowerShell não são passadas do ServerB para o ServerC.

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

Configuração Nota
CredSSP Equilibra facilidade de uso 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 usando RunAs Mais simples de configurar, mas requer gerenciamento de credenciais
Passar credenciais dentro de um bloco de Invoke-Command script Mais simples de usar, mas você deve fornecer credenciais

CredSSP

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

Para obter mais informações sobre questões de segurança ao usar o CredSSP para comunicação remota do PowerShell, consulte Sabotagem acidental: cuidado com o CredSSP.

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

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

Prós

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

Contras

  • Tem vulnerabilidades de segurança.
  • Requer configuração de funções de cliente e servidor.
  • não funciona com o grupo Utilizadores Protegidos. Para obter mais informações, consulte 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 fazer 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.

Prós

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

Contras

  • Não suporta o segundo salto para WinRM.
  • Requer acesso de Administrador de Domínio para configurar.
  • Deve ser configurado no objeto Ative Directory do servidor remoto (ServerB).
  • Limitado a um domínio. Não é possível cruzar domínios ou florestas.
  • Requer direitos para atualizar objetos e SPNs (Nomes da Entidade de Serviço).
  • ServerB pode adquirir um tíquete Kerberos para ServerC em nome do usuário sem intervenção do usuário.

Nota

As contas do Ative Directory que têm a Conta é confidencial e não pode ser delegada ao conjunto de propriedades não podem ser delegadas. Para obter mais informações, consulte Foco em segurança: analisando "A conta é confidencial e não pode ser delegada" para contas privilegiadas e ferramentas e configurações de autenticação Kerberos.

Delegação restrita de Kerberos baseada em recursos

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

Prós

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

Contras

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

Nota

As contas do Ative Directory que têm a Conta é confidencial e não pode ser delegada ao conjunto de propriedades não podem ser delegadas. Para obter mais informações, consulte Foco em segurança: analisando "A conta é confidencial e não pode ser delegada" para contas privilegiadas e ferramentas e configuraçõ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 ServerB. Este exemplo pressupõe que todos os servidores estejam executando versões com suporte do Windows Server e que haja 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 RSAT-AD-PowerShell recurso para instalar o módulo PowerShell do Ative Directory e, em seguida, importar esse módulo para 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 de objeto do Ative Directory msDS-AllowedToActOnBehalfOfOtherIdentity, que contém uma lista de controle de acesso (ACL) que especifica quais contas têm permissão para delegar credenciais à conta associada (em nosso exemplo, será a conta de máquina para 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, a comunicação remota do PowerShell) é executado como a conta do computador por padrão. Você pode ver isso observando a propriedade StartName do winrm serviço:

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 remota do PowerShell no ServerB, devemos 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) armazena em cache tentativas de acesso negado (cache negativo) por 15 minutos. Se o ServerB já tentou acessar o ServerC, você precisará 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 esperar pelo menos 15 minutos para limpar o cache.

Depois de limpar o cache, você 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 é usada para tornar a $ServerC variável visível para ServerB. Para obter mais informações sobre a $using variável, consulte about_Remote_Variables.

Para permitir que vários servidores deleguem credenciais ao ServerC, defina o valor do parâmetro PrincipalsAllowedToDelegateToAccount no ServerC como 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 FQDN (nome de domínio totalmente qualificado) 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 delegação restrita de Kerberos baseada em recursos

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

Você também pode usar a delegação sem restrições Kerberos para fazer 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

Esse método não fornece nenhum controle de onde as credenciais delegadas são usadas. É menos seguro do que o CredSSP. Este método só deve ser usado para testar cenários.

Administração JEA (Just Enough Administration)

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

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

Prós

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

Contras

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

PSSessionConfiguration usando RunAs

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

Para obter informações sobre como usar PSSessionConfiguration e RunAs para resolver o problema do segundo salto, consulte Outra solução para comunicação remota do PowerShell multi-hop.

Prós

  • Funciona com qualquer servidor com WMF 3.0 ou posterior.

Contras

  • Requer configuração de PSSessionConfiguration e 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

Você pode passar credenciais dentro do parâmetro ScriptBlock de uma chamada para o cmdlet Invoke-Command .

Prós

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

Contras

  • Requer uma técnica de código incômoda.
  • Se estiver executando o WMF 2.0, requer 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}
}

Consulte também

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