WinRMがホスト名では動作するのにFQDNでは動作しない(あるいはその逆の)時のチェックポイント

下記は過去ebisuda.comで公開していた記事です。今はebisuda.comでは見られなくなってしまっておりますが、そこから有用だと思う記事をnoteに転載しておきます。

---

皆さんこんにちは。胡田です。 いやー。久しぶりにほんのちょっとした当たり前の事でどハマリしてしまいました。しかも2度も。自戒を込めてこのエントリを書き残しておきたいと思います…。

事象例

複数の事象やそのバリエーションがあります。

• WinRMがホスト名では動作するが、FQDNでは動作しない。あるいはその逆。

• Windows Admin Centerにサーバーを追加する際に、ホスト名ではうまく動作するがFQDNでは動作しない。あるいはその逆。

• Test-ClusterがWinRMでの接続不可で失敗する。

• Enter-PSSession, Invoke-Command等がホスト名では動作するがFQDNでは動作しない。あるいはその逆。

チェックポイント

winrmのリスナーがきちんと意図したとおりに登録されているか？ winrm enumerate winrm/config/Listener を実行し、リスナーの登録状況を確認し、意図する構成になっているかどうか確認します。

PS C:\Windows\system32> winrm enumerate winrm/config/Listener
Listener
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 127.0.0.1, 172.17.112.177, ::1, fe80::fc36:5d9e:4649:cbd5%5

例えば上記の例であればHTTPのリスナーのみが構成されています。HTTPSのリスナーは構成されていません。全てのIPアドレスで受け付けるように構成されています。ポート番号は5985です。 また、「Hostname」は特に限定されていません。ですので、ホスト名でもFQDNでもどちらでも受け付ける事ができます。Hostnameが具体的に登録されていた場合にはそのホスト名でしか受け付けませんので注意が必要です。 上記の例ではHTTPのみですが、HTTPSも構成されている場合には証明書との関係で必ずホスト名が固定的に設定されます。そのホスト名と合致していないとうまく動かないことになります。下図はHTTPも構成してある状態です。

https://ebiwordpress.azureedge.net/windowsadmin/D8wJBTqU0AAqrYz.png

SPNが正しく登録されているか？重複していないか？

Kerberos認証のためにはSPN(=Service Principal Name)が正しく登録されている必要があります。そして、重複していない状況である必要があります。 WinRMで利用するSPNは「WSMAN/ホスト名」という形式になります。 「Active Directory ユーザーとコンピューター」で直接LDAPクエリを入力して重複を調べることができます。

https://ebiwordpress.azureedge.net/windowsadmin/2019-09-25_17h50_18.png

上記の図の例だと、WSMAN/s2dnode1*で検索した結果、1つのコンピューターオブジェクトのみが表示されているので、重複していないことが確認できたことになります。もしも2つ以上のオブジェクトが検索にヒットするようなら重複している可能性が大です。具体的に属性値を確認して、必要なら片方から削除する必要があります。

https://ebiwordpress.azureedge.net/windowsadmin/2019-09-25_17h57_45.png

上記の図はADSIエディターにて具体的に該当のコンピューターオブジェクトのservicePrincipalNameを確認しているところです。きちんとホスト名のみとFQDNの両方が登録されており、両方動作可能に構成されていることが確認できます。もしも重複しているなら、どちらかのオブジェクトから削除します。

Proxy経由の通信になっていないか？

WinRMの通信はwinhttpを使用します。よって、winhttpのproxy設定の影響を受けます。netsh winhttp show proxyコマンドで現在のwinhttpの設定を確認できます。

PS C:\WINDOWS\system32> netsh winhttp show proxy
現在の WinHTTP プロキシ設定:

直接アクセス (プロキシ サーバーなし)。

上記のようになっていれば、proxy無しの直接通信となります。この設定の場合にはproxy設定として問題が出ることは無いでしょう。

PS C:\WINDOWS\system32> netsh winhttp show proxy

現在の WinHTTP プロキシ設定:

    プロキシ サーバー:  proxy:8080
    バイパス一覧     :  <local>

上記のようにProxyを設定しているけれども「ローカルアドレスは除外する」設定になっている場合に問題が起きやすいです。 Windowsのproxy設定で言うところの<local>は同一サブネットというような意味合いではなく、「ホスト名に.(ドット)を含まない」という意味合いになります。つまり上記の設定の場合にまさに「ホスト名ではうまく動くのに、FQDNではうまく動かない」という挙動になります。 参考：「インターネットに繋がらない」 – Proxy編 | Windowsインフラ管理者への道 上記の問題回避のために、必要に応じてきちんとバイパス設定を入れてあげて下さい。例えばドメイン(sample.local)内のサーバーへのアクセスはproxy経由にしないようにしたければ、下記のように設定します。

PS C:\WINDOWS\system32> netsh winhttp show proxy

現在の WinHTTP プロキシ設定:

    プロキシ サーバー:  proxy:8080
    バイパス一覧     :  *.sample.local;<local>

なお、このwinhttpのproxy設定はnetshコマンドで直接設定してもいいですが、IEでproxy設定をした上でその設定をimportするのがお手軽でおすすめです。IEと一緒のほうが混乱も少ないでしょうし。それは下記コマンドで実現できます。

netsh winhttp import proxy ie

そして、私は、このwinhttpのproxy設定できちんと除外していないことに気が付かずに随分と長い時間を無駄にしてしまったのでした…。 皆さんはお気をつけ下さい！