treedown’s Report

システム管理者に巻き起こる様々な事象を読者の貴方へ報告するブログです。会社でも家庭でも"システム"に携わるすべての方の共感を目指しています。

※https化しました。その影響でしばらくリンク切れなどがあるかもしれませんが徐々に修正していきます。 リンク切れなどのお気づきの点がございましたらコメントなどでご指摘いただけますと助かります。

Windows Server 2022で共有名にOptionalNamesキーが使えるか確認する

以前Windows Server 2019で実施した内容をWindows Server 2022でもう一回やってみた検証内容のご報告です。
LanManagerはレガシな技術なので需要も少なそうな内容です。

環境と動機

ファイルサーバを統合する時に、旧サーバと新サーバの二台を一台に集約しつつ、共有名は旧サーバ名と新サーバ名の両方を使えるようにWindows Serverを設定したい、と言うときに、レジストリキーを操作してこの動きを実現していました。

以前の検証:
一台のファイルサーバで複数ホスト名で(一台を)参照できるようにする - treedown’s Report

今回はWindows Server 2022(評価版)でこれを実施してみることにします。

設定1:複数のサーバ名を登録する

レジストリエディタから実施します。

"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters"

を開きました。

※一部修正済の画像です。

ここのレジストリキーに、新規作成します。

今回は「複数文字列値」を設定します。

名前は"OptionalNames"と指定し、値のデータの編集は、

このように、ファイルサーバ名となる文字列を複数記述します。
完了後、OKボタンをクリックして終了。

"OptionalNames"がこのように登録されます。次の設定へ。

設定2:複数ホスト名の有効化

設定1と同じ
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters"
に、次はDWORD値を設定します。

設定するDWORD値の名前を、"DisableStrictNameChecking"とします。

作成したDWORD値:DisableStrictNameCheckingを開いて、値を編集します。

デフォルト「0」の値のデータを「1」に編集します。完了後OKボタンをクリック。

できました。

この状態で、Windows Serverを再起動します。反映のためにはOS再起動が必要です。

また前回も記載しましたが、"OptionalNames"に登録したサーバ名と同一名称のコンピュータが同一ネットワーク上に存在しないように対処しておく必要があります。同一のコンピュータ名が存在していた場合、コンピュータ名重複エラーが発生します。

再起動後の動作確認

OS再起動後に、有効になったファイルサーバのコンピュータ名(ホスト名)を確認していきます。

設定したサーバ上でテスト用の共有フォルダを二つ作成しました。

この共有が他のPCからネットワーク経由で閲覧、書き込みが出来るかどうかを確認していきます。

同じネットワーク内のWindows10 PCからアクセスしてみたところ、

"OptionalNames"に登録したサーバ名「\\FileSVR-A」でも「\\FileSVR-B」でも同じサーバ上の共有フォルダをエクスプローラで開くことができました。

さらに、この共有フォルダの中身を編集してみると、

問題なく編集して書き込み、保存まで出来ました。特に問題なさそうです。

Windows11も動作は同じ

気になったので、Windows11から対象のサーバへアクセスしてみました。

特に問題なく、

「\\FileSVR-A」や「\\FileSVR-B」の両方の指定でアクセスできることが確認出来ました。加えて、サーバの本名「\\WIN-S06QP2N6CJO」でも同じアクセスが出来ています。

ただし、Windows11で気になる話題が

編集したレジストリのキー名が表現しているように、おそらくこの仕組みはNTLMを使っていると考えられます。そこで気になるのがWindows11でNTLM廃止(段階的な廃止)をMicrosoftが公表している点です。

Microsoftとしては既にレガシなNTLMをKerberos認証に置き換えることを推奨しており、徐々にNTLMを終息に向けて活動していく動きがあります。

参考:

techcommunity.microsoft.com

現状ワークグループ環境のWindows認証はNTLMが使われていることもありそうですが、いずれKerberos認証への置き換えが必要になるという可能性が高いとみられています。その場合には、新しいKerberos認証である「IAKerb」および「Local KDC」という仕組みを理解して組み込んでいかないといけないのかもしれません。まだ知識が追いついていませんが。