Configurations de session JEA

Un point de terminaison JEA est inscrit sur un système en créant et en inscrivant un fichier de configuration de session PowerShell. Les configurations de session définissent qui peut utiliser le point de terminaison JEA et les rôles auxquels ils ont accès. Ils définissent également des paramètres globaux qui s’appliquent à tous les utilisateurs de la session JEA.

Créer un fichier de configuration de session

Pour inscrire un point de terminaison JEA, vous devez spécifier la façon dont ce point de terminaison est configuré. Il existe de nombreuses options à prendre en compte. Les options les plus importantes sont les suivantes :

• Qui a accès au point de terminaison JEA
• Rôles auxquels ils peuvent être attribués
• Quelle identité JEA utilise sous les couvertures
• Nom du point de terminaison JEA

Ces options sont définies dans un fichier de données PowerShell avec une .pssc extension appelée fichier de configuration de session PowerShell. Le fichier de configuration de session peut être modifié à l’aide de n’importe quel éditeur de texte.

Exécutez la commande suivante pour créer un fichier de configuration de modèle vide.

New-PSSessionConfigurationFile -SessionType RestrictedRemoteServer -Path .\MyJEAEndpoint.pssc

Le -SessionType RestrictedRemoteServer champ indique que la configuration de session est utilisée par JEA pour la gestion sécurisée. Les sessions de ce type fonctionnent en mode NoLanguage et ont uniquement accès aux commandes par défaut suivantes (et alias) :

• Clear-Host (cls, clear)
• Exit-PSSession (exsn, exit)
• Get-Command (gcm)
• Get-FormatData
• Get-Help
• Measure-Object (measure)
• Out-Default
• Select-Object (select)

Aucun fournisseur PowerShell n’est disponible, ni aucun programme externe (exécutables ou scripts).

Pour plus d’informations sur les modes linguistiques, consultez about_Language_Modes.

Choisir l’identité JEA

En arrière-plan, JEA a besoin d’une identité (compte) à utiliser lors de l’exécution des commandes d’un utilisateur connecté. Vous définissez l’identité que JEA utilise dans le fichier de configuration de session.

Compte virtuel local

Les comptes virtuels locaux sont utiles lorsque tous les rôles définis pour le point de terminaison JEA sont utilisés pour gérer l’ordinateur local et qu’un compte d’administrateur local suffit pour exécuter les commandes avec succès. Les comptes virtuels sont des comptes temporaires uniques à un utilisateur spécifique et uniquement pour la durée de leur session PowerShell. Sur un serveur membre ou une station de travail, les comptes virtuels appartiennent au groupe Administrateurs de l’ordinateur local. Sur un contrôleur de domaine Active Directory, les comptes virtuels appartiennent au groupe Administrateurs de domaine du domaine.

# Setting the session to use a virtual account
RunAsVirtualAccount = $true

Si les rôles définis par la configuration de session ne nécessitent pas de privilège d’administration complet, vous pouvez spécifier les groupes de sécurité auxquels appartient le compte virtuel. Sur un serveur membre ou une station de travail, les groupes de sécurité spécifiés doivent être des groupes locaux, et non des groupes d’un domaine.

Quand un ou plusieurs groupes de sécurité sont spécifiés, le compte virtuel n’est pas affecté au groupe administrateurs local ou de domaine.

# Setting the session to use a virtual account that only belongs to the NetworkOperator and NetworkAuditor local groups
RunAsVirtualAccount = $true
RunAsVirtualAccountGroups = 'NetworkOperator', 'NetworkAuditor'

Compte de service géré par groupe

Un compte de service géré par un groupe (GMSA) est l’identité appropriée à utiliser lorsque les utilisateurs JEA doivent accéder aux ressources réseau telles que les partages de fichiers et les services web. Les GMSA vous donnent une identité de domaine utilisée pour s’authentifier auprès des ressources sur n’importe quel ordinateur du domaine. Les droits qu’un GMSA fournit sont déterminés par les ressources auxquelles vous accédez. Vous n’avez pas de droits d’administrateur sur des ordinateurs ou services, sauf si l’administrateur de machine ou de service a explicitement accordé ces droits à GMSA.

# Configure JEA sessions to use the GMSA in the local computer's domain
# with the sAMAccountName of 'MyJEAGMSA'
GroupManagedServiceAccount = 'Domain\MyJEAGMSA'

Les GMSA ne doivent être utilisés que si nécessaire :

• Il est difficile de retracer les actions à un utilisateur lors de l’utilisation d’un GMSA. Chaque utilisateur partage la même identité d'exécution. Vous devez passer en revue les transcriptions et journaux de session PowerShell pour mettre en corrélation les utilisateurs individuels avec leurs actions.

• Le GMSA peut avoir accès à de nombreuses ressources réseau auxquelles l’utilisateur connecté n’a pas besoin d’accéder. Essayez toujours de limiter les autorisations effectives dans une session JEA pour suivre le principe du privilège minimum.

