PowerShell en accès Web : est-ce pratique ?

PowerShell en accès Web : est-ce pratique ?

PowerShell est depuis longtemps l’outil standard pour tout gérer. Il gère aussi bien Windows Server, Exchange mais aussi Office 365 et les ressources Azure. Plus récemment, il a pris en charge Linux et macOS via son fork PowerShell Core. Avec son langage robuste, ses capacités d’automatisation et de remoting, PowerShell s’est avéré inestimable et de nombreux professionnels de l’informatique. Il est donc devenu très important de garantir l’accès à une console PowerShell chaque fois que cela est possible.

L’utilisation de PowerShell dans le navigateur n’est pas quelque chose de nouveau. En fait, cette fonctionnalité est disponible depuis de nombreuses années. Depuis Windows Server 2012, PowerShell Web Access nous a permis d’exécuter des cmdlets et des scripts sur n’importe quel appareil. Cela dit, la fonctionnalité PowerShell Web Access n’a pas reçu beaucoup d’amour depuis sa sortie initiale. Et bien qu’elle fasse toujours partie de l’installation de Windows Server, il n’y a pas grand-chose de nouveau à dire.

Alors, pourquoi est-ce que j’écris sur ce sujet maintenant, six ans plus tard ? Azure Cloud Shell est l’une des raisons. J’avais l’intention de faire une comparaison entre les deux, en particulier pour la gestion d’Office 365. Après d’autres annonces faites lors du salon Ignite de cette année, j’ai quelques raisons supplémentaires d’approfondir ce sujet. Entrons dans le vif du sujet.

Accès Web PowerShell

PowerShell Web Access n’étant pas nouveau, je n’entrerai pas dans les détails de l’installation et de la configuration. Vous pouvez trouver ces informations dans la documentation officielle ou sur de nombreux articles de blog. Cependant, je vais brièvement parler de la façon dont vous pouvez l’utiliser et les applications. 

Pour commencer, vous pouvez utiliser n’importe quel navigateur pour vous connecter au point de terminaison PSWA. Il s’agit du point de terminaison exposé en interne dans votre organisation ou au monde extérieur. Internet Explorer fera l’affaire, même des versions aussi anciennes que IE 8.0, même si vous ne devriez pas les utiliser. La plupart des navigateurs mobiles conviennent également, à condition qu’ils prennent en charge JavaScript. Comme vous pouvez l’imaginer, la contrepartie de cet assouplissement des exigences est une interface « moins vive ». Cette capture d’écran illustre également l’attention accordée à cette fonctionnalité par Microsoft au cours des dernières années. Puisque je fonctionne en fait sur une boîte Windows Server 2019, même si la page Web indique Windows Server 2016.

Cmdlet prises en charge

Une fois que vous vous êtes connecté à la page PSWA, vous vous retrouvez dans une fenêtre de terminal. Et vous pouvez commencer à émettre des cmdlets. Sous la couverture, PSWA utilise le remoting pour se connecter à une machine donnée. C’est pourquoi le paramètre Computer Name est obligatoire lors de la connexion. Une fois connecté, vous avez accès à une console PowerShell à part entière, comme l’indique la sortie de $PSVersionTable. Et vous pouvez faire plus qu’exécuter des cmdlets. Par exemple, vous pouvez invoquer des classes et des méthodes .NET, telles que la classe System.Environment et sa propriété OSVersion, qui indique la version/bâtiment du serveur actuel. Vous pouvez également appeler des applications de console telles que ipconfig :

Vous bénéficiez de la prise en charge de :

• la complétion de tabulation et de l’historique d’exécution,
• la plupart des autres fonctionnalités PowerShell que vous connaissez.

La recherche et l’installation de modules via les cmdlets exposés par le module PowerShellGet en est un exemple, à condition que vous soyez connecté à un ordinateur exécutant une version récente de PowerShell. Vous pouvez rapidement télécharger le module MSOnline s’il n’est pas déjà présent sur le système. Une fois le module installé, vous pouvez vous connecter à Office 365 et commencer à gérer les utilisateurs.

Limitations

Vous avez peut-être remarqué que j’ai utilisé le commutateur -Credential pour la cmdlet Connect-MsolService ci-dessus. Cela entraîne l’utilisation d’un flux OAuth spécial. Cela me permet de me connecter via l’authentification moderne tout en contournant la boîte de dialogue de connexion interactive. La raison en est simple : puisque j’exécute PowerShell dans ce qui est effectivement un terminal, il n’y a aucun moyen d’afficher la boîte de dialogue interactive ADAL. Cela signifie que tout module nécessitant une connexion interactive ne fonctionnera pas. Et PowerShell vous en informera par un message d’erreur. La connexion aux services qui acceptent la variable $Credentials fonctionnera cependant très bien, par exemple dans le cas d’Exchange Online :

