Partager via

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

Le « problème du second saut » fait référence à une situation semblable à celle-ci :

  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 que vous avez utilisées pour créer la session de communication à distance PowerShell ne sont pas passées de ServerB à ServerC.

Il existe plusieurs façons de résoudre ce problème. Le tableau suivant répertorie les méthodes dans l’ordre de préférence.

Paramétrage Remarque
Crédit SSP Équilibre la facilité d’utilisation et la sécurité
Délégation Kerberos contrainte basée sur les ressources Sécurité plus élevée avec une configuration plus simple
Délégation Kerberos contrainte Haute sécurité, mais nécessite l’administrateur de domaine
Délégation Kerberos (non contrainte) 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 la gestion des informations d’identification
Passer des informations d’identification à l’intérieur d’un Invoke-Command bloc de script Plus simple à utiliser, mais vous devez fournir des informations d’identification

Crédit SSP

Vous pouvez utiliser le fournisseur de support de sécurité des informations d’identification (CredSSP) pour l’authentification. CredSSP met en cache les informations d’identification sur le serveur distant (ServerB), de sorte qu’elle vous ouvre aux attaques par vol d’informations d’identification. 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 se connectant à un contrôleur de domaine, car le contrôleur de domaine est hautement approuvé.

Pour plus d’informations sur les problèmes de sécurité lors de l’utilisation de CredSSP pour la communication à distance PowerShell, consultez Sabotage accidentel : Méfiez-vous de CredSSP.

Pour plus d’informations sur les attaques par vol d’informations d’identification, consultez Atténuation des attaques ptH (Pass-the-Hash) et autres vols d’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

  • Il fonctionne pour tous les serveurs avec Windows Server 2008 ou version ultérieure.

Inconvénients

  • A des vulnérabilités de sécurité.
  • Nécessite 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 Kerberos contrainte avec l’option « Utiliser n’importe quel protocole d’authentification » pour autoriser la transition du protocole.

Avantages

  • Nécessite aucun codage spécial
  • Les informations d’identification ne sont pas stockées.

Inconvénients

  • Ne prend pas en charge le deuxième saut pour WinRM.
  • Nécessite l'accès de l'administrateur de domaine pour la configuration.
  • Doit être configuré sur l’objet Active Directory du serveur distant (ServerB).
  • Limité à un domaine. Impossible de traverser des domaines ou des forêts.
  • Nécessite des droits pour mettre à jour des objets et des noms de principal de service (SPN).
  • ServerB peut acquérir un ticket Kerberos vers ServerC pour le compte de l’utilisateur sans intervention de l’utilisateur.

Remarque

Les comptes Active Directory dont le compte est sensible et ne peuvent pas être délégués ne peuvent pas être délégués. Pour plus d’informations, consultez Focus sur la sécurité : Analyse de « Le compte est sensible et ne peut pas être délégué » pour les comptes privilégiés et les outils et paramètres d’authentification Kerberos.

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

À l’aide de la délégation Kerberos contrainte basée sur des ressources (introduite dans Windows Server 2012), vous configurez la délégation d’informations d’identification sur l’objet serveur où résident les ressources. Dans le deuxième scénario de tronçon décrit ci-dessus, vous configurez ServerC pour spécifier à partir duquel il accepte les informations d’identification déléguées.

Avantages

  • Les informations d’identification ne sont pas stockées.
  • Configuré à l’aide d’applets de commande PowerShell. Aucun codage spécial n’est requis.
  • Ne nécessite pas l’accès administrateur de domaine pour configurer.
  • Fonctionne à travers les domaines et les forêts.

Inconvénients

  • Nécessite Windows Server 2012 ou version ultérieure.
  • Ne prend pas en charge le deuxième saut pour WinRM.
  • Nécessite des droits pour mettre à jour des objets et des noms de principal de service (SPN).

Remarque

Les comptes Active Directory dont le compte est sensible et ne peuvent pas être délégués ne peuvent pas être délégués. Pour plus d’informations, consultez Focus sur la sécurité : Analyse de « Le compte est sensible et ne peut pas être délégué » pour les comptes privilégiés et les outils et paramètres d’authentification Kerberos.

Exemple :

Examinons un exemple PowerShell qui configure la délégation contrainte confinée aux ressources sur ServerC pour autoriser les informations d’identification déléguées depuis 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 chaque domaine approuvé.

Avant de pouvoir configurer la délégation contrainte, vous devez ajouter la RSAT-AD-PowerShell fonctionnalité pour installer le module PowerShell Active Directory, 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, qui contient 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’agit du compte d’ordinateur pour ServerA).

Maintenant, nous allons configurer les variables que nous allons utiliser 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 voir en examinant la propriété StartName du winrm service :

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

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

Pour que ServerC permette la délégation d'une session PowerShell à distance sur ServerB, nous devons configurer le paramètre PrincipalsAllowedToDelegateToAccount sur ServerC à l'objet 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 Kerberos (KDC) met en cache les tentatives d’accès refusé (cache négatif) pendant 15 minutes. Si ServerB a déjà tenté 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 supprimé le cache, vous pouvez exécuter le code de ServerA via ServerB vers 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)
}

Dans cet exemple, le Using: modificateur d’étendue est utilisé pour rendre la $ServerC variable visible par ServerB. Pour plus d’informations sur le modificateur d’étendue Using: , consultez about_Remote_Variables.

Pour autoriser plusieurs serveurs à déléguer des informations d’identification à ServerC, définissez la valeur du paramètre PrincipalsAllowedToDelegateToAccount sur ServerC sur un tableau :

# 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 les domaines, utilisez le paramètre Serveur pour spécifier le nom de domaine complet (FQDN) du contrôleur de domaine 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 des informations d’identification à ServerC, définissez la valeur du paramètre PrincipalsAllowedToDelegateToAccount sur ServerC$nullsur :

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

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

Délégation Kerberos (non contrainte)

Vous pouvez également utiliser la délégation sans contraintes Kerberos pour effectuer le deuxième saut. Comme 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 permet aucun contrôle de l’endroit où les informations d’identification déléguées sont utilisées. Il est moins sécurisé que 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 pendant une session PowerShell. Il peut être utilisé pour résoudre le problème du deuxième saut.

Pour plus d’informations sur JEA, consultez Just Enough Administration.

Avantages

  • Aucune maintenance de mot de passe lors de l’utilisation d’un compte virtuel.

Inconvénients

  • Nécessite WMF 5.0 ou version ultérieure.
  • Nécessite une configuration sur 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 version ultérieure.

Inconvénients

  • Nécessite la configuration de PSSessionConfiguration et d’RunAs sur chaque serveur intermédiaire (ServerB).
  • Nécessite une gestion de mot de passe lors de l’utilisation d’un compte RunAs de domaine

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

Vous pouvez transmettre des informations d’identification dans le paramètre ScriptBlock d’un appel au cmdlet Invoke-Command.

Avantages

  • Ne nécessite pas de configuration de serveur spéciale.
  • Fonctionne sur n’importe quel serveur exécutant WMF 2.0 ou version ultérieure.

Inconvénients

  • Nécessite une technique de code maladroite.
  • Si vous exécutez WMF 2.0, nécessite une syntaxe différente pour passer des arguments à une session distante.

Exemple :

L’exemple suivant montre comment passer 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

  • Last updated on