PowerShell リモート処理をワークグループ（ドメインなし）で動作させる方法
ドメインに参加していないコンピューターにPowerShell Remoting（PSRemoting）を設定するのは、少々面倒な作業です。ワークグループ内のコンピューターに接続しようとして、認証やTrustedHostsに関する不可解なエラーに遭遇した経験があるなら、それはあなただけではありません。基本的に、WinRM（Windowsリモート管理）はデフォルトでKerberosを使用しており、これにはドメインが必要です。しかし、ワークグループでは、NTLMに切り替えたり、SSL証明書を設定したりする必要があります。このガイドでは、そのような状況でPSRemotingを動作させる方法について説明します。Active Directoryを完全に設定せずに、スクリプトを実行したり、リモートPCを再起動したりする必要がある場合があるからです。ある設定ではすぐに使えるかもしれませんが、別の設定では、ネットワークプロファイル、ファイアウォール、TrustedHostsを細かく調べる必要があります。目標は？これらのコンピューターがドメインのないローカルネットワークに接続している場合でも、PowerShellコマンドをリモートで安全かつ確実に実行できるようにすることです。—
ワークグループ環境で PowerShell リモート処理を修正する方法
リモートホストでWinRMサービスを有効にする
これはまさにステップ0です。WinRMが動作していなければ、他のことは何も問題になりません。重要なのは、サービスが動作していないとリモート接続ができないということです。 – 接続先のマシンにログインします（RDP経由または物理的に接続）。 – PowerShellを管理者として開きます。 – WinRMサービスが動作しているかどうかを確認します。
Get-Service -Name "WinRM" | select status– 実行されていない場合は、サービスを開始し、自動開始に設定します。
Enable-PSRemoting -Forceこのコマンドは、WinRMの有効化、ファイアウォールルールの有効化、そしていくつかのデフォルト設定の調整など、一度に多くの処理を実行します。ただし、ネットワークの種類がパブリックに設定されている場合は、次のエラーが表示されるので注意してください。
Set-WSManQuickConfig :...WinRM firewall exception will not work since one of the network connection types on this machine is set to Public.Windowsはネットワークをパブリックと認識するため、必要なファイアウォールルールをブロックします。これをプライベートに変更する必要があります。- 次のコマンドを実行してください。
Set-NetConnectionProfile -NetworkCategory Privateまたは、そのチェックを完全にスキップしたい場合（非常に安全ではありませんが、高速です）、次を実行します。
Enable-PSRemoting –SkipNetworkProfileCheck—
Windows Defender ファイアウォールを介したリモート接続を許可する
次に、TCPポート5985（HTTP）が受信接続用に開いていることを確認する必要があります。これはPowerShellで実行できます。- 管理PCのIPからのみ許可する場合（より安全）：
Set-NetFirewallRule -DisplayName "Windows Remote Management (HTTP-In)" -RemoteAddress 192.168.13.100 -Action Allow– または、全員に公開します (安全性は低くなりますが、必要な場合もあります)。
Set-NetFirewallRule -DisplayName "Windows Remote Management (HTTP-In)" -RemoteAddress * -Action Allowヒント: ルールが有効になっていてアクティブであることを常に確認してください。
Get-NetFirewallRule -DisplayName "Windows Remote Management (HTTP-In)"—
クライアントマシンでTrustedHostsを構成する
ここで現実は複雑になります。ワークグループでは Kerberos が利用できないため、WinRM は NTLM または HTTPS にフォールバックしますが、NTLM が機能するには、クライアント マシンがリモート マシンを信頼する必要があります。 – 管理 PC で、ターゲットの IP または FQDN を TrustedHosts リストに追加します。
Set-Item wsman:\localhost\Client\TrustedHosts -Value "192.168.13.222" -Force– 現在のTrustedHostsを確認するには:
get-Item WSMan:\localhost\Client\TrustedHosts– TrustedHosts をクリアするには:
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "" -Force– 複数を追加するには (-Concatenate を使用):
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "192.168.13.222" -Concatenate 警告: *TrustedHosts で ` ` を使用することは、ドアを大きく開けたままにすることと同じです。積極的にテストしているのでなければ、お勧めしません。—
リモートでの接続とコマンドの実行
WinRM が有効になり、ファイアウォール ルールが設定され、TrustedHosts が構成されたら、接続をテストする必要があります。 – 接続を確認します。
Test-NetConnection 192.168.13.222 -Port 5985– ターゲット上の WinRM を確認します。
Test-WsMan 192.168.13.222それがチェックされたら、リモート PowerShell セッションの作成を試みます。
Enter-PSSession -ComputerName 192.168.13.222 -Credential (Get-Credential) *注:* 資格情報の入力を求められます。ユーザー名は ` COMPUTERNAME\username` の形式にするか、ローカルに同じユーザーが存在する場合はローカルのユーザー名のみを入力してください。トラブルシューティングのヒント: 接続または認証に関するエラーが発生した場合は、リモートマシンが Kerberos のみを受け入れるかどうか (ワークグループではこれは不可能)、または認証スキームを切り替える必要があるかどうかを確認してください。 – 認証スキームを確認します。
Get-ChildItem -Path WSMan:\localhost\Service\Auth\– NTLM を使用する場合は、リモート TrustedHosts が設定されており、Kerberos を使用しないように注意してください。—
セキュリティ強化のため、CredSSP または HTTPS を使用する
NTLMは、特に大きく開いた場合、脆弱になる可能性があります。代替案としては、リモートマシンにSSL証明書付きのIISを設定し、HTTPS経由で接続する方法があります。この方法ではTrustedHostsの調整は不要です。あるいは、CredSSPを使用して資格情報を安全に委任することもできますが、こちらはより高度な方法です。—
一般的なコマンドの概要
- WinRM を有効にする:
Enable-PSRemoting -Force - ネットワークプロファイルをプライベートに変更します:
Set-NetConnectionProfile -NetworkCategory Private - ファイアウォールポート5985を開きます:
Set-NetFirewallRule -DisplayName "Windows Remote Management (HTTP-In)" -RemoteAddress * -Action Allow - TrustedHostsにIPを追加します:
Set-Item wsman:\localhost\Client\TrustedHosts -Value "192.168.13.222" -Force - WinRM接続をテストします:
Test-WsMan 192.168.13.222 - リモートマシンに接続:
Enter-PSSession -ComputerName 192.168.13.222 -Credential (Get-Credential)
—
まとめ
ワークグループでPSRemotingを動作させるのは、特にWindowsのデフォルトのセキュリティ設定がドメインなしのリモート管理を阻んでいるため、少々面倒です。それでも、上記の手順に従えば問題なく動作します。ただし、ネットワークの信頼性も重要です。よほどの事情がない限り、TrustedHostsを*に設定したままにしないでください。また、大規模環境や機密性の高い環境では、HTTPSまたは証明書ベースの認証が最適であることも覚えておいてください。これで、誰かのフラストレーションが少しでも軽減されることを願っています。必ずしも簡単ではありませんが、実現可能です。少なくとも以前よりは楽になりました。