Creazione del secondo hop nella comunicazione remota di PowerShell

  • Articolo

Il "problema relativo al secondo hop" si riferisce a una situazione simile alla seguente:

  1. Si è connessi al ServerA.
  2. Dal ServerA, si avvia una sessione remota di PowerShell per connettersi al ServerB.
  3. Un comando eseguito nel ServerB tramite la sessione di comunicazione remota di PowerShell prova ad accedere a una risorsa nel ServerC.
  4. L'accesso alla risorsa nel ServerC viene negato perché le credenziali usate per creare la sessione di comunicazione remota di PowerShell non vengono passate da ServerB a ServerC.

Ci sono diversi modi per risolvere questo problema. Nella tabella seguente sono elencati i metodi in ordine di preferenza.

Impostazione Nota
CredSSP Bilancia la semplicità d'uso e la sicurezza
Delega vincolata Kerberos basata sulle risorse Maggiore sicurezza con una configurazione più semplice
Delega vincolata Kerberos Sicurezza elevata, ma richiede un amministratore di dominio
Delega Kerberos (non vincolata) Non consigliata
JEA (Just Enough Administration) Può fornire la maggiore sicurezza ma richiede una configurazione più dettagliata
PSSessionConfiguration tramite RunAs Più semplice da configurare ma richiede la gestione delle credenziali
Passare le credenziali all'interno di un blocco di script Invoke-Command Più semplice da usare ma è necessario fornire le credenziali

CredSSP

È possibile usare Credential Security Support Provider (CredSSP) per l'autenticazione. CredSSP memorizza le credenziali nel server remoto (ServerB), quindi il suo uso potrebbe facilitare il furto di credenziali. Se il computer remoto viene compromesso, l'utente malintenzionato ha accesso alle credenziali dell'utente. Per impostazione predefinita, CredSSP è disabilitato sia nei computer client che nei computer server. È opportuno abilitare CredSSP solo negli ambienti più attendibili. Ad esempio, quando un amministratore di dominio si connette a un controller di dominio perché il controller di dominio è estremamente attendibile.

Per altre informazioni sui problemi di sicurezza relativi all'uso di CredSSP per la comunicazione remota di PowerShell, vedere Accidental Sabotage: Beware of CredSSP (Sabotaggio accidentale: attenzione a CredSSP).

Per altre informazioni sugli attacchi con furto di credenziali, vedere Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft (Mitigazione degli attacchi Pass-the-Hash (PtH) e di altre tecniche per il furto delle credenziali).

Per un esempio di come abilitare e usare CredSSP per la comunicazione remota di PowerShell, vedere Abilitare la funzionalità "secondo hop" di PowerShell con CredSSP.

Vantaggi

  • Funziona per tutti i server con Windows Server 2008 o versione successiva.

Svantaggi

  • Presenta vulnerabilità di sicurezza.
  • Richiede la configurazione dei ruoli client e server.
  • non funziona con il gruppo Utenti protetti. Per altre informazioni, vedere Gruppo di sicurezza Utenti protetti.

Delega vincolata Kerberos

È possibile usare la delega vincolata legacy (non basata sulle risorse) per creare il secondo hop. Configurare la delega vincolata Kerberos con l'opzione "Usa un qualsiasi protocollo di autenticazione" per consentire la transizione di protocollo.

Vantaggi

  • Non richiede codice speciale
  • Le credenziali non vengono archiviate.

Svantaggi

  • Non supporta il secondo hop per WinRM.
  • Richiede l'accesso di amministratore di dominio per la configurazione.
  • Deve essere configurato nell'oggetto di Active Directory del server remoto (ServerB).
  • Limitato a un solo dominio. Non è possibile attraversare domini o foreste.
  • Richiede diritti per aggiornare gli oggetti e i nomi dell'entità servizio (SPN).
  • ServerB può acquisire un ticket Kerberos per ServerC per conto dell'utente senza l'intervento dell'utente.

Nota

Gli account Active Directory con account sensibili e non possono essere delegati . Per altre informazioni, vedere Security Focus: Analisi di "Account sensibile e non può essere delegata" per gli account con privilegi e gli strumenti di autenticazione Kerberos e Impostazioni.

Delega vincolata Kerberos basata sulle risorse

Co l'uso della delega vincolata Kerberos basata sulle risorse (introdotta in Windows Server 2012), si configura la delega delle credenziali nell'oggetto del server dove si trovano le risorse. Nello scenario del secondo hop illustrato in precedenza, si configura il ServerC per specificare da dove vengono accettate le credenziali delegate.

Vantaggi

  • Le credenziali non vengono archiviate.
  • Configurazione con cmdlet di PowerShell. Non è richiesto codice speciale.
  • Non richiede l'accesso a domain Amministrazione istrator per la configurazione.
  • Funziona attraverso domini e foreste.

Svantaggi

  • Richiede Windows Server 2012 o versione successiva.
  • Non supporta il secondo hop per WinRM.
  • Richiede diritti per aggiornare gli oggetti e i nomi dell'entità servizio (SPN).

Nota

