Partager via

Effectuer le deuxième saut dans la communication à distance PowerShell

  • Article

Le « problème du deuxième saut » fait référence à une situation de ce type :

  1. Vous êtes connecté à ServerA.
  2. À partir de ServerA, vous démarrez une session PowerShell à distance pour vous connecter à ServerB.
  3. Une commande exécutée sur ServerB via votre session de communication à distance PowerShell tente d’accéder à une ressource sur ServerC.
  4. L’accès à la ressource sur ServerC est refusé, car les informations d’identification utilisées pour créer la session de communication à distance PowerShell ne sont pas transmises de ServerB à ServerC.

Il existe plusieurs moyens de résoudre ce problème. Le tableau suivant répertorie les méthodes par ordre de préférence.

Configuration Remarque
CredSSP Équilibre la facilité d’utilisation et la sécurité
Délégation Kerberos contrainte basée sur les ressources Sécurité accrue avec une configuration plus simple
Délégation Kerberos contrainte Sécurité élevée, mais nécessite un administrateur de domaine
Délégation Kerberos (sans contraintes) Non recommandé
Just Enough Administration (JEA) Peut fournir la meilleure sécurité, mais nécessite une configuration plus détaillée
PSSessionConfiguration avec la commande RunAs Plus simple à configurer mais nécessite une gestion des informations d’identification
Transmettre des informations d’identification à l’intérieur d’un bloc de script Invoke-Command La méthode la plus simple à utiliser, mais vous devez fournir des informations d’identification

CredSSP

Vous pouvez utiliser le protocole CredSSP (Credential Security Support Provider) pour l’authentification. Le protocole CredSSP mettant en cache les informations d’identification sur le serveur distant (ServerB), son utilisation vous expose à des risques de vol de ces informations. Si l’ordinateur distant est compromis, la personne malveillante a accès aux informations d’identification de l’utilisateur. CredSSP est désactivé par défaut sur les ordinateurs clients et serveurs. Vous devez activer CredSSP uniquement dans les environnements les plus approuvés, Par exemple un administrateur de domaine qui se connecte à un contrôleur de domaine, car le contrôleur de domaine est hautement approuvé.

Pour plus d’informations sur les questions de sécurité lors de l’utilisation de CredSSP pour la communication à distance PowerShell, voir Accidental Sabotage: Beware of CredSSP.

Pour plus d’informations sur les risques de vol des informations d’identification, voir Atténuation des attaques PtH (Pass-The-Hash) et autres risques de vol des informations d’identification.

Pour accéder à un exemple montrant comment activer et utiliser CredSSP pour la communication à distance PowerShell, consultez Activer la fonctionnalité « deuxième saut » de PowerShell avec CredSSP.

Avantages

  • Fonctionne pour tous les serveurs avec Windows Server 2008 ou une version ultérieure.

Inconvénients

  • Présente des failles de sécurité.
  • Requiert la configuration des rôles client et serveur.
  • ne fonctionne pas avec le groupe Utilisateurs protégés. Pour plus d’informations, consultez Groupe de sécurité Utilisateurs protégés.

Délégation Kerberos contrainte

Vous pouvez utiliser la délégation contrainte héritée (non basée sur les ressources) pour effectuer le deuxième saut. Configurez la délégation contrainte Kerberos avec l’option « Utiliser tout protocole d’authentification » pour permettre la transition du protocole.

Avantages

  • Ne requiert pas de programmation particulière.
  • Les informations d’identification ne sont pas stockées.

Inconvénients

  • Ne prend pas en charge le deuxième tronçon pour WinRM.
  • Nécessite un accès Administrateur de domaine pour la configuration.
  • Doit être configuré sur l’objet Active Directory du serveur distant (ServerB).
  • Limité à un serveur. Ne peut pas croiser des domaines ou des forêts.
  • Requiert des droits pour mettre à jour les objets et le nom des principaux du service (SPN).
  • ServerB peut acquérir un ticket Kerberos pour ServerC au nom de l’utilisateur sans intervention de l’utilisateur.

Remarque

Les comptes Active Directory ayant l’ensemble de propriétés Le compte est sensible et ne peut pas être délégué ne peuvent pas être délégués. Pour obtenir plus d’informations, consultez Priorité à la sécurité : analyser « Le compte est sensible et ne peut pas être délégué » pour les comptes privilégiés et Paramètres et outils d’authentification Kerberos.

Délégation Kerberos contrainte basée sur les ressources

La délégation Kerberos contrainte basée sur les ressources (introduite dans Windows Server 2012) permet de configurer la délégation des informations d’identification sur l’objet serveur où résident les ressources. Dans le scénario du deuxième saut décrit ci-dessus, vous configurez ServerC pour spécifier l’emplacement où il accepte les informations d’identification déléguées.

Avantages

  • Les informations d’identification ne sont pas stockées.
  • Configuration effectuée à l’aide des cmdlets PowerShell. Pas de programmation particulière requise.
  • Ne nécessite pas d’accès Administrateur de domaine pour la configuration.
  • Fonctionne à travers des domaines et des forêts.

Inconvénients

  • Requiert Windows Server 2012 ou une version ultérieure.
  • Ne prend pas en charge le deuxième tronçon pour WinRM.
  • Requiert des droits pour mettre à jour les objets et le nom des principaux du service (SPN).

Remarque

Les comptes Active Directory ayant l’ensemble de propriétés Le compte est sensible et ne peut pas être délégué ne peuvent pas être délégués. Pour obtenir plus d’informations, consultez Priorité à la sécurité : analyser « Le compte est sensible et ne peut pas être délégué » pour les comptes privilégiés et Paramètres et outils d’authentification Kerberos.

