Dando o segundo salto na Comunicação Remota do PowerShellMaking the second hop in PowerShell Remoting

O "problema do segundo salto" refere-se a uma situação semelhante ao seguinte:The "second hop problem" refers to a situation like the following:

  1. Você está conectado no ServerA.You are logged in to ServerA.
  2. No ServerA, você inicia uma sessão remota do PowerShell para se conectar ao ServerB.From ServerA, you start a remote PowerShell session to connect to 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.A command you run on ServerB via your PowerShell Remoting session attempts to access a resource on ServerC.
  4. O acesso ao recurso no ServerC é 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.Access to the resource on ServerC is denied, because the credentials you used to create the PowerShell Remoting session are not passed from ServerB to ServerC.

Há várias maneiras de resolver esse problema.There are several ways to address this problem. Neste tópico, vamos examinar várias soluções mais comuns para o problema do segundo salto.In this topic, we'll look at several of the most popular solutions to the second hop problem.

CredSSPCredSSP

Você pode usar o CredSSP (Credential Security Support Provider) para autenticação.You can use the Credential Security Support Provider (CredSSP) for authentication. O CredSSP armazena em cache as credenciais no servidor remoto (ServerB), portanto, usá-lo abre para ataques de roubo de credenciais.CredSSP caches credentials on the remote server (ServerB), so using it opens you up to credential theft attacks. Se o computador remoto estiver comprometido, o invasor terá acesso às credenciais do usuário.If the remote computer is compromised, the attacker has access to the user's credentials. O CredSSP é desabilitado por padrão nos computadores cliente e servidor.CredSSP is disabled by default on both client and server computers. Você só deve habilitar o CredSSP nos ambientes mais confiáveis.You should enable CredSSP only in the most trusted environments. 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.For example, a domain administrator connecting to a domain controller because the domain controller is highly trusted.

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).For more information about security concerns when using CredSSP for PowerShell Remoting, see Accidental Sabotage: Beware of CredSSP.

Para obter mais informações sobre ataques de roubo de credenciais, consulte Mitigando ataques PtH (Pass-the-Hash) e outro roubo de credenciais.For more information about credential theft attacks, see Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft.

Para obter um exemplo de como habilitar e usar o CredSSP para a Comunicação Remota do PowerShell, consulte Usando o CredSSP para resolver o problema do segundo salto.For an example of how to enable and use CredSSP for PowerShell remoting, see Using CredSSP to solve the second-hop problem.

VantagensPros

  • Ele funciona para todos os servidores com o Windows Server 2008 ou posterior.It works for all servers with Windows Server 2008 or later.

DesvantagensCons

  • Tem vulnerabilidades de segurança.Has security vulnerabilities.
  • Requer a configuração de funções de cliente e servidor.Requires configuration of both client and server roles.

Delegação Kerberos (irrestrita)Kerberos delegation (unconstrained)

Você pode também pode usar a delegação Kerberos irrestrita para realizar o segundo salto.You can also used Kerberos unconstrained delegation to make the second hop. No entanto, esse método não fornece controle de onde as credenciais delegadas são usadas.However, this method provides no control of where delegated credentials are used.

Observação: As contas do Active Directory que têm a propriedade Conta sensível à segurança não pode ser delegada definida, não podem ser delegadas.Note: Active Directory accounts that have the Account is sensitive and cannot be delegated property set cannot be delegated. Para obter mais informações, consulte Foco de Segurança: analisando 'Conta sensível à segurança não pode ser delegada' para Contas Privilegiadas e Configurações e Ferramentas da Autenticação KerberosFor more information, see Security Focus: Analysing 'Account is sensitive and cannot be delegated' for Privileged Accounts and Kerberos Authentication Tools and Settings

VantagensPros

  • Não exige nenhuma codificação especial.Requires no special coding.

DesvantagensCons

  • Não oferece suporte ao segundo salto para o WinRM.Does not support the second hop for WinRM.
  • Não fornece controle sobre onde as credenciais são usadas, criando uma vulnerabilidade de segurança.Provides no control over where credentials are used, creating a security vulnerability.

Delegação restrita de KerberosKerberos constrained delegation

Você pode usar a delegação restrita herdada (não baseada em recursos) para realizar o segundo salto.You can use legacy constrained delegation (not resource-based) to make the second hop.

Observação: As contas do Active Directory que têm a propriedade Conta sensível à segurança não pode ser delegada definida, não podem ser delegadas.Note: Active Directory accounts that have the Account is sensitive and cannot be delegated property set cannot be delegated. Para obter mais informações, consulte Foco de Segurança: analisando 'Conta sensível à segurança não pode ser delegada' para Contas Privilegiadas e Configurações e Ferramentas da Autenticação KerberosFor more information, see Security Focus: Analysing 'Account is sensitive and cannot be delegated' for Privileged Accounts and Kerberos Authentication Tools and Settings

