Windows PowerShell : Faites le deuxième saut
Vous pouvez rencontrer quelques situations délicates lorsque vous utilisez la communication à distance avec Windows PowerShell. Faites juste attention au nombre de fois que vous effectuez le saut.
Don Jones
Communication à distance de Windows PowerShell est une façon incroyable de gérer plusieurs ordinateurs distants comme facilement comme si vous ont été seulement gérer un. Dans un environnement de domaine, ça marche. Après avoir dit qu'il y a quelques mises en garde à surveiller qui peut vraiment gâcher vous. Le « deuxième hop » est de ceux-là.
Une chose particulièrement cool sur la communication à distance, c'est comment il s'intègre aux technologies spécifiques de Windows, tels que le protocole d'authentification Kerberos. Contrairement aux anciens outils qui peuvent accepter et exécuter des commandes à distance, accès distant ne s'exécute pas sous un compte LocalSystem tout-puissants. Au lieu de cela, lorsque vous vous connectez, vos informations d'identification Windows (celle avec laquelle vous connecté ou indiquée au moment de la connexion) est déléguée à l'ordinateur distant ou les ordinateurs.
La délégation est une fonctionnalité native de Kerberos et Active Directory. Il est complètement sûr. Votre mot de passe n'est pas transmis sur le réseau dans le clair, chiffré ou non. Tout au plus, il est utilisé comme une clé de chiffrement partagée.
Délégation signifie que copie de l'ordinateur distant de Windows PowerShell peut exécuter des commandes comme vous le faites, ce qui signifie qu'accès distant devient transparent de sécurité. Tout ce que vous êtes autorisé à faire, vous serez en mesure de le faire à distance. Si vous n'avez pas l'autorisation, vous ne pouvez pas le faire. Communication à distance est l'exécution des commandes comme vous.
Si vous vous asseoir à votre ordinateur client et se connectez au serveur a, qui est un ordinateur distant. Vos informations d'identification sont déléguée à cet ordinateur. Partir de ServeurA, vous lancez maintenant une autre connexion quelconque à un tiers de l'ordinateur. Qui ne doit pas être une connexion d'accès distant. Essayez de mapper un lecteur réseau sur cet ordinateur tiers, d'accéder à un magasin de certificats ou de faire autre chose. Vous venez de faire un deuxième saut.
Le premier tronçon a été depuis votre client au serveur a. La seconde est de ServeurA à l'autre ordinateur auquel vous cherchez à vous connecter. Le problème se pose parce que vos informations d'identification ne peuvent être déléguées à une seconde fois.
C'est en fait une fonctionnalité de sécurité, conçue pour empêcher que vos informations d'identification soient passées autour sans votre connaissance. Si votre deuxième hop échoue, car le serveur n'est pas en mesure d'envoyer des informations d'identification le long du trajet.
À peu près toutes les classes Windows PowerShell que j'ai enseigné, il y a quelqu'un qui a rencontré ce. Il est facile d'oublier que vous êtes distants dans une machine parce qu'il est si transparente et simple à faire. Il est donc facile de se retrouver à télécommande pour une troisième machine sans se rendre compte que vous êtes lance un deuxième saut.
Il n'y a aucune délégation des informations d'identification, le deuxième saut échoue, vous voyez des messages d'erreur bizarre et tout le monde finit par confus. Cela peut se produire même dans certains cas où vous n'avez qu'un saut, mais vous essayez d'effectuer une opération sur l'ordinateur distant nécessitant des informations d'identification déléguées.
Le Windows PowerShell Blog post, "CredSSP pour le deuxième saut remoting,» décrit ce qui se passe. Il décrit également le correctif, ce qui est de permettre le nouveau protocole d'authentification CredSSP. Ceci doit être activé sur votre ordinateur client et toutes les machines auxquelles vous prévoyez à distance. Vous pouvez exécuter une commande afin de lui permettre :
Enable-WSManCredSSP –Role client –DelegateComputer * Enable-WSManCredSSP –Role server
Il devrait être évident que l'on obtient exécuté sur le client et dont une sur le serveur. Vous pouvez également activer ce protocole à travers un objet de stratégie de groupe (GPO) dans les paramètres de Windows Remote Management (WinRM). Vous devez également spécifier le protocole CredSSP lorsque vous utilisez Invoke-Command, Enter-PSSession, New-PSSession ou toute autre applet de commande qui utilise la communication à distance.
Consultez le PDF gratuit, "Guide de profane à PowerShell 2.0 Remoting," de Ravikanth Chaganti. Il comprend plus de détails (en particulier dans le chapitre 10) sur le deuxième bonds et comment résoudre toute confusion. Par exemple, il note que les contrôleurs de domaine n'ont pas besoin CredSSP afin de faire de la magie du deuxième tronçon, parce qu'ils sont configurés pour prendre en charge par défaut.
Il y a un tas d'autres scénarios difficiles, que vous pouvez rencontrer avec accès distant. Vous pouvez rencontrer non-domaine ordinateurs, connexions inter-domaines, accès distant via un serveur proxy et ainsi de suite. Dans Windows PowerShell, exécutez about_remote_troubleshooting aide pour lire des instructions détaillées pour s'occuper de ces et d'autres scénarios. Si vous êtes toujours coincé, envoyez-moi une ligne.
.jpg)
Don Jones est un destinataire Microsoft MVP Award et auteur de "Apprendre Windows PowerShell dans un mois de repas » (Manning Publications, 2011), un livre conçu pour aider n'importe quel administrateur devenir efficace avec Windows PowerShell. Jones offre également une formation de Windows PowerShell publique et sur place. Vous pouvez le contacter via ConcentratedTech.com ou bit.ly/AskDon.