Nested Hyper-Vを使う公式のAzure Local仮想マシンデプロイ手法を使ってみた

仮想 Azure ローカル システムをデプロイする

を見つけました。

こちらをベースにお手製のスクリプトを改良しました。加えて、再認識しましたが、ゲストOSのタイムゾーンはPST/PDTのままだなと（統合サービスとの時間同期を無効化、w32tmによるタイムサービスとの同期を行った上で、ゲストOSのクロックをPST/PDTに手動で合わせた）。

2508のデプロイにおいて、Extensionは、インストールされたものから触らない。下手に手動アップグレードすると、BasicのValidateに失敗するという気づきを得ました。

ということで、本稿作成時点でのExtensionsは、下記のままで進めました。

デプロイ前の最終的なValidateは、TrustedHostsの指定方法がよろしくないような。*だとダメなのかな。。。また調べ直さないと。

引き続き調べるとして、22H2依頼のデプロイを成功させたいものですね。

Active DirectoryでBitLocker回復パスワードを表示する

BitLocker回復パスワードをActive Directoryに保存できますね。Azure Localのノードで使われるBitLocker回復パスワードも同様に保存できます。

Azure Localのノードではないのですが、本稿ではWindows 11でBitLockerを有効化し、BitLocker回復パスワードをActive Directoryに保存した結果を閲覧してみます。

Windows 11でBitLockerを有効化

設定から、BitLockerドライブ暗号化を開きます。この例では、暗号化されていません。ここから暗号化を有効化します。

UACにて管理者権限を取得します。

回復キーはファイルに保存しました。

BitLockerをアクティブ化します。

有効化できました。

Active DirectoryドメインコントローラーにBitLocker回復パスワードビューアーをインストール

サーバーマネージャーから役割と機能の追加をクリックして、ウィザードを起動します。

「役割ベースまたは機能ベースのインストール」をクリックして、「次へ」をクリックします。

指定されたサーバーのまま、「次へ」をクリックします。

サーバーの役割はそのままにして、「次へ」をクリックします。

機能で、「リモートサーバー管理ツール」→「機能管理ツール」の順で展開します。

「BitLocker回復パスワードビューアー」をクリックして、「次へ」をクリックします。

「インストール」をクリックします。

しばらく待つとインストールが完了しました。

BitLocker回復パスワードをActive Directoryに保存

グループポリシーは未構成のまま試してみることとしました。

manage-bde.exeのオプションを確認します。

manage-bde.exe -statusで状態を見ておきます。

ファイルに保存した回復キーを確認しました。

リトライした結果、manage-bde.exeよりBitLocker回復パスワードをActive Directoryに保存しました。回復キーのIDは、そのまま指定できません。下図の通り、'{回復キーのID}'という形式で囲っておく必要がありました。

該当のコンピューターアカウントにて、BitLocker回復タブをクリックしたところ、回復キーのID、回復パスワードが表示されました。

Windows Kerberosに対する脆弱性CVE-2025-26647の続報

複数フェーズからなるADの脆弱性対策「CVE-2025-26647 (Kerberos 認証) の保護」 

という記事を書いていました。

先日続報がリリースされましたので、ご紹介します。

CVE-2025-26647 への対応とその影響について

が日本マイクロソフトのWindowsサポートチームよりリリースされています。この記事によると強制モードの開始日（更新プログラムのリリース日）が2025年10月14日で確定しています。

複数フェーズからなるADの脆弱性対策「CVE-2025-26647 (Kerberos 認証) の保護」 

に記載した通り、強制モードは下記のような状況になります。

このモードになると、ADドメインコントローラーが安全でない証明書を使用してKerberos認証要求を受け取った場合、イベント D 21 がログに記録され、要求が拒否されます。
またAllowNtAuthPolicyBypassレジストリキーに対するMicrosoft のサポートは中止されます。よって監査モードに戻すことはできません。

ということで、証明書認証をお使いの場合は、残り1か月で対応が必要になります。