VantagensPros

  • Não exige nenhuma codificação especialRequires no special coding

DesvantagensCons

  • Não oferece suporte ao segundo salto para o WinRM.Does not support the second hop for WinRM.
  • Deve ser configurada no objeto do Active Directory do servidor remoto (ServerB).Must be configured on the Active Directory object of the remote server (ServerB).
  • Limitado a um domínio.Limited to one domain. Não pode cruzar domínios ou florestas.Cannot cross domains or forests.
  • Requer direitos para atualizar objetos e SPNs (Nomes de Entidade de Serviço).Requires rights to update objects and Service Principal Names (SPNs).

Delegação restrita de Kerberos com base em recursosResource-based Kerberos constrained delegation

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.Using resource-based Kerberos constrained delegation (introduced in Windows Server 2012), you configure credential delegation on the server object where resources reside. No cenário de segundo salto descrito acima, você configura o ServerC para especificar de onde ele aceitará as credenciais delegadas.In the second hop scenario described above, you configure ServerC to specify from where it will accept delegated credentials.

Observação: As contas do Active Directory que têm a propriedade Conta sensível à segurança não pode ser delegada definida, não podem ser delegadas.Note: Active Directory accounts that have the Account is sensitive and cannot be delegated property set cannot be delegated. Para obter mais informações, consulte Foco de Segurança: analisando 'Conta sensível à segurança não pode ser delegada' para Contas Privilegiadas e Configurações e Ferramentas da Autenticação KerberosFor more information, see Security Focus: Analysing 'Account is sensitive and cannot be delegated' for Privileged Accounts and Kerberos Authentication Tools and Settings

VantagensPros

  • As credenciais não são armazenadas.Credentials are not stored.
  • É relativamente fácil de configurar usando cmdlets do PowerShell – não é necessária nenhuma codificação especial.Relatively easy to configure by using PowerShell cmdlets--no special coding required.
  • Não é necessário acesso de domínio especial.No special domain access is required.
  • Funciona entre domínios e florestas.Works across domains and forests.
  • Código do PowerShell.PowerShell code.

DesvantagensCons

  • Requer o Windows Server 2012 ou posterior.Requires Windows Server 2012 or later.
  • Não oferece suporte ao segundo salto para o WinRM.Does not support the second hop for WinRM.
  • Requer direitos para atualizar objetos e SPNs (Nomes de Entidade de Serviço).Requires rights to update objects and Service Principal Names (SPNs).

ExemploExample

Vejamos um exemplo do PowerShell que configura a delegação restrita baseada em recursos no ServerC para permitir credenciais delegadas de um ServerB.Let's look at a PowerShell example that configures resource based constrained delegation on ServerC to allow delegated credentials from a ServerB. Este exemplo pressupõe que todos os servidores estão executando o Windows Server 2012 ou posterior, e que há pelo menos um controlador de domínio do Windows Server 2012 em cada domínio aos quais os servidores pertencem.This example assumes that all servers are running Windows Server 2012 or later, and that there is at least one Windows Server 2012 domain controller each domain to which any of the servers belong.

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:Before you can configure constrained delegation, you must add the RSAT-AD-PowerShell feature to install the Active Directory PowerShell module, and then import that module into your session:

PS C:\> Add-WindowsFeature RSAT-AD-PowerShell

PS C:\> Import-Module ActiveDirector

Vários cmdlets disponíveis agora têm um parâmetro PrincipalsAllowedToDelegateToAccount:Several available cmdlets now have a PrincipalsAllowedToDelegateToAccount parameter:

PS C:\> Get-Command -ParameterName 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 controle de acesso (ACL) que especifica as contas que têm permissão para delegar credenciais para a conta associada (no nosso exemplo, será a conta do computador para Servidor).The PrincipalsAllowedToDelegateToAccount parameter sets the Active Directory object attribute msDS-AllowedToActOnBehalfOfOtherIdentity, which contains an access control list (ACL) that specifies which accounts have permission to delegate credentials to the associated account (in our example, it will be the machine account for Server).

Agora vamos configurar as variáveis que usaremos para representar os servidores:Now let's set up the variables we'll use to represent the servers:

# 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.WinRM (and therefore PowerShell remoting) runs as the computer account by default. Você pode ver isso examinando a propriedade StartName do serviço winrm:You can see this by looking at the StartName property of the winrm service:

