2 votes

La meilleure approche pour accéder au serveur dans la zone démilitarisée (hors domaine) depuis le réseau local via la ligne de commande (MS Windows).

J'ai deux serveurs :

SVR1 (Windows Server 2008) dans le LAN - partie du domaine

SVR2 (Windows Server 2008) en DMZ - groupe de travail

J'ai besoin d'accéder à SVR2 à partir de SVR1 via une ligne de commande batch - copier quelques fichiers et exécuter la commande sc pour gérer les services sur SVR2. Ce lot est planifié et je dois donc accéder à SVR2 sans avoir à saisir d'informations d'identification.

La seule possibilité que je connaisse est d'avoir le même nom d'utilisateur et le même mot de passe sur les deux serveurs mais ce n'est pas aussi gracieux et c'est un risque potentiel.

Quelle est la meilleure approche pour résoudre mon problème ? Le mieux serait de le faire sans logiciel tiers.

2voto

Ryan Ries Points 54671

Comme SVR1 et SVR2 ne font pas partie du même domaine AD, vous devrez stocker les informations d'identification pour SVR2 quelque part sur SVR1 pour que votre script automatisé puisse y accéder.

En utilisant WinRM et une mise à jour suffisante de Powershell, Powershell Remoting vous permettra d'établir une connexion de SVR1 à SVR2 et de faire tout ce que vous pouvez imaginer sur une ligne de commande de manière automatique.

Vous pouvez enregistrer un mot de passe dans le coffre-fort des justificatifs Windows à l'aide de Powershell et votre script peut accéder aux justificatifs à partir du coffre-fort des justificatifs :

https://gallery.technet.microsoft.com/scriptcenter/How-to-add-credentials-to-c8e9bd5f

Je recommanderais cette solution comme un moyen un peu plus efficace de stocker les informations d'identification. L'ancienne méthode classique de stockage des informations d'identification consistait à faire quelque chose comme ceci :

read-host -assecurestring | convertfrom-securestring | out-file operationspassword.txt

Ensuite, dans votre script, "décryptez" le mot de passe comme suit :

$pass = Get-Content operationspassword.txt | convertto-securestring
$creds = New-Object -Typename System.Management.Automation.PSCredential -argumentlist "SRV2\admin",$pass

Les lettres de créance "cryptées" ne peuvent être décryptées que par le même compte et sur la même machine où elles ont été cryptées à l'origine, de sorte que vous ne pouvez pas simplement voler la représentation textuelle de la SecureString et l'utiliser ailleurs. Mais il n'est toujours pas professionnel de stocker les références de cette manière et je ne le conseille pas vraiment en général.

N'oubliez pas non plus de modifier votre liste Powershell TrustedHosts pour autoriser les connexions à la machine "untrusted"... vous devez le faire car vous n'utilisez pas Kerberos ou SSL.

Cela me rappelle... utilisez SSL pour les connexions WinRM pour une meilleure sécurité : http://support.microsoft.com/kb/2019527

Les ports WinRM de Windows 2008 sont 80 (HTTP) et 443 (HTTPS).

Microsoft s'est vite rendu compte que ces ports étaient en quelque sorte déjà utilisés, et donc :

Les ports WinRM de Windows 2008 R2 et plus sont 5985 (HTTP) et 5986 (HTTPS).

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X