Pour plus d’informations sur la sécurisation d’une session JEA, consultez l’article sur les considérations de sécurité .

Transcriptions de session

Il est recommandé de configurer un point de terminaison JEA pour enregistrer automatiquement les transcriptions des sessions des utilisateurs. Les transcriptions de session PowerShell contiennent des informations sur l’utilisateur qui se connecte, l’identification en tant qu’identité qui lui est attribuée et les commandes exécutées par l’utilisateur. Ils peuvent être utiles à une équipe d’audit qui doit comprendre qui a apporté une modification spécifique à un système.

Pour configurer la transcription automatique dans le fichier de configuration de session, fournissez un chemin d’accès à un dossier dans lequel les transcriptions doivent être stockées.

TranscriptDirectory = 'C:\ProgramData\JEAConfiguration\Transcripts'

Les transcriptions sont écrites dans le dossier par le compte système local , ce qui nécessite un accès en lecture et en écriture au répertoire. Les utilisateurs standard ne doivent pas avoir accès au dossier. Limitez le nombre d’administrateurs de sécurité qui ont accès à l’audit des transcriptions.

Disque de l'utilisateur

Si vos utilisateurs connectés doivent copier des fichiers vers ou à partir du point de terminaison JEA, vous pouvez activer le lecteur utilisateur dans le fichier de configuration de session. Le lecteur utilisateur est un PSDrive mappé à un dossier unique pour chaque utilisateur connecté. Ce dossier permet aux utilisateurs de copier des fichiers vers ou depuis le système sans leur donner accès au système de fichiers complet ou exposer le fournisseur FileSystem. Le contenu du lecteur utilisateur est persistant entre les sessions pour prendre en charge les situations où la connectivité réseau peut être interrompue.

MountUserDrive = $true

Par défaut, le lecteur utilisateur vous permet de stocker un maximum de 50 Mo de données par utilisateur. Vous pouvez limiter la quantité de données qu’un utilisateur peut consommer avec le champ UserDriveMaximumSize .

# Enables the user drive with a per-user limit of 500MB (524288000 bytes)
MountUserDrive = $true
UserDriveMaximumSize = 524288000

Si vous ne souhaitez pas que les données du lecteur utilisateur soient persistantes, vous pouvez configurer une tâche planifiée sur le système pour nettoyer automatiquement le dossier chaque nuit.

Pour plus d’informations sur PSDrives, consultez Gestion des lecteurs PowerShell.

Définitions de rôles

Les définitions de rôles dans un fichier de configuration de session définissent le mappage des utilisateurs aux rôles. Chaque utilisateur ou groupe inclus dans ce champ reçoit l'autorisation d'accéder au point de terminaison JEA lors de son enregistrement. Chaque utilisateur ou groupe peut être inclus en tant que clé dans la table de hachage une seule fois, mais peut être affecté à plusieurs rôles. Le nom de la fonctionnalité de rôle doit être le nom du fichier de capacité de rôle, sans l’extension .psrc .

RoleDefinitions = @{
    'CONTOSO\JEA_DNS_ADMINS'    = @{ RoleCapabilities = 'DnsAdmin', 'DnsOperator', 'DnsAuditor' }
    'CONTOSO\JEA_DNS_OPERATORS' = @{ RoleCapabilities = 'DnsOperator', 'DnsAuditor' }
    'CONTOSO\JEA_DNS_AUDITORS'  = @{ RoleCapabilities = 'DnsAuditor' }
}

Si un utilisateur appartient à plusieurs groupes dans la définition de rôle, il accède aux rôles de chacun d’eux. Lorsque deux rôles accordent l’accès aux mêmes applets de commande, le jeu de paramètres le plus permissif est accordé à l’utilisateur.

Lorsque vous spécifiez des utilisateurs ou des groupes locaux dans le champ définitions de rôle, veillez à utiliser le nom de l’ordinateur, et non les caractères génériques ou localhost . Vous pouvez vérifier le nom de l’ordinateur en inspectant la $Env:COMPUTERNAME variable.

RoleDefinitions = @{
    'MyComputerName\MyLocalGroup' = @{ RoleCapabilities = 'DnsAuditor' }
}

Ordre de recherche des fonctionnalités de rôle

Comme indiqué dans l’exemple ci-dessus, les fonctionnalités de rôle sont référencées par le nom de base du fichier de capacité de rôle. Le nom de base d’un fichier est le nom de fichier sans l’extension. Si plusieurs fonctionnalités de rôle sont disponibles sur le système avec le même nom, PowerShell utilise son ordre de recherche implicite pour sélectionner le fichier de capacité de rôle effectif. JEA ne donne pas accès à tous les fichiers de capacité de rôle portant le même nom.

