2020年8月に「Windows Server 2019のワークグループ環境でリモートデスクトップサーバを構築する」という記事を書きました。ドメインコントローラーのない環境でRDSを立てたら「リモートデスクトップライセンスに問題があるため、このセッションは60分後に切断されます」と怒られ、ローカルグループポリシーでライセンスモードを「接続デバイス数」に変えたら解決した、という内容です。記事の最後に追記として、接続デバイス数（Per Device）なら動くが接続ユーザー数（Per User）はダメで、その場合はADが必要と書きました。
あれから6年が経ち、Windows Serverは2022を経て2025になりました。当時の話はまだ通用するのか。ワークグループという「ADを使わない構成」そのものが、Microsoftの中でどう扱われているのか。小規模拠点やDMZ、閉域の検証環境など、ADを立てるほどでもない場所は今も現場に山ほどあります。改めて調べ直してみました。
結論を先に書きます。元記事の結論は2026年8月現在もそのまま有効です。ワークグループではPer Device CALのみ、Per UserはAD必須。これはMicrosoftの現行ドキュメントに今も明記されています。ただし「変わっていないのはそこだけ」でした。周辺の認証基盤は静かに、しかし決定的に作り替えられつつあります。ワークグループ運用の土台であるNTLMが非推奨になり、SMBは既定でハードニングされ、その代わりにワークグループでもKerberosが使える仕組みが準備されている。以下、順に見ていきます。
1. まず答え合わせ：ライセンス制約は6年間まったく変わっていない
Microsoft LearnのRDS CAL解説ページには、Per DeviceとPer Userを比較する表があります。そこでPer Deviceには「Active Directoryのメンバーシップに関係なく追跡できる」、Per Userには「ワークグループ内では追跡できない」と書かれています。適用対象にはWindows Server 2025が筆頭で並んでいます。
なぜこうなるのか、理屈を押さえておくと納得しやすくなります。Per User CALは、発行したライセンス情報をADのユーザーオブジェクトの属性に書き込んで管理する仕組みです。書き込む先のADがないワークグループでは、そもそも発行・追跡の器が存在しません。一方Per Device CALは、接続してくるデバイス側にライセンスを紐づけるので、ADの有無と無関係に成立します。2020年に私が遭遇した60分切断は、この「器がない」状態でPer Userを要求していたことの現れだったわけです。
対処法も当時のままです。gpedit.msc で「コンピューターの構成 → 管理用テンプレート → Windowsコンポーネント → リモートデスクトップサービス → リモートデスクトップセッションホスト → ライセンス」を開き、「リモートデスクトップライセンスモードの設定」を有効にして「接続デバイス数」を選ぶ。ライセンスサーバーも同じ場所で明示指定します。1台のセッションホストが要求できるモードはPer DeviceかPer Userのどちらか一方だけ、という制約も変わっていません。
| 項目 | 2019（2020年当時） | 2022 | 2025（2026年8月現在） |
|---|---|---|---|
| ワークグループでのPer Device CAL | 可 | 可 | 可 |
| ワークグループでのPer User CAL | 不可（60分切断） | 不可 | 不可（公式に非サポート） |
| グループポリシーでのライセンスモード手動設定 | 必要 | 必要 | 必要 |
| RDS CALのバージョン互換 | 下位互換のみ | 下位互換のみ | 2025ホストには2025 CALが必須 |
最後の行は移行時に効いてくるので補足します。RDS CALは下位互換のみです。2025 CALを持っていれば2022や2019のセッションホストに使えますが、逆はできません。つまりセッションホストを2025に上げるなら、2025のRDS CALを新規に買う必要があります。OSのアップグレードだけ考えて予算を組むと、ここで足が出ます。
なお、ワークグループでもPer Userを設定すること自体は技術的には可能です。しかし追跡も強制も行われないため、「セッションは張れるがライセンス管理としては成立しておらず、Microsoftのサポート対象外」という状態になります。Microsoftの見解は一貫して「ワークグループではPer Deviceのみ」です。
2. 逆に「ワークグループでできること」は増えている
ワークグループは冷遇されている、という印象を持たれがちですが、実は正式サポートの範囲は広がっています。
代表がフェールオーバークラスタリングです。ワークグループクラスター（ADに参加しないノードでクラスターを組む構成）はWindows Server 2016で導入され、現行ドキュメントの適用対象にも2025・2022・2019・2016とAzure Localが並んでいます。ADは不要ですが、DNSは必要です。
そして2025での大きな前進が、ワークグループクラスターでのライブマイグレーション対応です。ワークグループクラスター自体は2016からありましたが、その上でHyper-Vのライブマイグレーションを行うことは長らくサポート外でした。Windows Server 2025で初めて正式にサポートされ、Microsoft Learnに手順が用意されています。
仕組みは、各ノードに同じユーザー名・同じパスワードのローカルアカウントを作り、クラスターが自己署名証明書によるPKU2U認証でノード間の信頼を確立するというものです。Kerberosを使わずにVMを移動させられる。ADを立てるほどの規模でない2ノード構成のエッジ・拠点サーバーには、現実的な選択肢が増えたことになります。
ファイル共有の面ではSMB over QUICが効きます。2022ではAzure Editionだけの機能でしたが、2025ではStandard／Datacenterを含む全エディションで使えるようになりました。TLS 1.3と証明書でSMBを丸ごと暗号化し、UDP 443で通すので、VPNなしで境界越しのファイルアクセスができます。ADに依存しない証明書ベースの認証という意味で、ワークグループとの相性は悪くありません。
Hyper-V Replicaも同様で、ワークグループや信頼関係のないドメイン間ではもともと証明書ベース認証（HTTPS）が必須です。この設計は2019から2025まで一貫しています。
3. その一方で、足元のNTLMが崩れ始めている
ここからが本題です。ワークグループ運用でいちばん注意すべきなのは、実はRDSライセンスではなく認証プロトコルの世代交代です。
前提として押さえておきたいのは、ワークグループは本質的にNTLMに依存しているという事実です。Kerberosは鍵配布センター（KDC）を持つドメインコントローラーがあってこそ機能します。DCのないワークグループでは、サーバー間のファイル共有もWinRMもRDPも、最終的にNTLMにフォールバックする。Microsoft自身も、ワークグループのメンバーやDC以外でのローカルログオン認証ではNTLMが今も使われている（使われざるを得ない）と認めています。
そのNTLMが、2024年6月に非推奨（deprecated）と宣言されました。Microsoft Learnの「Windowsクライアントの非推奨の機能」ページは、LANMAN・NTLMv1・NTLMv2を含むすべてのバージョンのNTLMがアクティブな機能開発の対象ではなくなった、と明記しています。NTLMv1はWindows 11 24H2およびWindows Server 2025ですでに削除済みです。NTLMv2は当面動きますが、将来の削除が予告されています。
廃止の道筋は3段階で示されています。
- フェーズ1：監査 — どこでNTLMが使われているかを可視化する段階。Windows Server 2025では監査が既定で有効です。
- フェーズ2：代替手段の提供 — IAKerbとLocalKDCでNTLMなしでも成り立つようにする。一般提供は2026年後半予定。
- フェーズ3：既定で無効化 — 次期メジャーリリースでネットワークNTLMを既定オフにし、必要な場合はポリシーで明示的に再有効化させる（予定）。
直近の具体的な期日としては、BlockNTLMv1SSO レジストリキーの既定値が2026年10月に監査（0）から強制（1）へ自動的に変わる予定がアナウンスされています。手動でこのキーを配布していない環境は、放っておくと既定値が切り替わることになります。
4. Windows Server 2025のSMBハードニングが刺さるところ
NTLM廃止と並行して、SMBの既定値が大きく変わりました。ワークグループ運用に直撃する順に並べます。
SMB署名の既定要求。従来、SMB署名が既定で必須だったのはSYSVOL／NETLOGON共有とドメインコントローラーへの接続だけでした。Windows 11 24H2とWindows Server 2025からは、これがすべての接続に広がります。厳密にはWindows Server 2025は送信（アウトバウンド）接続で既定要求、Windows 11 24H2は送受信の両方です。署名を要求するとゲストアクセスも同時に無効化されるので、署名非対応の古いNASや一部のサードパーティSMBサーバーに繋がらなくなる可能性があります。ワークグループのファイルサーバー環境では真っ先に踏むポイントです。
SMB NTLMブロック。SMBクライアントが送信接続でNTLMを使うこと自体をブロックできるようになりました。グループポリシー（Lanman Workstation配下）または net use /blockntlm で制御します。これはクライアント側の機能だけで、サーバー側にはありません。注意点として、ワークグループ環境やIPアドレス直指定の接続はまさにNTLMにフォールバックする典型例なので、これを有効にすると既存の運用が止まります。例外リストが用意されているので、いきなり全面適用しないことです。
SMB認証レート制限。Windows Server 2025で既定有効です。NTLMまたはLocalKDC Kerberosの認証が失敗すると2秒の遅延を挟みます。Microsoftの試算では、毎秒300回×5分で90,000回試せていた総当たりが、同じ回数に50時間かかるようになります。SMBを外に出さざるを得ない構成では、地味ですが効果の大きい変更です。
5. 救世主候補：IAKerbとLocalKDC
「NTLMを廃止したらワークグループはどうなるのか」という当然の疑問に対するMicrosoftの答えが、この2つです。ワークグループ運用者にとっては本記事でいちばん重要な話かもしれません。
LocalKDCは、各マシンのLSAの中にKerberosのKDCを内蔵してしまう仕組みです。ローカルアカウント（SAM）に対してKerberosチケットを発行できるようにする。つまりドメインコントローラーがなくてもKerberosが使えるようになります。ワークグループがNTLMに縛られていた根本原因が解消されるわけです。
IAKerb（Initial and Pass-Through Authentication using Kerberos）は、クライアントがKDCに直接到達できない場合に、接続先サーバーをプロキシとしてKerberos認証を通す仕組みです。ネットワーク的な到達性の問題でNTLMに落ちていたケースを救います。
現状（2026年8月時点）は、2026年6月にWindows Insiderのパブリックプレビューが始まった段階です。プレビューではIAKerbが既定で有効、LocalKDCは既定で無効という構成になっています。一般提供はWindows 11 24H2およびWindows Server 2025向けに2026年後半を予定とされています。あくまで予定であり、本番環境で当てにする段階ではありません。
とはいえ、これがGAすればワークグループの設計思想は一段変わります。「ADがないからNTLMしかない」という前提が消え、NTLM既定無効化フェーズが来ても慌てずに済む。現時点でやるべきは、プレビューへの飛びつきではなく自分の環境のどこがNTLMに依存しているかの棚卸しです。Windows Server 2025なら、イベントビューアの「アプリケーションとサービス ログ → Microsoft → Windows → NTLM → Operational」で監査ログが取れます。
6. ワークグループ最大の弱点は、実はパスワード管理
技術的な話から少し離れますが、運用上いちばん怖いのはここです。
ワークグループの各サーバーは、それぞれ独立したローカルSAMだけで認証します。集中管理がないので、実務では「全台で同じローカルAdministratorパスワード」になりがちです。これはPass-the-Hashによる横展開の理想的な条件で、1台落ちれば全台落ちる構図になります。
これを解決するのが本来Windows LAPS（ローカル管理者パスワードの自動ローテーション）です。Windows LAPS自体はWindows Server 2019（2023年4月以降の更新）・2022・2025にOS標準で組み込まれています。ところが致命的な制約があります。パスワードの保存先としてActive DirectoryかMicrosoft Entra IDが必須なのです。ADもEntraもない純粋なワークグループでは、LAPSは使えません。
つまりワークグループでは、ローカル管理者パスワードのユニーク化と定期ローテーションを手作業か自前の仕組みでやるしかない。これは構造的な弱点であり、「ワークグループでいくか、ADを立てるか」を判断するとき、ライセンスや構築の手間より先に検討すべき論点だと思います。ゼロトラストの文脈でも、集中IDと条件付きアクセスが効かない構成は明確に不利です。
逆に言えば、DMZ・エッジ・閉域の検証環境など「あえてADの信頼境界から切り離したい」明確な理由があるときにワークグループを選ぶ、という整理になります。「ADを立てるのが面倒だから」で選ぶと、後でパスワード管理に苦しみます。
7. サポート期限：2019はいつまで使えるのか
元記事を読んで2019を構築した方も多いと思うので、期限を整理しておきます。日付はMicrosoft公式ライフサイクルページの値です。
| バージョン | メインストリーム終了 | 延長サポート終了 | Microsoft 365 Apps |
|---|---|---|---|
| Windows Server 2019 | 2024年1月9日 | 2029年1月9日 | 2025年10月14日にサポート終了済み（セキュリティ更新は2028年10月10日まで） |
| Windows Server 2022 | 2026年10月13日 | 2031年10月14日 | メインストリーム終了まで（セキュリティ更新は2028年10月10日まで） |
| Windows Server 2025 | 2029年11月13日 | 2034年11月14日 | サポート対象 |
日付について一点補足します。Microsoftのライフサイクルページの表示は「翌日 6:59:59 AM（太平洋時間）」というタイムスタンプで持っているため、印字値が実効終了日の+1日になっていることがあります。ネット上で2025の期限を「11月14日／11月15日」と書いているものと「11月13日／11月14日」と書いているものが混在するのはこのためです。上表は実効日で統一しています。
実務的な判断としては、RDS用途で2019を使い続ける理由はもう薄いと考えます。延長サポートは2029年1月まで残っていますが、メインストリームはすでに終了しており新機能は入りません。加えて2019上のMicrosoft 365 Appsのサポートが2025年10月に切れているので、RDSでOfficeを使う典型的な構成はすでに賞味期限を過ぎています。2022もメインストリーム終了が2026年10月13日と目前です。新規構築・更改なら、2019も2022も飛ばして2025へ直行するのが素直でしょう。2034年11月まで持ちます。
8. 周辺で消えていくもの
元記事の手法や、その周辺の運用に影響しうる廃止・非推奨をまとめます。
| 機能 | 状態 | ワークグループ運用への影響 |
|---|---|---|
| NTLMv1 | 削除済み（2025／24H2） | v1しか話せない古いNASや装置に接続できなくなる |
| NTLM全般 | 非推奨（当面は動作） | RDS・ファイル共有・WinRMが依存。将来の既定無効化に要注意 |
| WINS | 非推奨。2025より後のリリースから削除予定 | 2025では2034年11月まで標準サポート下で利用可。名前解決はDNSへ移行を |
| TLS 1.0／1.1 | 既定で無効 | 古いクライアントや業務アプリが接続不能になる場合あり |
| ネットワーク負荷分散（NLB） | 非推奨 | RDS本体には直接影響しないが冗長化設計の見直し材料 |
紛らわしいので分けて書いておきたいのがクライアント側アプリの廃止です。Microsoft Store版の「リモート デスクトップ」アプリは2025年5月27日にサポート終了し、「Windows App」へ統合されました。旧アプリからWindows 365やAzure Virtual Desktopといったクラウド側への接続は、2025年9月30日以降ブロックが始まっています。MSI版のリモートデスクトップクライアントも、商用クラウド向けサポートが2026年3月27日に終了しました（Azure Government／21Vianetは2026年9月28日まで）。
ただし、これらはクライアントアプリの話であって、サーバー側のRDSや標準の mstsc.exe（リモートデスクトップ接続）は影響を受けません。「リモートデスクトップが終わる」という見出しを見て慌てる必要はありません。オンプレのRDSサーバーにmstscで繋ぐ、という元記事そのままの構成は現役です。
もう一つ、ライセンス面で影響が大きいのがSPLAの変更です。2025年10月1日以降、SPLAではListed Provider（AWS・Azure・Google Cloud・Alibaba）上でRDSを提供できなくなりました。オンプレミスや非Listedのホスティング事業者は対象外です。
9. まとめ：2026年にワークグループとどう付き合うか
6年前の記事の答え合わせとしては、結論は当たっていたと言えます。ワークグループRDSはPer Device CALのみ、Per UserはAD必須。この一点は2019・2022・2025を通じて微動だにしていません。グループポリシーでライセンスモードを明示する回避策も、そのまま使えます。
一方で、当時は意識していなかった論点が浮かび上がりました。ワークグループという構成はNTLMという退場が決まったプロトコルの上に乗っている、ということです。今すぐ壊れるわけではありませんが、監査フェーズはすでに始まり、SMBの既定値は締め上げられ、2026年10月にはNTLMv1関連の既定値変更が予定されています。そして代替となるLocalKDC／IAKerbは、まだプレビューです。この「移行期の谷間」に今いる、という認識を持っておくことに意味があります。
実務的な優先順位としては、こう考えています。
- すぐやる：ローカル管理者パスワードのユニーク化と手動ローテーションの仕組み作り。LAPSが使えない以上、ここが最大の穴。あわせて署名非対応のNAS・機器の洗い出しと、正引き・逆引きDNSの整備（IP直指定はNTLMフォールバックを招きます）。
- 2025なら追加で：NTLM監査ログを有効にして依存箇所を可視化しておく。SMB NTLMブロックは例外リストを併用して段階導入。
- 更改のとき：2019・2022を飛ばして2025へ。RDS CALは2025版を別途手当て。2ノードのHA要件があるならワークグループHyper-Vクラスター＋ライブマイグレーションが選択肢に入る。
- 方針転換の判断ライン：Per Userが必要になった／RD Web Accessを使いたい／集中ID管理が要件化した／パスワード管理が回らなくなった。このいずれかに触れたら、ADドメイン化またはEntra参加へ舵を切るタイミングです。
RD Web Accessについて一点だけ補足しておくと、Per Deviceを選んだ環境でRD Web Accessを使うと、ポータルにアクセスしただけのデバイスにCALが消費されてしまいます。ワークグループ＝Per Device固定である以上、RD Web Accessを使いたい時点でADが実質必須になる、という連鎖になります。設計初期に確認しておきたいポイントです。
6年前は「60分で切断される」という目の前のエラーをどう消すか、という記事でした。今回調べ直してみて、同じ構成が今も動くという安心と、その足元が静かに入れ替わりつつあるという緊張の両方を感じました。次にこのテーマを書くとしたら、LocalKDCがGAして「ワークグループでもKerberosが当たり前」になった後になるのかもしれません。
0 件のコメント:
コメントを投稿