En fait, j’ai utilisé mon script habituel de « connexion à Office 365 » dans une session de navigateur. Et je suis maintenant capable d’effectuer (presque) toutes les opérations que j’ai l’habitude d’exécuter sur mon ordinateur de bureau. D’autres modules, tels que MicrosoftTeams, fonctionneront également sans problème, à condition que vous puissiez transmettre les informations d’identification directement. Pour les modules uniquement compatible avec la connexion interactive, vous opterez pour des solutions de contournement. Ainsi vous obtiendrez un jeton d’accès directement via ADAL et le transmettrez pour vous connecter via l’authentification moderne :

Ce n’est pas la seule limitation. Par exemple, dans une session à distance, vous exécutez PowerShell dans un hôte différent, aucun profil n’est disponible. Ainsi vous ne pouvez pas vous connecter à distance de manière interactive à une autre machine en utilisant Enter-PSSession. Par exemple pour accéder à un module installé sur cette machine. Une alternative serait de se reconnecter à la passerelle PSWA et de choisir l’autre machine à la place. Vous pouvez également utiliser d’autres méthodes, telles que New-PSSession, Invoke-Command ou le paramètre -ComputerName.

Bilan

Puisque vous êtes lié au terminal, copier et coller des informations peut être une corvée. Tout comme visualiser ou modifier des fichiers, et transférer des fichiers est une tâche presque impossible. La coloration syntaxique, les touches de fonction et l’historique persistant des cmdlets, sont également indisponibles ou limités. Globalement, PSWA est un substitut viable pour les cas où vous devez exécuter une tâche PowerShell spécifique depuis une tablette. Dans quelle mesure est-il pratique ? Je dirais un solide 8/10 lorsqu’il est placé dans le contexte des tâches Office 365.

Azure Cloud Shell

Tandis que PSWA a peu évolué, Microsoft a consacré beaucoup d’efforts à la publication et au perfectionnement de PowerShell Core. L’une de ces modalités est Azure Cloud Shell, une expérience PowerShell basée sur un navigateur pour gérer les ressources Azure. Sous la couverture, Azure Cloud Shell est une interface web pour une instance PowerShell Core. Cette dernière fonctionne sur une VM Linux s’exécutant au-dessus d’un hôte Hyper-V. L’exécution sur Linux permet à Microsoft de minimiser la consommation de ressources et les coûts. Et en fait, les seuls frais ACS sont ceux du compte de stockage en cloud utilisé pour héberger la VM contenant le partage de fichiers.

Azure Cloud Shell est accessible à partir de plusieurs points d’accès. Il est intégré au portail Azur, et dispose également d’un site Web autonome accessible via https://shell.azure.com. Si vous accédez à ACS via la connexion au portail Azure, vous serez automatiquement connecté et aurez accès à Azure PowerShell. Si vous y accédez via la page Web d’ACS, vous devrez vous authentifier et sélectionner l’abonnement. Vous pouvez également sélectionner le type de shell, soit Bash, soit PowerShell.

Dans le cadre de cet article, nous nous intéressons bien sûr à PowerShell. La capture d’écran ci-dessous révèle quelques informations de base sur l’environnement, telles que :

• la version de PowerShell utilisée,
• le système d’exploitation sur lequel il s’exécute,
• le fait qu’il s’exécute dans une VM Hyper-V,
• l’adresse IP de la machine.

Modules disponibles

Les modules PowerShell actuellement disponibles sont indiqués à droite, et des modules supplémentaires peuvent être ajoutés via Install-Module. En outre, certaines des variables d’environnement sont affichées, ce qui sera important par la suite.

Comme il s’agit d’une instance PowerShell Core fonctionnant sous Linux, il existe certaines limitations. Par exemple, je peux télécharger, installer et importer le module MSOnline sans problème. Cependant je ne peux pas l’utiliser pour me connecter à Azure AD en raison d’une dépendance sous-jacente aux binaires ADAL :

Il en va de même pour tout autre module qui dépend d’ADAL, à moins qu’il n’ait été porté vers .Net Core. Heureusement, c’est exactement ce que Microsoft a fait avec les modules Azure. Y compris une version (preview) du module Azure AD que vous avez peut-être repéré dans la sortie de Get-Module ci-dessus. Par conséquent, nous pouvons l’utiliser à la place du module MSOnline afin de gérer nos objets Office 365. En fait, il existe plusieurs méthodes que vous pouvez utiliser pour vous connecter à Azure AD, comme indiqué ci-dessous :

Connexion à Azure-AD

La première méthode consiste à utiliser simplement la fonction Connect-AzureADService. Cela remplira les valeurs AccountId et TenantId en fonction des variables environnementales et vous connectera automatiquement. Vous pouvez également exécuter la cmdlet Connect-AzureAD sans aucun paramètre. Cela déclenchera le flux OAuth du code du périphérique. Ainsi cela vous permettra de terminer le processus d’authentification interactive à partir d’un autre point de terminaison. Et donc de contourner les limites de PowerShell Core. Une autre méthode consiste à transmettre directement un jeton d’accès. Une fois la connexion réussie, vous pouvez exécuter toutes les cmdlets AzureAD familières sans aucun problème. Cela contraste avec l’exécution des cmdlets Azure AD sur PowerShell Core qui ont donné lieu à diverses erreurs.