PS C:\> Get-WmiObject win32_service -filter 'name="winrm"' | Format-List 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, vamos conceder acesso ao definir o parâmetro PrincipalsAllowedToDelegateToAccount no ServerC para o objeto de computador do ServerB:For ServerC to allow delegation from a PowerShell remoting session on ServerB, we will grant access by setting the PrincipalsAllowedToDelegateToAccount parameter on ServerC to the computer object of 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 Kerberos KDC (Centro de distribuição de chaves) armazena em cache as tentativas de acesso negado (cache negativo) por 15 minutos.The Kerberos Key Distribution Center (KDC) caches denied access attempts (negative cache) for 15 minutes. Se ServerB tentou acessar anteriormente o ServerC, será necessário limpar o cache no ServerB invocando o seguinte comando:If ServerB has previously attempted to access ServerC, you will need to clear the cache on ServerB by invoking the following command:

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.You could also restart the computer, or wait at least 15 minutes to clear the cache.

Depois de limpar o cache, é possível executar com êxito o código do ServerA por meio do ServerB no ServerC:After clearing the cache, you can successfully run code from ServerA through ServerB to 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.In this example, the $using variable is used to make the $ServerC variable visible to ServerB. Para obter mais informações sobre a variável $using, consulte about_Remote_Variables.For more information about the $using variable, see 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:To allow multiple servers to delegate credentials to ServerC, set the value of the PrincipalsAllowedToDelegateToAccount parameter on ServerC to an array:

# 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            

# Grant resource-based Kerberos constrained delegation            
Set-ADComputer -Identity $ServerC `
    -PrincipalsAllowedToDelegateToAccount @($ServerB1,$ServerB2,$ServerB3)

Se você quiser realizar o segundo salto entre domínios, adicione o FQDN (nome de domínio totalmente qualificado) do controlador de domínio do domínio ao qual o ServerB pertence:If you want to make the second hop across domains, add fully-qualified domain name (FQDN) of the domain controller of the domain to which ServerB belongs:

# 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:To remove the ability to delegate credentials to ServerC, set the value of the PrincipalsAllowedToDelegateToAccount parameter on ServerC to $null:

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

Informações sobre delegação restrita de Kerberos baseada em recursosInformation on resource-based Kerberos constrained delegation

PSSessionConfiguration usando RunAsPSSessionConfiguration using RunAs

Você pode criar uma configuração de sessão no ServerB e definir o parâmetro RunAsCredential.You can create a session configuration on ServerB and set its RunAsCredential parameter.

Para obter informações sobre como usar PSSessionConfiguration e RunAs para resolver o problema do segundo salto, consulte Outra solução para a comunicação remota de saltos múltiplos do PowerShell.For information about using PSSessionConfiguration and RunAs to solve the second hop problem, see Another solution to multi-hop PowerShell remoting.

VantagensPros

  • Funciona com qualquer servidor com o WMF 3.0 ou posterior.Works with any server with WMF 3.0 or later.

DesvantagensCons

  • Requer a configuração de PSSessionConfiguration e de RunAs em cada servidor intermediário (ServerB).Requires configuration of PSSessionConfiguration and RunAs on every intermediate server (ServerB).
  • Requer manutenção de senha ao usar uma conta RunAs de domínioRequires password maintenance when using a domain RunAs account

JEA (Administração Just Enough)Just Enough Administration (JEA)

O JEA permite restringir os comandos que um administrador pode executar durante uma sessão do PowerShell.JEA allows you to restrict what commands an administrator can run during a PowerShell session. Pode ser usado para resolver o problema do segundo salto.It can be used to solve the second hop problem.

Para obter informações sobre o JEA, consulte Just Enough Administration.For information about JEA, see Just Enough Administration.

VantagensPros

  • Não necessita manutenção de senha ao usar uma conta virtual.No password maintenance when using a virtual account.

DesvantagensCons

  • Requer o WMF 5.0 ou posterior.Requires WMF 5.0 or later.
  • Requer a configuração em cada servidor intermediário (ServerB).Requires configuration on every intermediate server (ServerB).

Passar credenciais dentro de um bloco de script Invoke-CommandPass credentials inside an Invoke-Command script block

É possível passar credenciais dentro do parâmetro ScriptBlock de uma chamada do cmdlet Invoke-Command.You can pass credentials inside the ScriptBlock parameter of a call to the Invoke-Command cmdlet.

VantagensPros

  • Não requer configuração especial do servidor.Does not require special server configuration.
  • Funciona em qualquer servidor que executa o WMF 2.0 ou posterior.Works on any server running WMF 2.0 or later.

DesvantagensCons

  • Requer uma técnica de código complicada.Requires an awkward code technique.
  • Se estiver executando o WMF 2.0, necessita de uma sintaxe diferente para passar argumentos para uma sessão remota.If running WMF 2.0, requires different syntax for passing arguments to a remote session.

ExemploExample

O exemplo a seguir mostra como passar credenciais em um bloco de script Invoke-Command:The following example shows how to pass credentials in an Invoke-Command script block:

# 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émSee also

Considerações de segurança de comunicação remota do PowerShellPowerShell Remoting Security Considerations