CVE-2025-26647 (Kerberos 認証) の保護　はサポート情報でした。今回は日本マイクロソフトのWindowsサポートチームによる記事のため、すでにリリース済みの更新プログラムに対する不具合情報が記載されています。各々の不具合情報は、CVE-2025-26647 への対応とその影響について に詳細がございますのでご確認ください。下記では、その不具合情報が、すでに改善済みか否かを抜粋して記載いたします。

• 2025 年 4 月 8 日の更新プログラムに含まれている不具合は、2025 年 6 月 10 日の更新プログラムで改善済みとのこと。
• 2025 年 7 月 8 日の更新プログラムに含まれている不具合は、上記とは別とのことです。そのため、今後改善する見込みとのこと。
  ただし、6 月の更新プログラムを適用済みの状態で ID:45 が記録されていない状況であれば、ID:21 イベントによる実影響がないとも記載ありました。

Windows Server Pay as you goを解除

都合により、一度Windows Server Pay as you goを解除することにしました。

基本的に下記の逆回しだと思いますので、Azure Portalから操作してみました。

Configure Windows Server Pay-as-you-go with Azure Arc

Azure Arc対応サーバーとしていますので、ライセンスの従量課金画面を出します。

「Azureで従量課金」行のチェックを外し、確認をクリックします。

「非アクティブ化」をクリックします。

非アクティブ化が完了しました。がこの時点では、「Azureで従量課金」行のチェックはまだ入ったままの表示です。

一度概要画面に戻りました。赤枠の通り、非アクティブ化が完了しています。

ライセンスの画面も確認します。「Azureで従量課金」行のチェックは外れています。

これで大丈夫かと思います。

この後は、都合によりAzure Arc対応サーバーの関連付けも外しました。

Windows Server 2025 Active Directory環境下で、Windows 11 23H2がADドメインから外れてしまう事象

Server 2025 Domain Controllers - Trust relationship issues on workstations after 30 days as "pwdLastSet" value unable to be updated

があると教えていただきました。

Windows Server 2025 Active Directoryにローリングアップグレード後、Windows 11 23H2がADドメインに参加していない状態となってしまいました。この際、上記の情報があると教えてもらった次第です。

ADドメインに参加しているコンピューターは、30日ごとにコンピューターアカウントのパスワードを更新する仕組みが既定で動きます。

Windows Server 2025 Active DirectoryとWindows 11 23H2の組み合わせだとこの辺りの動きがうまく無いようです。

Server 2025 Domain Controllers - Trust relationship issues on workstations after 30 days as "pwdLastSet" value unable to be updated

を見ると、Windows 11 24H2にアップグレードするか、グループポリシーによりコンピューターアカウントのパスワードを更新する仕組みを停止する「DisablePasswordChange」がワークアラウンドになります。なおDisablePasswordChangeのレジストリ値は、How to disable automatic machine account password changesに記載ありました。

複数フェーズからなるADの脆弱性対策「CVE-2025-26647 (Kerberos 認証) の保護」

CVE-2025-26647 (Kerberos 認証) の保護

上記は、2025年4月8日に公開されました。

本文に記載ありますが、本脆弱性は、3フェーズでADの脆弱性の対策が図られます。上記の内容をサマリして以下に記載します。

• 脆弱性の概要：NTAuth ストアに存在しない認証局（CA）から発行された証明書を使って Kerberos 認証が行われると、セキュリティ上のリスクが生じる可能性があります。
• 影響対象：altSecID 属性を使った証明書マッピングを行っているセキュリティプリンシパル。またADドメインコントローラーがこちらの影響を受けます。
• 対策の段階的導入：

1. 2025 年 4 月 8 日: 初期展開フェーズ – 監査モード
   初期展開フェーズ（監査モード）として、NTAuth チェックと監査ログ警告イベント（イベントID 45）が有効になります。このイベントID 45は、安全でない証明書を使用して Kerberos 認証要求を受信すると記録されます。
   この記録されたイベントを監視して、NTAuthストアに含まれていない影響を受ける証明機関を特定していくことも必要です。
2. 2025 年 7 月: 既定で適用されるフェーズ
   このフェーズ（モード）では、NTAuthストアのチェックが既定の動作となります。が、AllowNtAuthPolicyBypassレジストリキー設定を使用することで監査モードに戻すことも可能エス。
   ただしこのモードでは、セキュリティ更新プログラムを完全に無効にする機能は削除されます
