Condividi tramite

Creazione del secondo hop nella comunicazione remota di PowerShell

Il "problema del secondo hop" si riferisce a una situazione come la seguente:

  1. Si è connessi a 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.

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

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

CredSSP

È possibile usare il provider di supporto per la sicurezza delle credenziali (CredSSP) per l'autenticazione. CredSSP memorizza nella cache le credenziali nel server remoto (ServerB), quindi l'uso consente di aprire attacchi di 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, un amministratore di dominio che si connette a un controller di dominio perché il controller di dominio è altamente attendibile.

Per altre informazioni sui problemi di sicurezza quando si usa CredSSP per la comunicazione remota di PowerShell, vedere Sabotage accidentale: Beware of CredSSP.

Per altre informazioni sugli attacchi di furto di credenziali, vedere Mitigazione degli attacchi Pass-the-Hash (PtH) e altri furti di 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 Kerberos vincolata

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

Vantaggi

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

Svantaggi

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

Nota

Gli account di Active Directory che hanno la proprietà Account sensibile e non può essere delegato impostata non possono essere delegati. Per altre informazioni, vedere Focus sulla sicurezza: Analisi di "Account sensibile e non può essere delegata" per gli account con privilegi e gli strumenti e le impostazioni di autenticazione Kerberos.

Delega Kerberos vincolata basata sulle risorse

Usando la delega vincolata Kerberos basata su risorse (introdotta in Windows Server 2012), si configura la delega delle credenziali nell'oggetto server in cui risiedono le risorse. Nel secondo scenario hop descritto in precedenza si configura ServerC per specificare da dove accetta credenziali delegate.

Vantaggi

  • Le credenziali non vengono archiviate.
  • Configurato usando i cmdlet di PowerShell. Non è necessario alcun codice speciale.
  • Non richiede l'accesso amministratore di dominio per la configurazione.
  • Funziona tra 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 gli Service Principal Names (SPNs).

Nota

Gli account di Active Directory che hanno la proprietà Account sensibile e non può essere delegato impostata non possono essere delegati. Per altre informazioni, vedere Focus sulla sicurezza: Analisi di "Account sensibile e non può essere delegata" per gli account con privilegi e gli strumenti e le impostazioni di autenticazione Kerberos.

Esempio

Di seguito è riportato un esempio di PowerShell che configura la delega vincolata basata su risorse nel ServerC per consentire le credenziali delegate da un 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 RSAT-AD-PowerShell funzionalità per installare il modulo PowerShell di Active Directory e quindi importare il modulo nella sessione:

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

Diversi 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 Active Directory msDS-AllowedToActOnBehalfOfOtherIdentity, che contiene un elenco di controllo di accesso (ACL) che specifica quali account dispongono dell'autorizzazione per delegare le credenziali all'account associato (in questo esempio sarà l'account computer per ServerA).

A questo punto verranno configurate le variabili che verranno usate per rappresentare i server:

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

WinRM (e quindi il remoting di PowerShell) viene eseguito come account del computer per impostazione predefinita. Per visualizzare questo aspetto, vedere la proprietà StartName del winrm servizio:

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

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

Affinché ServerC consenta la delega da una sessione remota di PowerShell nel ServerB, è necessario impostare il parametro PrincipalsAllowedToDelegateToAccount su ServerC sull'oggetto computer di 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

La cache KDC (Kerberos Key Distribution Center) memorizza nella cache i tentativi di accesso negato (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 aver cancellato la cache, è possibile eseguire correttamente il codice da ServerA tramite ServerB a 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 viene usato il Using: modificatore di ambito per rendere visibile la $ServerC variabile a ServerB. Per altre informazioni sul modificatore di Using: ambito, vedere about_Remote_Variables.

Per consentire a più server di delegare le credenziali a ServerC, impostare il valore del parametro PrincipalsAllowedToDelegateToAccount in ServerC su 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 la possibilità di delegare le credenziali a ServerC, impostare il valore del parametro PrincipalsAllowedToDelegateToAccount in ServerC su $null:

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

Informazioni sulla delega vincolata Kerberos basata sulle risorse

Delega Kerberos (senza vincoli)

È anche possibile usare la delegazione 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.

Avvertimento

Questo metodo non fornisce alcun controllo sulla posizione in cui vengono usate le credenziali delegate. È meno sicuro di CredSSP. Questo metodo deve essere usato solo per gli scenari di test.

JEA (Just Enough Administration)

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

Per informazioni su JEA, vedere Just Enough Administration.

Vantaggi

  • 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 con RunAs

È possibile creare una configurazione di sessione in ServerB e impostarne il parametro RunAsCredential .

Per informazioni sull'uso di PSSessionConfiguration e RunAs per risolvere il problema del secondo hop, vedere Altra soluzione per il remoting multi-hop di PowerShell.

Vantaggi

  • Funziona con qualsiasi server con 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 imbarazzante.
  • Se si esegue WMF 2.0, è necessaria una sintassi diversa per passare 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}
}

Vedere anche

Considerazioni sulla sicurezza remota di PowerShell