Gli account Active Directory con account sensibili e non possono essere delegati . Per altre informazioni, vedere Security Focus: Analisi di "Account sensibile e non può essere delegata" per gli account con privilegi e gli strumenti di autenticazione Kerberos e Impostazioni.

Esempio

Di seguito viene illustrato un esempio di PowerShell che configura una delega vincolata basata sulle risorse nel ServerC per consentire le credenziali delegate dal ServerB. In questo esempio si presuppone che tutti i server eseguano versioni supportate di Windows Server e che sia presente almeno un controller di dominio Windows per ogni dominio attendibile.

Prima di poter configurare la delega vincolata, è necessario aggiungere la funzionalità RSAT-AD-PowerShell per installare il modulo di PowerShell per Active Directory e importare il modulo nella sessione:

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

Molti cmdlet disponibili hanno ora un parametro 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

Il parametro PrincipalsAllowedToDelegateToAccount imposta l'attributo dell'oggetto di Active Directory msDS-AllowedToActOnBehalfOfOtherIdentity, che contiene un elenco di controllo di accesso (ACL). Questo elenco specifica gli account che hanno l'autorizzazione per delegare le credenziali all'account associato (in questo esempio, sarà l'account computer per il ServerA).

A questo punto vengono impostate le variabili da usare per rappresentare i server:

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

WinRM (e di conseguenza la comunicazione remota di PowerShell) viene eseguito come account del computer per impostazione predefinita. È possibile verificarlo esaminando la proprietà StartName del servizio winrm:

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

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

Per il ServerC per consentire la delega da una sessione di comunicazione remota di PowerShell nel ServerB, è necessario impostare il parametro PrincipalsAllowedToDelegateToAccount nel ServerC sull'oggetto computer del 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

Le cache del Centro distribuzione chiavi (KDC) Kerberos hanno negato i tentativi di accesso (cache negativa) per 15 minuti. Se ServerB ha tentato in precedenza di accedere a ServerC, è necessario cancellare la cache in ServerB richiamando il comando seguente:

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

È anche possibile riavviare il computer o attendere almeno 15 minuti per cancellare la cache.

Dopo la cancellazione della cache, è possibile eseguire codice dal ServerA attraverso il ServerB al 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)
}

In questo esempio, la variabile $using viene usata per rendere visibile la variabile $ServerC al ServerB. Per altre informazioni sulla variabile $using, vedere about_Remote_Variables.

Per consentire a più server di delegare le credenziali al ServerC, impostare il valore del parametro PrincipalsAllowedToDelegateToAccount nel ServerC a una matrice:

# 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 si desidera eseguire il secondo hop tra domini, usare il parametro Server per specificare il nome di dominio completo (FQDN) del controller di dominio del dominio a cui appartiene ServerB:

# 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

Per rimuovere l'abilità di delegare le credenziali al ServerC, impostare il valore del parametro PrincipalsAllowedToDelegateToAccount nel ServerC to $null:

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

Informazioni sulla delega vincolata Kerberos basata sulle risorse

Delega Kerberos (non vincolata)

È anche possibile usare la delega kerberos senza vincoli per creare il secondo hop. Analogamente a tutti gli scenari Kerberos, le credenziali non vengono archiviate. Questo metodo non supporta il secondo hop per WinRM.

Avviso

Questo metodo non offre alcun controllo su dove vengono usate le credenziali delegate. È meno sicuro di CredSSP. Questo metodo deve essere usato solo per gli scenari di testing.

JEA (Just Enough Administration)

JEA consente di limitare i comandi che un amministratore può eseguire durante una sessione di PowerShell. Può essere usato per risolvere il problema del secondo hop.

Per informazioni su JEA, vedere Just Enough Administration.

Vantaggi

  • Non richiede nessuna manutenzione delle password quando si usa un account virtuale.

Svantaggi

  • Richiede WMF 5.0 o versione successiva.
  • Richiede la configurazione in ogni server intermedio (ServerB).

PSSessionConfiguration tramite RunAs

È possibile creare una configurazione sessione nel ServerB e impostare il parametro RunAsCredential.

Per informazioni sull'uso di PSSessionConfiguration e RunAs per risolvere il problema del secondo hop, vedere Un'altra soluzione per creare più hop nella comunicazione remota di PowerShell.

Vantaggi

  • Funziona con qualsiasi server che esegue WMF 3.0 o versione successiva.

Svantaggi

  • Richiede la configurazione di PSSessionConfiguration e RunAs in ogni server intermedio (ServerB).
  • Richiede la manutenzione delle password quando si usa un account RunAs di dominio

Passare le credenziali all'interno di un blocco di script Invoke-Command

È possibile passare le credenziali all'interno del parametro ScriptBlock di una chiamata al cmdlet Invoke-Command.

Vantaggi

  • Non richiede una configurazione speciale del server.
  • Funziona in qualsiasi server che esegue WMF 2.0 o versione successiva.

Svantaggi

  • Richiede una tecnica di codice complicata.
  • Se si esegue WMF 2.0, richiede una sintassi diversa per passare gli argomenti a una sessione remota.

Esempio

L'esempio seguente illustra come passare le credenziali in un blocco di 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}
}

Vedi anche

Considerazioni sulla sicurezza della comunicazione remota di PowerShell