3. 2025 年 10 月: 強制モード
   このモードになると、ADドメインコントローラーが安全でない証明書を使用してKerberos認証要求を受け取った場合、イベント D 21 がログに記録され、要求が拒否されます。
   またAllowNtAuthPolicyBypassレジストリキーに対するMicrosoft のサポートは中止されます。よって監査モードに戻すことはできません。

Windows Server Summit 2025のオンデマンドビデオが公開されています。

2025年4月に開催されたWindows Server Summit 2025のオンデマンドビデオが公開されています。

Windows Server Summit 2025

Windows Server 2025だけではなく、AD、AD CS、WAC、Azure Arc、Azure File Syncなどのセッションがありますよ。

Windows Server 2025に含まれるwingetを使ってPowerShell 7をインストール

Windows Server 2025にPowerShell 7をインストールしたくて、調べました。結果、

WinGet (推奨) を使用して PowerShell をインストールする

を確認しました。MSIなどでインストールするのかと思いましたが、Windows Server 2025からwingetを使う方法がありました。wingetは、Windows 11や最新バージョンのWindows 10で使えるそうですね。

WinGet (推奨) を使用して PowerShell をインストールする

に沿って「winget search Microsoft.PowerShell」を使いPowerShellのパッケージを検索してみます。

WinGet (推奨) を使用して PowerShell をインストールするに記載通り、通常版とプレビュー版の両方が表示されましたね。

続いて「winget install --id Microsoft.PowerShell --source winget」を使いPowerShell 7.5.1をインストールします。

ちなみに、「winget help」を実行すれば、--proxyオプションを使えることがわかりますね。

Windows Server 2025 Pay-as-you-goとWAC in Azure その2

Windows Server 2025 Pay-as-you-goとWAC in Azure　その1では、Windows Server 2025 Pay-as-you-goの有効化しました。これによりWAC in Azureのライセンス要件を満足できました。本稿では、WAC in Azureの有効化を解説します。

まず拡張がないことを確認しておきます。

「Windows Admin Ceter (プレビュー)」をクリックして、「設定」をクリックして、セットアップを進めます。

拡張が入りつつあります。

拡張の作成が成功しました。

「Windows Admin Center管理者ログイン」のロールを権限割り当てしてください。（手順は省略します）

ロールの権限割り当てが完了するとメッセージが消えます。この状態で、「接続」クリックします。

WAC in Azureにて接続できました。

WAC in AzureゆえWAC機能拡張は、追加できません。が、サーバーマネージャーは一通り使えます。

以上、2回に分けて解説しました。ご参考になれば幸いです。

Windows Server 2025 Pay-as-you-goとWAC in Azure その1

Azure Arc対応サーバーにしたオンプレミス側のサーバーで、WAC in Azureを有効にすると警告メッセージが出るようになっています。

メッセージある通りSA権か従量課金制（Pay-as-you-go）が必要なので、Windows Server 2025 Pay-as-you-goを準備することとしました。

インストール時に下記をまず下記赤枠を選択してOSセットアップを完了させます。

OSセットアップが完了したら、Azure Arcに登録します。システムトレイのアイコンから進めるのがわかりやすいです。

Azure Arcの構成ウィザードが起動したら、次に進めます。

「Azureにサインイン」か「コードの生成」で認証します。

次の画面でEntra IDテナント（画面上は、Azure Active Directoryテナント）を選択するのですが、ここでエラー発生。。。

数回繰り返したのですが、ここでエラーになったまま。ということで数時間後に改めて再トライ。今度はうまくいきました。

次の画面で「従量課金制」をチェックして次に進めます。

登録が進行中です。

当方の環境では、上記から数分かからずに登録完了しました。

下図赤枠の通り、登録完了を確認できました。

ライセンスを確認したところ、従量課金制のアクティブ化が進行中でした。

待っている間に、OS側のライセンスを確認します。

OS側は認証されていました。

しばらく待つとAzure側の従量課金制もアクティベートが完了しました。

以上で、WAC in Azureを使うためのライセンス要件を満たすことができました。

次回は、WAC in Azureの有効化を見ていきます。その2につづく。