【世界初】Windows Server 2025でSMB over QUICを実装してみた(ドメイン環境)03 ～確認作業編～

はい。
昨日の記事の続きです。
ちょっと雑だったのと確認作業が抜けていたので最後の確認作業の前に実施ます。

VPN接続確認

Azure 仮想ネットワークゲートウェイ側

RTX1300側で適切な設定を行えばVPN接続は瞬殺ですね。

はい。
つながっています。

オンプレミスRTX1300側

RTX1300が故障して一時的にRTX1210を使っていますが、確認方法は同じです。

yamaha_sample.config

show status tunnel [トンネル番号]

ですね。
私の実際の環境だと

yamaha.config

show status tunnel 25

です。
結果は以下の通り

はい。
ちゃんとつながっていますね。

Azure上のWindows 11の確認

項目	設定値
OS	Windows 11 22H2
ホスト名	vm-client01
ローカルIPアドレス	192.168.201.11

ですね。

まとめた画像がこちら。
デフォルトだとネットワークプロファイルがPublicになっているのでPrivateに変更してローカルからもICMP返るように設定変更しましたが、それ以外はデフォルト設定のままです。
時刻くらいJSTにせんかいって話ですね。

ドメイン参加

はい。
参加できるっぽいですね。

はい。
参加できました。
再起動しても

はい。
ちゃんとドメイン参加できましたね。

項目	設定値
OS	Windows 11 22H2
ホスト名	vm-client01
ローカルIPアドレス	192.168.201.11
ドメイン参加	参加済み(sh-style.info)

となりました。

証明書インストール

で、以前の記事の通り、証明書をインストールします。

はい。
無事ンストールできましたね。

キャッシュログオンの有効化

ドメコンのGPOでキャッシュログオンを有効化します。

ドメコンにログインして操作

ドメコンにログインしてGPOの設定画面を開きます。
対象のコンピューターの所属するOUにあたっているGPOを編集します。
私の環境ではご多分に漏れずDefault Domain Policyです。
コンピューターの構成→ポリシー→Windowsの設定→セキュリティの設定→ローカルポリシー→セキュリティオプションを開き、以下の2点を設定変更します。

ポリシー名	設定値
対話型ログオン:workstationのロック解除にドメインコントローラーの認証を必要とする	無効
対話型ログオン:キャッシュする過去のログオン数(ドメインコントローラーが使用できない場合)	有効、かつ10(最低1でもOKですが、デフォルトで10なのでそのまま。ちなみに最大値は50)

以下の図の赤枠内です。

多分キャッシュログインするだけならキャッシュ10の方だけでいけそうなんですが、ロックされた場合を考えてロック解除のポリシーも設定します。

クライアントPCにログインして操作

前の手順で作成したGPOをクライアントPCに適用します。
gpupdate /forceを実行してgpresult /H [適当な名前].htmlを実行し、対話型ログオン(Intaractive Logon)でキャッシュが有効になっているか確認します。
私は[適当な名前]の部分にだいたい日付時間分_01として一意になるように命名します。

赤枠部分で設定が確認できます。
GPOで設定した通りのパラメーターが落ちてきています。

ファイルサーバ側準備

ファイルサーバの状況を確認して設定していきましょう。

ドメイン参加等々各種パラメータ確認

項目	設定値
OS	Windows Server 2025
ホスト名	win2k25-03
IPアドレス	172.16.0.69
ドメイン参加	参加済み(sh-style.info)

証明書インストール

こちらも証明書をインストールします。
前々回の記事で作成したPFXファイルを
ローカルコンピューター→個人にインポートします。

はい。
証明書もインストールしました。

コマンドでSMB over QUICとインポートした証明書を関連付ける。

これも前々回の記事と同じくコマンドで設定します。

記事執筆時の7月6日時点ではWindows Server 2025における本操作はPower Shellのみでサポートされています。

以下のコマンドを実行します。

smb_mapping_sample.ps1

New-SmbServerCertificateMapping -Name [関連付ける証明書のDisplay名] -Thumbprint [関連付ける証明書の拇印] -Store My

[関連付ける証明書のDNS名]は各環境に合わせてチューニングしてください。
私の環境だとDNS名がwin2k25-03.sh-style.infoとなります。
証明書の拇印は

ここから取得します。
これを踏まえると私の環境で実行するコマンドは以下のようになります。

smb_mapping.ps1

New-SmbServerCertificateMapping -Name win2k25-03.sh-style.info -Thumbprint "9e5c6f8999ff970c550bbd1fdecbccc508301df9" -Store My

となります。
実行後、

このようになれば成功です。
この証明書のマッピングの処理は非ドメイン環境と変わりません。

その他ルーターやDNSの設定

前々回の記事と実施する内容は同じなので割愛します。

動作確認

はい。
お待ちかねの動作確認です。
はてさてうまくいくでしょうか？

まずはAzure-オンプレミス間のVPNを切断する

これでAzure上のWindows 11がオンプレミスのファイルサーバにローカルIPアドレスで直接通信できなくなります。
SMB over QUICは社外からVPN接続を行わずとも、Windows Client OSのエクスプローラー機能でファイルサーバにアクセスできるというのが最大の特徴ですから、これを行うにはVPNが接続されていては困りますね。

はい。
YAMAHA側でVPNを切断しました。

ドメインユーザーでログインしてファイルサーバのローカルIPアドレスでアクセスできないことを確認

これでキャッシュログインし、TNCを使いTCP445番ポートでファイルサーバにアクセスできないことを確認します。

はい。
無理ですね。

アクセス確認

\\win2k25-03.sh-style.info\sharedfolder01
にアクセスします。

これで実行すると・・・

アクセスできました！

もちろん権限制御は効くんやんな？

はい。
確認しましょう。
まずはファイルサーバーに以下のようなフォルダを作成し

sharedfolder_AにはA_Divisionというドメイン内のSGにアクセス権を与え、それ以外のSGには権限を与えませんます。
sharedfolder_BにはB_Divisionというドメイン内のSGにアクセス権を与え、それ以外のSGには権限を与えません。
これでA_Divisonに所属するdomain.user01というユーザーでWin11にRDPでログインし、sharedfolder_Aにアクセスでき、sharedfolder_Bにアクセスできなければ権限制御できていることになります。

ドメインユーザー、SGの入れ子関係を確認

まずはドメイン内のSGとユーザーの入れ子関係から確認します。

はい。
A_DivisionというSGにはdomain.user01というユーザーが所属していますね。

はい。
B_DivisionというSGにはdomain.user01というユーザーは存在しません。

ファイルサーバーのフォルダ権限確認

ファイルサーバーにログインして確認しましょう。

はい。
このファイルサーバーのこのフォルダ構成です。
簡単ですね。
まずはsharedfolder_Aから

はい。
sharedfolder_AにはA_Divisionしか権限が付与されていません。
続いてsharedfolder_Bです。

はい。
sharedfolder_BにはB_Divisionしか権限が付与されていません。

Windows 11で権限確認

ではWindows 11にログインして確認します。

A_Divisionに所属するdomain.user01というユーザーでsharedfolder_Aにアクセスします。

ｷﾀ!

アクセスできました！
では拒否されるであろうsharedfolder_Bにアクセスします。

ｷﾀｷﾀ!
アクセスできませんでした！
完璧ですね！

長かった！！！

本日はこれまで！！！！