Exemple

Examinons un exemple PowerShell qui configure la délégation contrainte basée sur les ressources sur ServerC de façon à autoriser les informations d’identification déléguées à partir d’un ServerB. Cet exemple suppose que tous les serveurs exécutent des versions prises en charge de Windows Server et qu’il existe au moins un contrôleur de domaine Windows pour chacun des domaines approuvés.

Pour pouvoir configurer la délégation contrainte, vous devez ajouter la fonctionnalité RSAT-AD-PowerShell afin d’installer le module Active Directory PowerShell, puis importer ce module dans votre session :

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

Plusieurs applets de commande disponibles ont désormais un paramètre 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

Le paramètre PrincipalsAllowedToDelegateToAccount définit l’attribut d’objet Active Directory msDS-AllowedToActOnBehalfOfOtherIdentity contenant une liste de contrôle d’accès (ACL) qui spécifie quels comptes ont l’autorisation de déléguer les informations d’identification au compte associé (dans notre exemple, il s’agira du compte d’ordinateur de ServerA).

Nous allons maintenant définir les variables que nous utiliserons pour représenter les serveurs :

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

WinRM (et par conséquent la communication à distance PowerShell) s’exécute en tant que compte d’ordinateur par défaut. Vous pouvez le constater en examinant la propriété StartName du service winrm :

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

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

Pour que ServerC autorise la délégation à partir d’une session de communication à distance PowerShell sur ServerB, nous devons définir le paramètre PrincipalsAllowedToDelegateToAccount sur ServerC sur l’objet d’ordinateur de 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 Centre de distribution de clés (KDC) Kerberos met en cache les tentatives d’accès refusées (cache négatif) pendant 15 minutes. Si ServerB a précédemment essayé d’accéder à ServerC, vous devez effacer le cache sur ServerB en appelant la commande suivante :

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

Vous pouvez également redémarrer l’ordinateur, ou attendre au moins 15 minutes pour effacer le cache.

Après avoir vidé le cache, vous pouvez exécuter le code de ServerA à ServerC via ServerB :

# 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)
}

Dans cet exemple, la variable $using est utilisée pour rendre la variable $ServerC visible pour ServerB. Pour plus d’informations sur la variable $using, consultez about_Remote_Variables.

Pour permettre à plusieurs serveurs de déléguer les informations d’identification à ServerC, donnez comme valeur un tableau au paramètre PrincipalsAllowedToDelegateToAccount sur ServerC :

# 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

Si vous souhaitez effectuer le deuxième tronçon entre domaines, utilisez le paramètre Serveur pour spécifier un nom de domaine complet (FQDN) du contrôleur du domaine auquel ServerB appartient :

# 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

Pour supprimer la possibilité de déléguer les informations d’identification à ServerC, donnez comme valeur $null au paramètre PrincipalsAllowedToDelegateToAccount sur ServerC :

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

Informations sur la délégation Kerberos contrainte basée sur les ressources

Délégation Kerberos (sans contraintes)

Vous pouvez également utiliser la délégation sans contrainte Kerberos pour effectuer le deuxième tronçon. Comme dans tous les scénarios Kerberos, les informations d’identification ne sont pas stockées. Cette méthode ne prend pas en charge le deuxième tronçon pour WinRM.

Avertissement

Cette méthode ne fournit aucun contrôle sur l’utilisation des informations d’identification déléguées. Elle est moins sécurisée que la méthode CredSSP. Cette méthode ne doit être utilisée que pour les scénarios de test.

Just Enough Administration (JEA)

JEA vous permet de restreindre les commandes qu’un administrateur peut exécuter au cours d’une session PowerShell. Il peut être utilisé pour résoudre le problème du deuxième saut.

Pour plus d’informations sur JEA, consultez Juste assez d’administration.

Avantages

  • Aucune maintenance des mots de passe lorsque vous utilisez un compte virtuel.

Inconvénients

  • Nécessite WMF 5.0 ou une version ultérieure.
  • Requiert la configuration de chaque serveur intermédiaire (ServerB).

PSSessionConfiguration avec la commande RunAs

Vous pouvez créer une configuration de session sur ServerB et définir son paramètre RunAsCredential.

Pour plus d’informations sur l’utilisation de PSSessionConfiguration et de RunAs afin de résoudre le problème du deuxième saut, consultez Autre solution de communication à distance PowerShell sur plusieurs sauts.

Avantages

  • Fonctionne avec n’importe quel serveur avec WMF 3.0 ou une version ultérieure.

Inconvénients

  • Nécessite la configuration de PSSessionConfiguration et de RunAs sur chaque serveur intermédiaire (ServerB).
  • Nécessite la maintenance des mots de passe lorsqu’un compte de domaine RunAs est utilisé

Transmettre des informations d’identification à l’intérieur d’un bloc de script Invoke-Command

Vous pouvez transmettre des informations d’identification à l’intérieur du paramètre ScriptBlock d’un appel à l’applet de commande Invoke-Command.

Avantages

  • Ne nécessite pas de configuration particulière du serveur.
  • Fonctionne sur n’importe quel serveur exécutant WMF 2.0 ou une version ultérieure.

Inconvénients

  • Nécessite une technique de programmation délicate.
  • Si vous exécutez WMF 2.0, requiert une syntaxe différente pour transmettre des arguments à une session à distance.

Exemple

L’exemple suivant montre comment transmettre des informations d’identification dans un bloc 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}
}

Voir aussi

Éléments à prendre en compte en matière de sécurité de la communication à distance PowerShell