JEA utilise la variable d’environnement $Env:PSModulePath pour déterminer les chemins d’accès à analyser pour les fichiers de capacité de rôle. Dans chacun de ces chemins, JEA recherche des modules PowerShell valides qui contiennent un sous-dossier « RoleCapabilities ». Comme pour l’importation de modules, JEA préfère les fonctionnalités de rôle fournies avec Windows aux fonctionnalités de rôle personnalisées portant le même nom.

Pour tous les autres conflits d’affectation de noms, la priorité est déterminée par l’ordre dans lequel Windows énumère les fichiers dans le répertoire. L’ordre n’est pas garanti par ordre alphabétique. Le premier fichier de capacité de rôle trouvé qui correspond au nom spécifié est utilisé pour l’utilisateur connecté. Étant donné que l’ordre de recherche des capacités de rôle n’est pas déterministe, il est fortement recommandé que les fonctionnalités de rôle aient des noms de fichiers uniques.

Règles d’accès conditionnel

Tous les utilisateurs et groupes inclus dans le champ RoleDefinitions sont automatiquement autorisés à accéder aux points de terminaison JEA. Les règles d’accès conditionnel vous permettent d’affiner cet accès et de demander aux utilisateurs d’appartenir à des groupes de sécurité supplémentaires qui n’ont pas d’impact sur les rôles auxquels ils sont affectés. Cela est utile lorsque vous souhaitez intégrer une solution de gestion des accès privilégiés juste-à-temps, une authentification par carte à puce ou une autre solution d’authentification multifacteur avec JEA.

Les règles d’accès conditionnel sont définies dans le champ RequiredGroups dans un fichier de configuration de session. Là, vous pouvez fournir une table de hachage (éventuellement imbriquée) qui utilise des clés « And » et « Or » pour construire vos règles. Voici quelques exemples d’utilisation de ce champ :

# Example 1: Connecting users must belong to a security group called "elevated-jea"
RequiredGroups = @{ And = 'elevated-jea' }

# Example 2: Connecting users must have signed on with 2 factor authentication or a smart card
# The 2 factor authentication group name is "2FA-logon" and the smart card group
# name is "smartcard-logon"
RequiredGroups = @{ Or = '2FA-logon', 'smartcard-logon' }

# Example 3: Connecting users must elevate into "elevated-jea" with their JIT system and
# have logged on with 2FA or a smart card
RequiredGroups = @{ And = 'elevated-jea', @{ Or = '2FA-logon', 'smartcard-logon' }}

Autres propriétés

Les fichiers de configuration de session peuvent également faire tout ce qu’un fichier de capacité de rôle peut faire, sauf qu'ils ne peuvent pas donner aux utilisateurs connectés l'accès à différentes commandes. Si vous souhaitez autoriser tous les utilisateurs à accéder à des applets de commande, fonctions ou fournisseurs spécifiques, vous pouvez le faire directement dans le fichier de configuration de session. Pour obtenir la liste complète des propriétés prises en charge dans le fichier de configuration de session, exécutez Get-Help New-PSSessionConfigurationFile -Full.

Test d’un fichier de configuration de session

Vous pouvez tester une configuration de session à l’aide de l’applet de commande Test-PSSessionConfigurationFile . Nous vous recommandons de tester votre fichier de configuration de session si vous avez modifié manuellement le .pssc fichier. Le test garantit que la syntaxe est correcte. Si un fichier de configuration de session échoue ce test, il ne peut pas être inscrit sur le système.

Exemple de fichier de configuration de session

L’exemple suivant montre comment créer et valider une configuration de session pour JEA. Les définitions de rôle sont créées et stockées dans la $roles variable pour des raisons pratiques et de lisibilité. il n’est pas nécessaire de le faire.

$roles = @{
    'CONTOSO\JEA_DNS_ADMINS'    = @{ RoleCapabilities = 'DnsAdmin', 'DnsOperator', 'DnsAuditor' }
    'CONTOSO\JEA_DNS_OPERATORS' = @{ RoleCapabilities = 'DnsOperator', 'DnsAuditor' }
    'CONTOSO\JEA_DNS_AUDITORS'  = @{ RoleCapabilities = 'DnsAuditor' }
}

$parameters = @{
    SessionType = 'RestrictedRemoteServer'
    Path = '.\JEAConfig.pssc'
    RunAsVirtualAccount = $true
    TranscriptDirectory = 'C:\ProgramData\JEAConfiguration\Transcripts'
    RoleDefinitions = $roles
    RequiredGroups = @{ Or = '2FA-logon', 'smartcard-logon' }
}
New-PSSessionConfigurationFile @parameters
Test-PSSessionConfigurationFile -Path .\JEAConfig.pssc # should yield True

Mise à jour des fichiers de configuration de session

Pour modifier les propriétés d’une configuration de session JEA, y compris le mappage des utilisateurs aux rôles, vous devez annuler l’inscription. Ensuite, réinscrivez la configuration de session JEA à l’aide d’un fichier de configuration de session mis à jour.

Étapes suivantes

• Enregistrer une configuration JEA
• Définir des rôles JEA