Limites

Pour la gestion des objets Exchange Online, PowerShell Core devrait faire l’affaire, une fois authentifié. Si vous utilisez toujours l’authentification de base, tout se passera bien. La MFA n’est pas compatible avec le module ExO activé par ADA. Car le module n’a pas encore été porté pour fonctionner sur .NET Core. Mais vous pouvez toujours utiliser diverses astuces, comme l’obtention d’un jeton en dehors du module et son passage :

Une autre nuisance de la combinaison Linux VM/PowerShell Core est également montrée sur la capture d’écran ci-dessus. A savoir les erreurs « ERROR_WSMAN_INVALID_SELECTORS » plutôt ennuyeuses que vous rencontrez souvent. Les problèmes avec d’autres modules peuvent être encore plus frustrants. Par exemple, le module MicrosoftTeams ne s’installe pas avec une erreur de dépendance DLL. Le module SharePoint PnP s’installe correctement mais ne parvient pas à se connecter en raison d’une dépendance de méthode, etc.

Certains des inconvénients liés à l’utilisation de PowerShell dans le navigateur ont été résolus. Un surligneur syntaxique de base est disponible, ainsi que l’historique des exécutions entre les sessions. Au lieu d’utiliser des utilitaires de ligne de commande vi ou emacs, nous disposons d’un éditeur de script intégré. Le transfert de fichiers dans et hors de l’environnement est également possible. Enfin, ACS prend également en charge les profils PowerShell. L’inconvénient est que les exigences en matière de navigateur sont plus strictes. Ce qui pourrait limiter la disponibilité sur certains systèmes. Parmi les problèmes qui subsistent, voici quelques points saillants :

• les touches de fonction sont inutilisables,
• la touche Echap ne fonctionne pas,
• le copier-coller laisse à désirer en termes de convivialité.

Le système de fichiers sensible à la casse peut rapidement vous mettre sur les nerfs lorsque vous essayez d’utiliser la complétion par tabulation.

Bilan

L’expérience de l’utilisateur final mise à part, ACS peut présenter quelques défis administratifs. Faisant partie du portail Azure, ACS est disponible à tout moment, sur n’importe quel appareil et depuis n’importe quel endroit. Cependant il est possible de restreindre l’accès à ACS en bloquant le point de terminaison sur vos périphériques réseau. Si vous établissez une liste blanche des emplacements à partir desquels les utilisateurs peuvent s’authentifier, comme les « emplacements nommés » pour l’accès conditionnel, vous devrez établir une liste blanche de sous-réseaux Azure entiers, car l’IP externe utilisée par l’environnement ACS n’est pas statique. ACS ne dispose pas de la granularité des règles d’autorisation PSWA et des configurations de session, ni même des contrôles de base de la marque en dehors de la marque de connexion Azure AD.

Dans quelle mesure Azure Cloud Shell est-il pratique lorsqu’il s’agit d’effectuer vos tâches quotidiennes liées à Office 365 ? Si vous ne vous intéressez qu’aux tâches Azure AD, l’expérience est comparable à l’exécution de PowerShell sur le bureau. Si vous ajoutez des tâches Exchange dans le mélange, seule l’authentification de ase fonctionne. Presque tous les autres modules liés à Office 365 ont des problèmes d’exécution dans un environnement ACS. Donc si ces modules sont essentiels pour vous, je vous conseille d’attendre qu’une version .NET Core du module soit officiellement publiée par Microsoft.

En raison des problèmes rencontrés, ACS mérite une note de 6/10, dans le contexte des tâches Office 365. Cette note devrait s’améliorer dans les mois à venir. A mesure que Microsoft poursuivra le développement du shell et le portage de modules supplémentaires pour PowerShell Core.

Résumé et prochaines étapes pour Office 365 PowerShell dans le navigateur

Dans cet article, nous avons exploré la viabilité d’un accès par navigateur à PowerShell, dans le contexte d’Office 365. Notre premier arrêt a été PowerShell Web Access. C’est une passerelle fiable vous permettant de vous connecter à PowerShell sur une machine sur site ou en cloud. Bien que PSWA a peu évolué et que l’interface est rustre, il fait toujours l’affaire dans la plupart des scénarios.

L’autre option est Azure Cloud Shell, un environnement PowerShell Core exécuté sur une VM Linux dans Azure. Bien qu’ACS offre une meilleure expérience globale, il n’est pas à la hauteur. Car la plupart des modules pertinents n’ont pas encore été portés sur .NET Core. Microsoft travaille à son amélioration et une version préliminaire du module Azure AD est disponible et préinstallée dans l’environnement ACS. De plus, nous savons que le module ExO est également en cours de développement. Cela ressort des récentes modifications apportées au code du script CreateExOPSSession. Ce dernier détecte si le script s’exécute dans ACS et met à jour les paramètres du script dynamiquement. Un court extrait du noyau est visible ci-dessous :

Oui, ce sont exactement les mêmes variables environnementales que nous avons vues dans la section précédente. Et c’est ainsi que je sais que le module est en cours de préparation pour ACS.