Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Mis à jour : 24 juin 2013
S’applique à : Windows Server 2012 R2, Windows Server 2012
Windows PowerShell Web Access dans Windows Server 2012 R2 et Windows Server 2012 utilise un modèle de sécurité restrictif. Les utilisateurs doivent explicitement se voir accorder l’accès avant de pouvoir se connecter à la passerelle Windows PowerShell Web Access et utiliser la console web Windows PowerShell.
Configuration des règles d’autorisation et de la sécurité du site
Après l’installation de Windows PowerShell Web Access et la configuration de la passerelle, les utilisateurs peuvent ouvrir la page de connexion dans un navigateur, mais ils ne peuvent pas se connecter tant que l’administrateur Windows PowerShell Web Access n’a pas accordé explicitement l’accès aux utilisateurs. Le contrôle d’accès « Windows PowerShell Web Access » est géré à l’aide de l’ensemble des cmdlets Windows PowerShell décrits dans le tableau suivant. Il n’existe pas d’interface graphique comparable pour ajouter ou gérer les règles d’autorisation. Voir les commandlets d’accès Web Windows PowerShell.
Les administrateurs peuvent définir {0-n} des règles d’authentification pour Windows PowerShell Web Access. La garantie par défaut est restrictive plutôt que permissive ; Aucune règle d’authentification signifie qu’aucun utilisateur n’a accès à quoi que ce soit.
Add-PswaAuthorizationRule et Test-PswaAuthorizationRule dans Windows Server 2012 R2 incluent un paramètre de crédential qui vous permet d’ajouter et de tester les règles d’autorisation d’accès Web PowerShell Windows depuis un ordinateur distant, ou depuis une session active d’accès Web PowerShell Windows. Comme pour d’autres cmdlets PowerShell Windows qui possèdent un paramètre de crédential, vous pouvez spécifier un objet PSCredential comme valeur du paramètre. Pour créer un objet PSCredential contenant les identifiants que vous souhaitez transmettre à un ordinateur distant, exécutez le cmdlet Get-Credential .
Les règles d’authentification d’accès Web Windows PowerShell sont des règles d’autorisation . Chaque règle est une définition d’une connexion autorisée entre les utilisateurs, les ordinateurs cibles et certaines configurations de session PowerShell Windows (également appelées terminaux ou espaces d’exécution) sur des ordinateurs cibles spécifiés. Pour une explication sur les espaces d’exécution , voir Début d’utilisation des espaces d’exécution PowerShell
Important
Un utilisateur n’a besoin que d’une seule règle pour être vraie afin d’y accéder. Si un utilisateur a accès à un ordinateur avec un accès complet en langue ou uniquement aux cmdlets de gestion distante PowerShell de Windows, depuis la console web, il peut se connecter (ou sauter) vers d’autres ordinateurs connectés au premier ordinateur cible. La manière la plus sécurisée de configurer Windows PowerShell Web Access est de permettre aux utilisateurs d’accéder uniquement à des configurations de session contraintes qui leur permettent d’accomplir des tâches spécifiques qu’ils doivent normalement effectuer à distance.
Les cmdlets référencés dans les CMDLETS d’accès Web PowerShell de Windows permettent de créer un ensemble de règles d’accès qui sont utilisées pour autoriser un utilisateur sur la passerelle d’accès Web PowerShell de Windows. Les règles diffèrent des listes de contrôle d’accès (ACL) de l’ordinateur de destination et offrent une couche supplémentaire de sécurité pour l’accès web. Plus de détails sur la sécurité sont décrits dans la section suivante.
Si les utilisateurs ne peuvent pas franchir l’une des couches de sécurité précédentes, ils reçoivent un message générique « accès refusé » dans les fenêtres de leur navigateur. Bien que les détails de sécurité soient enregistrés sur le serveur passerelle, les utilisateurs finaux ne reçoivent pas d’informations sur le nombre de couches de sécurité qu’ils ont franchies, ni sur la couche à laquelle l’échec de connexion ou d’authentification a eu lieu lui-même.
Pour plus d’informations sur la configuration des règles d’autorisation, voir configurer les règles d’autorisation dans ce sujet.
Security
Le modèle de sécurité de l’accès Web PowerShell Windows comporte quatre couches entre l’utilisateur final de la console web et l’ordinateur cible. Les administrateurs Windows PowerShell Web Access peuvent ajouter des couches de sécurité via une configuration supplémentaire dans la console IIS Manager. Pour plus d’informations sur la sécurisation des sites web dans la console IIS Manager, voir Configurer la sécurité des serveurs web (IIS7).
Pour plus d’informations sur les meilleures pratiques de l’IIS et la prévention des attaques par déni de service, consultez Meilleures pratiques pour prévenir les attaques DoS/déni de service. Un administrateur peut également acheter et installer des logiciels d’authentification supplémentaires pour le commerce de détail.
Le tableau suivant décrit les quatre couches de sécurité entre les utilisateurs finaux et les ordinateurs cibles.
Des informations détaillées sur chaque couche se trouvent sous les rubriques suivantes :
Fonctionnalités de sécurité des serveurs web IIS
Les utilisateurs de Windows PowerShell Web Access doivent toujours fournir un nom d’utilisateur et un mot de passe pour authentifier leurs comptes sur la passerelle. Cependant, les administrateurs Windows PowerShell Web Access peuvent également activer ou désactiver l’authentification optionnelle des certificats clients, voir installer et utiliser Windows PowerShell Web Access pour activer un certificat de test et, plus tard, comment configurer un certificat authentique.
La fonctionnalité optionnelle du certificat client exige que les utilisateurs finaux disposent d’un certificat client valide, en plus de leurs noms d’utilisateur et mots de passe, et fait partie de la configuration Web Server (IIS). Lorsque la couche de certificat client est activée, la page de connexion Windows PowerShell Web Access invite les utilisateurs à fournir des certificats valides avant que leurs identifiants de connexion ne soient évalués. L’authentification des certificats clients vérifie automatiquement la présence du certificat client. Si aucun certificat valide n’est trouvé, Windows PowerShell Web Access informe les utilisateurs, afin qu’ils puissent fournir le certificat. Si un certificat client valide est trouvé, Windows PowerShell Web Access ouvre la page de connexion permettant aux utilisateurs de fournir leurs noms d’utilisateur et mots de passe.
C’est un exemple de paramètres de sécurité supplémentaires proposés par IIS Web Server. Pour plus d’informations sur d’autres fonctionnalités de sécurité de l’IIS, voir Configurer la sécurité des serveurs web (IIS 7).
Authentification de passerelle basée sur des formulaires Windows PowerShell Web Access
La page de connexion Windows PowerShell Web Access nécessite un ensemble d’identifiants (nom d’utilisateur et mot de passe) et offre aux utilisateurs la possibilité de fournir différents identifiants pour l’ordinateur cible. Si l’utilisateur ne fournit pas d’identifiants alternatifs, le nom d’utilisateur principal et le mot de passe utilisés pour se connecter à la passerelle sont également utilisés pour se connecter à l’ordinateur cible.
Les identifiants requis sont authentifiés sur la passerelle d’accès Web PowerShell Windows. Ces identifiants doivent être des comptes utilisateurs valides soit sur le serveur local de passerelle Windows PowerShell Web Access, soit sur Active Directory.
Règles d’autorisation d’accès Web PowerShell Windows PowerShell
Après qu’un utilisateur est authentifié à la passerelle, Windows PowerShell Web Access vérifie les règles d’autorisation pour vérifier si l’utilisateur a accès à l’ordinateur cible demandé. Après une autorisation réussie, les identifiants de l’utilisateur sont transmis à l’ordinateur cible.
Ces règles ne sont évaluées qu’après qu’un utilisateur a été authentifié par la passerelle, et avant qu’un utilisateur ne puisse être authentifié sur un ordinateur cible.
Règles d’authentification et d’autorisation de la cible
La dernière couche de sécurité pour Windows PowerShell Web Access est la configuration de sécurité propre à l’ordinateur ciblé. Les utilisateurs doivent disposer des droits d’accès appropriés configurés sur l’ordinateur cible, ainsi que dans les règles d’autorisation d’accès Web de Windows PowerShell, pour exécuter une console web Windows PowerShell qui affecte un ordinateur cible via Windows PowerShell Web Access.
Cette couche offre les mêmes mécanismes de sécurité qui évalueraient les tentatives de connexion si les utilisateurs tentaient de créer une session PowerShell Windows à distance vers un ordinateur cible depuis Windows PowerShell en exécutant les cmdlets Enter-PSSession ou New-PSSession .
Par défaut, Windows PowerShell Web Access utilise le nom d’utilisateur principal et le mot de passe pour l’authentification à la fois sur la passerelle et sur l’ordinateur cible. La page de connexion web, dans une section intitulée Paramètres de connexion optionnels, offre aux utilisateurs la possibilité de fournir différentes identifiantes pour l’ordinateur cible, si nécessaire. Si l’utilisateur ne fournit pas d’identifiants alternatifs, le nom d’utilisateur principal et le mot de passe utilisés pour se connecter à la passerelle sont également utilisés pour se connecter à l’ordinateur cible.
Les règles d’autorisation peuvent être utilisées pour permettre aux utilisateurs d’accéder à une configuration de session particulière. Vous pouvez créer des espaces d’exécution restreints ou des configurations de session pour Windows PowerShell Web Access, et permettre à certains utilisateurs de se connecter uniquement à des configurations de session spécifiques lorsqu’ils se connectent à Windows PowerShell Web Access. Vous pouvez utiliser des listes de contrôle d’accès (ACL) pour déterminer quels utilisateurs ont accès à des points d’accès spécifiques, et restreindre davantage l’accès au point de terminaison pour un ensemble spécifique d’utilisateurs en utilisant les règles d’autorisation décrites dans cette section. Pour plus d’informations sur les espaces de gestion restreints, voir Création d’un espace de gestion contraint.
Configuration des règles d’autorisation
Les administrateurs souhaitent probablement la même règle d’autorisation pour les utilisateurs de Windows PowerShell Web Access qui est déjà définie dans leur environnement pour la gestion à distance de Windows PowerShell. La première procédure de cette section explique comment ajouter une règle d’autorisation sécurisée qui accorde l’accès à un utilisateur, la connexion pour gérer un ordinateur, et au sein d’une seule configuration de session. La deuxième procédure décrit comment supprimer une règle d’autorisation qui n’est plus nécessaire.
Si vous prévoyez d’utiliser des configurations de session personnalisées pour permettre à certains utilisateurs de travailler uniquement dans des espaces d’exécution restreints dans Windows PowerShell Web Access, créez vos configurations de session personnalisées avant d’ajouter des règles d’autorisation qui les réfèrent. Vous ne pouvez pas utiliser les commandements Windows PowerShell Web Access pour créer des configurations de session personnalisées. Pour plus d’informations sur la création de configurations de session personnalisées, voir about_Session_Configuration_Files.
Les cmdlets Windows PowerShell Web Access prennent en charge un caractère joker, un astérisque ( * ). Les caractères jokers dans les chaînes ne sont pas pris en charge ; Utilisez un astérisque unique par propriété (utilisateurs, ordinateurs ou configurations de session).
Note
Pour plus de façons d’utiliser les règles d’autorisation afin d’accorder l’accès aux utilisateurs et d’aider à sécuriser l’environnement Windows PowerShell Web Access, consultez d’autres exemples de scénarios de règles d’autorisation dans ce sujet.
Ajouter une règle d’autorisation restrictive
Effectuez une des opérations suivantes pour ouvrir une session Windows PowerShell avec des droits utilisateur élevés.
Sur le bureau Windows, cliquez avec le bouton droit sur Windows PowerShell dans la barre des tâches, puis cliquez sur Exécuter en tant qu’administrateur.
Sur l’écran de démarrage de Windows, cliquez droit sur Windows PowerShell, puis cliquez sur Exécuter en tant qu’Administrateur.
Étape optionnelle Pour restreindre l’accès des utilisateurs en utilisant des configurations de session :
Vérifiez que les configurations de session que vous souhaitez utiliser existent déjà dans vos règles.
S’ils n’ont pas encore été créés, utilisez les instructions pour créer les configurations de session dans about_Session_Configuration_Files.
Cette règle d’autorisation permet à un utilisateur spécifique d’accéder à un ordinateur du réseau auquel il a généralement accès, avec un accès à une configuration de session spécifique adaptée aux besoins typiques de script et de cmdlet de l’utilisateur. Tapez ce qui suit, puis appuyez sur Entrée.
Add-PswaAuthorizationRule -UserName <domain\user | computer\user> ` -ComputerName <computer_name> -ConfigurationName <session_configuration_name>- Dans l’exemple suivant, un utilisateur nommé JSmith dans le domaine Contoso obtient l’accès pour gérer la Contoso_214 informatique et utiliser une configuration de session nommée NewAdminsOnly.
Add-PswaAuthorizationRule -UserName 'Contoso\JSmith' ` -ComputerName Contoso_214 -ConfigurationName NewAdminsOnlyVérifiez que la règle a été créée en exécutant soit le cmdlet Get-PswaAuthorizationRule , soit
Test-PswaAuthorizationRule -UserName <domain\user | computer\user> -ComputerName** <computer_name>. Par exemple :Test-PswaAuthorizationRule -UserName Contoso\\JSmith -ComputerName Contoso_214.
Supprimer une règle d’autorisation
Si une session Windows PowerShell n’est pas déjà ouverte, voir l’étape 1 de pour ajouter une règle d’autorisation restrictive dans cette section.
Tapez ce qui suit, puis appuyez sur Entrée, où l’ID de la règle représente le numéro d’ID unique de la règle que vous souhaitez supprimer.
Remove-PswaAuthorizationRule -ID <rule ID>Sinon, si vous ne connaissez pas le numéro d’identification mais connaissez le nom amical de la règle que vous souhaitez supprimer, vous pouvez obtenir le nom de la règle et le transmettre au
Remove-PswaAuthorizationRulecmdlet pour supprimer la règle, comme montré dans l’exemple suivant :Get-PswaAuthorizationRule ` -RuleName <rule-name> | Remove-PswaAuthorizationRule
Note
On ne vous invite pas à confirmer si vous souhaitez supprimer la règle d’autorisation spécifiée ; la règle est supprimée lorsque vous appuyez sur Entrée. Assurez-vous de vouloir supprimer la règle d’autorisation avant d’exécuter le Remove-PswaAuthorizationRule cmdlet.
Autres exemples de scénarios de règles d’autorisation
Chaque session Windows PowerShell utilise une configuration de session ; si aucune session n’est spécifiée, Windows PowerShell utilise la configuration de session Windows PowerShell intégrée par défaut, appelée Microsoft.PowerShell. La configuration par défaut de la session inclut tous les cmdlets disponibles sur un ordinateur. Les administrateurs peuvent restreindre l’accès à tous les ordinateurs en définissant une configuration de session avec un espace d’exécution restreint (une gamme limitée de cmdlets et de tâches que leurs utilisateurs finaux pourraient effectuer). Un utilisateur ayant accès à un ordinateur avec un accès complet en langue ou uniquement avec les cmdlets de gestion distante Windows PowerShell peut se connecter à d’autres ordinateurs connectés au premier ordinateur. Définir un espace d’exécution restreint peut empêcher les utilisateurs d’accéder à d’autres ordinateurs depuis leur espace d’exécution Windows PowerShell autorisé, et améliore la sécurité de votre environnement Windows PowerShell Web Access. La configuration de la session peut être distribuée (en utilisant la Stratégie de Groupe) à tous les ordinateurs que les administrateurs souhaitent rendre accessibles via Windows PowerShell Web Access. Pour plus d’informations sur les configurations de session, consultez about_Session_Configurations. Voici quelques exemples de ce scénario.
Un administrateur crée un point de terminaison, appelé PswaEndpoint, avec un espace d’exécution restreint. Ensuite, l’administrateur crée une règle,
*,*,PswaEndpoint, et distribue le point de terminaison à d’autres ordinateurs. La règle permet à tous les utilisateurs d’accéder à tous les ordinateurs possédant le point de terminaison PswaEndpoint. Si c’est la seule règle d’autorisation définie dans l’ensemble de règles, les ordinateurs sans ce point de terminaison ne seraient pas accessibles.L’administrateur a créé un point de terminaison avec un espace d’exécution restreint appelé PswaEndpoint, et souhaite restreindre l’accès à des utilisateurs spécifiques. L’administrateur crée un groupe d’utilisateurs appelé Level1Support et définit la règle suivante : Level1Support,*,PswaEndpoint. La règle accorde à tous les utilisateurs du groupe Level1Support l’accès à tous les ordinateurs disposant de la configuration PswaEndpoint . De même, l’accès peut être restreint à un ensemble spécifique d’ordinateurs.
Certains administrateurs offrent à certains utilisateurs plus d’accès que d’autres. Par exemple, un administrateur crée deux groupes d’utilisateurs, Admins et BasicSupport. L’administrateur crée également un point de terminaison avec un espace d’exécution restreint appelé PswaEndpoint, et définit les deux règles suivantes : Admins,*,* et BasicSupport,*,PswaEndpoint. La première règle donne à tous les utilisateurs du groupe Admin l’accès à tous les ordinateurs, et la seconde règle donne à tous les utilisateurs du groupe BasicSupport l’accès uniquement aux ordinateurs possédant PswaEndpoint.
Un administrateur a mis en place un environnement de test privé et souhaite permettre à tous les utilisateurs autorisés du réseau d’accéder à tous les ordinateurs du réseau auxquels ils ont généralement accès, avec l’accès à toutes les configurations de session auxquelles ils ont généralement accès. Comme il s’agit d’un environnement de test privé, l’administrateur crée une règle d’autorisation qui n’est pas sécurisée. - L’administrateur exécute le cmdlet
Add-PswaAuthorizationRule * * *, qui utilise le caractère * joker pour représenter tous les utilisateurs, tous les ordinateurs et toutes les configurations. - Cette règle est l’équivalent de la suivante :Add-PswaAuthorizationRule -UserName * -ComputerName * -ConfigurationName *.Note
Cette règle n’est pas recommandée dans un environnement sécurisé et contourne la couche de règle d’autorisation de sécurité fournie par Windows PowerShell Web Access.
Un administrateur doit permettre aux utilisateurs de se connecter aux ordinateurs cibles dans un environnement incluant à la fois des groupes de travail et des domaines, où les ordinateurs de groupes de travail sont parfois utilisés pour se connecter aux ordinateurs cibles dans des domaines, et où les ordinateurs dans des domaines sont parfois utilisés pour se connecter aux ordinateurs cibles dans des groupes de travail. L’administrateur dispose d’un serveur passerelle, PswaServer, dans un groupe de travail ; et l’ordinateur cible srv1.contoso.com se trouve dans un domaine. L’utilisateur Chris est un utilisateur local autorisé à la fois sur le serveur passerelle du groupe de travail et sur l’ordinateur cible. Son nom d’utilisateur sur le serveur du groupe de travail est chrisLocal ; Et son nom d’utilisateur sur l’ordinateur cible est Contoso\chris. Pour autoriser l’accès à srv1.contoso.com pour Chris, l’administrateur ajoute la règle suivante.
Add-PswaAuthorizationRule -userName PswaServer\chrisLocal `
-computerName srv1.contoso.com -configurationName Microsoft.PowerShell
L’exemple de règle précédent authentifie Chris sur le serveur passerelle, puis autorise son accès à srv1. Sur la page de connexion, Chris doit fournir un second ensemble d’identifiants dans la section Paramètres de connexion optionnels (contoso\chris). Le serveur passerelle utilise cet ensemble supplémentaire d’identifiants pour l’authentifier sur l’ordinateur cible, srv1.contoso.com.
Dans le scénario précédent, Windows PowerShell Web Access n’établit une connexion réussie à l’ordinateur cible qu’après que les conditions suivantes ont été réussies, et autorisées par au moins une règle d’autorisation.
Authentification sur le serveur passerelle du groupe de travail en ajoutant un nom d’utilisateur dans le format server_name\user_name à la règle d’autorisation
Authentification sur l’ordinateur cible en utilisant des identifiants alternatifs fournis sur la page de connexion, dans la zone Paramètres de connexion optionnels
Note
Si la passerelle et les ordinateurs cibles appartiennent à des groupes de travail ou domaines différents, une relation de confiance doit être établie entre les deux ordinateurs du groupe de travail, les deux domaines, ou entre le groupe de travail et le domaine. Cette relation ne peut pas être configurée en utilisant les cmdlets de règles d’autorisation Windows PowerShell Web Access. Les règles d’autorisation ne définissent pas de relation de confiance entre ordinateurs ; ils ne peuvent autoriser les utilisateurs qu’à se connecter à des ordinateurs cibles spécifiques et à des configurations de session. Pour plus d’informations sur la configuration d’une relation de confiance entre différents domaines, voir Création de trusts de domaine et de forêt. Pour plus d’informations sur la manière d’ajouter des ordinateurs de groupe de travail à une liste d’hôtes de confiance, voir Gestion à distance avec Server Manager.
Utilisation d’un ensemble unique de règles d’autorisation pour plusieurs sites
Les règles d’autorisation sont stockées dans un fichier XML. Par défaut, le nom de chemin du fichier XML est $env:windir\Web\PowershellWebAccess\data\AuthorizationRules.xml.
Le chemin vers le fichier XML des règles d’autorisation est stocké dans le fichierpowwa.config , qui se trouve dans $env:windir\Web\PowershellWebAccess\data. L’administrateur a la flexibilité de modifier la référence au chemin par défaut danspowwa.config selon ses préférences ou exigences. Permettre à l’administrateur de modifier l’emplacement du fichier permet à plusieurs passerelles Windows PowerShell Web Access d’utiliser les mêmes règles d’autorisation, si une telle configuration est souhaitée.
Gestion des sessions
Par défaut, Windows PowerShell Web Access limite un utilisateur à trois sessions à la fois. Vous pouvez modifier le fichier web.config de l’application web dans IIS Manager pour prendre en charge un nombre différent de sessions par utilisateur. Le chemin vers le fichier web.config est $env:windir\Web\PowerShellWebAccess\wwwroot\Web.config.
Par défaut, IIS Web Server est configuré pour redémarrer le pool d’applications si des paramètres sont modifiés. Par exemple, le pool d’applications est redémarré si des modifications sont apportées au fichierweb.config . >Parce que Windows PowerShell Web Access utilise des états de session en mémoire, >les utilisateurs connectés aux sessions Windows PowerShell Web Access perdent leurs sessions lorsque le pool d’applications est redémarré.
Définir les paramètres par défaut sur la page de connexion
Si votre passerelle Windows PowerShell Web Access fonctionne sur Windows Server 2012 R2, vous pouvez configurer les valeurs par défaut pour les paramètres affichés sur la page de connexion Windows PowerShell Web Access. Vous pouvez configurer des valeurs dans le fichier web.config décrit dans le paragraphe précédent. Les valeurs par défaut pour les paramètres de la page de connexion se trouvent dans la section appParamètres du fichier web.config ; ce qui suit est un exemple de la section appSettings . Les valeurs valides pour beaucoup de ces paramètres sont les mêmes que pour les paramètres correspondants du cmdlet New-PSSession dans Windows PowerShell.
Par exemple, la defaultApplicationName clé, comme illustrée dans le bloc de code suivant, est la valeur de la variable de préférence $PSSessionApplicationName sur l’ordinateur cible.
<appSettings>
<add key="maxSessionsAllowedPerUser" value="3"/>
<add key="defaultPortNumber" value="5985"/>
<add key="defaultSSLPortNumber" value="5986"/>
<add key="defaultApplicationName" value="WSMAN"/>
<add key="defaultUseSslSelection" value="0"/>
<add key="defaultAuthenticationType" value="0"/>
<add key="defaultAllowRedirection" value="0"/>
<add key="defaultConfigurationName" value="Microsoft.PowerShell"/>
</appSettings>
Temps morts et déconnexions imprévues
Les sessions Windows PowerShell Web Access expirent. Dans Windows PowerShell Web Access fonctionnant sur Windows Server 2012, un message de délai d’attente est affiché aux utilisateurs connectés après 15 minutes d’inactivité de la session. Si l’utilisateur ne répond pas dans les cinq minutes suivant l’affichage du message de temps d’attente, la session est terminée et l’utilisateur est déconnecté. Vous pouvez modifier les délais d’attente des sessions dans les paramètres du site web dans IIS Manager.
Dans Windows PowerShell Web Access fonctionnant sur Windows Server 2012 R2, les sessions expirent, par défaut, après 20 minutes d’inactivité. Si les utilisateurs sont déconnectés des sessions dans la console web en raison d’erreurs réseau ou d’autres arrêts ou défaillances imprévus, et non parce qu’ils ont fermé eux-mêmes les sessions, les sessions Windows PowerShell Web Access continuent de s’exécuter, connectées aux ordinateurs cibles, jusqu’à la fin du délai côté client. La session est déconnectée après soit les 20 minutes par défaut, soit après la période d’attente spécifiée par l’administrateur de la passerelle, selon la durée la plus courte.
Si le serveur passerelle exécute Windows Server 2012 R2, Windows PowerShell Web Access permet aux utilisateurs de se reconnecter aux sessions sauvegardées ultérieurement, mais lorsque des erreurs réseau, des arrêts non planifiés ou d’autres défaillances déconnectent les sessions, les utilisateurs ne peuvent pas voir ni se reconnecter aux sessions sauvegardées avant que la période d’attente spécifiée par l’administrateur de la passerelle soit écoulée.
Voir aussi
Installer et utiliser Windows PowerShell Web Access