2025年12月14日日曜日
2025年12月7日日曜日
2025年9月5日金曜日
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、回復パスワードが表示されました。2025年9月2日火曜日
Windows Kerberosに対する脆弱性CVE-2025-26647の続報
複数フェーズからなるADの脆弱性対策「CVE-2025-26647 (Kerberos 認証) の保護」
という記事を書いていました。
先日続報がリリースされましたので、ご紹介します。
が日本マイクロソフトの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 イベントによる実影響がないとも記載ありました。
2025年7月21日月曜日
ADドメインコントローラーの降格失敗につき、メタデータクリーンアップせざるを得ない
オンプレミス側のActive Directoryドメインコントローラー(以降AD DC)を仮想マシンから物理マシンに入れ替えました。
※検証用途のサーバー2台を切り替えながら使うため、外出しのAD DCを用意することとしました。
何やら昇格の途中でエラーになったものの、Active Directory(以降AD)には昇格された状態となっておりました。エラー自体を看過できないので、一旦、物理マシンのAD DCを降格することとしました。
降格自体うまくいったかのように見えたのですが、なぜか物理マシンはワークグループになりました。ADドメインに再参加させようとすると、エラーです。
ADユーザーとコンピューターを開いてみると、Domain Controllersに降格したはずの物理マシンが存在しますね。これでは再参加できるわけ無いです。※タイムゾーンは、日本時間ではありません、念のため。
こうなるともうADでメタデータクリーンアップせざるを得ません。本ブログでは
Active Directoryからゾンビになったドメインコントローラを削除しよう Ver. 1.1Active Directoryからゾンビになったドメインコントローラを削除しよう Ver. 1.2
をまとめております。ですが、別件で試し結果、PowerShellよりntdsutilが最強と気づいたので、安納さん謹製の手順でメタデータクリーンアップを行いました。
【Windows Server】DC が死んだらグローバルカタログの移動も忘れずに
ADユーザーとコンピューター、ADサイトとサービス、DNSの順で、削除しきれていないものがないかを確認して、あれば削除を実施しました。
無事にADドメインへ再参加完了。AD DCへの昇格も完了。ADサイトとサービスにも接続オブジェクトができました。
この後Azure側のAD DC 2台をAzureサイトへ移動して構成変更完了しました。
2025年7月3日木曜日
Windows Server 2025 Active Directory環境下で、Windows 11 23H2がADドメインから外れてしまう事象
があると教えていただきました。
Windows Server 2025 Active Directoryにローリングアップグレード後、Windows 11 23H2がADドメインに参加していない状態となってしまいました。この際、上記の情報があると教えてもらった次第です。
ADドメインに参加しているコンピューターは、30日ごとにコンピューターアカウントのパスワードを更新する仕組みが既定で動きます。
Windows Server 2025 Active DirectoryとWindows 11 23H2の組み合わせだとこの辺りの動きがうまく無いようです。
を見ると、Windows 11 24H2にアップグレードするか、グループポリシーによりコンピューターアカウントのパスワードを更新する仕組みを停止する「DisablePasswordChange」がワークアラウンドになります。なおDisablePasswordChangeのレジストリ値は、How to disable automatic machine account password changesに記載ありました。
2025年6月30日月曜日
複数フェーズからなるADの脆弱性対策「CVE-2025-26647 (Kerberos 認証) の保護」
CVE-2025-26647 (Kerberos 認証) の保護
上記は、2025年4月8日に公開されました。
本文に記載ありますが、本脆弱性は、3フェーズでADの脆弱性の対策が図られます。上記の内容をサマリして以下に記載します。
- 脆弱性の概要:NTAuth ストアに存在しない認証局(CA)から発行された証明書を使って Kerberos 認証が行われると、セキュリティ上のリスクが生じる可能性があります。
- 影響対象:altSecID 属性を使った証明書マッピングを行っているセキュリティプリンシパル。またADドメインコントローラーがこちらの影響を受けます。
- 対策の段階的導入:
- 2025 年 4 月 8 日: 初期展開フェーズ – 監査モード
初期展開フェーズ(監査モード)として、NTAuth チェックと監査ログ警告イベント(イベントID 45)が有効になります。このイベントID 45は、安全でない証明書を使用して Kerberos 認証要求を受信すると記録されます。
この記録されたイベントを監視して、NTAuthストアに含まれていない影響を受ける証明機関を特定していくことも必要です。 - 2025 年 7 月: 既定で適用されるフェーズ
このフェーズ(モード)では、NTAuthストアのチェックが既定の動作となります。が、AllowNtAuthPolicyBypassレジストリキー設定を使用することで監査モードに戻すことも可能エス。
ただしこのモードでは、セキュリティ更新プログラムを完全に無効にする機能は削除されます - 2025 年 10 月: 強制モード
このモードになると、ADドメインコントローラーが安全でない証明書を使用してKerberos認証要求を受け取った場合、イベント D 21 がログに記録され、要求が拒否されます。
またAllowNtAuthPolicyBypassレジストリキーに対するMicrosoft のサポートは中止されます。よって監査モードに戻すことはできません。
Windows Server Summit 2025のオンデマンドビデオが公開されています。
2025年4月に開催されたWindows Server Summit 2025のオンデマンドビデオが公開されています。
Windows Server 2025だけではなく、AD、AD CS、WAC、Azure Arc、Azure File Syncなどのセッションがありますよ。
2025年2月2日日曜日
2025年2月11日は、「KB5014754: Windows ドメイン コントローラーでの証明書ベースの認証の変更」にご注意ください
を拝見していたら、
【AD】時間切れ目前!2025/2/11までに対策必須!ID39警告を無視するとヤバい理由【緊急対策】
がありました。こちら、実際の症状としてイベントID観点で解説されていますね。
実は、当方も同じような記事を書いていますw
※閲覧には、無料の会員登録が必要です。
です。この中で、「証明書認証に影響する脆弱性対策」を解説しており、2025年2月11日というのは「完全強制フェーズ」の更新プログラム(パッチ)がリリースされる日となっています。こちらの更新プログラムは、
KB5014754: Windows ドメイン コントローラーでの証明書ベースの認証の変更
にて情報提供されているものです。この脆弱性に関しては、2022年5月10日から4フェーズを経て完全強制になります。このフェーズを図示したものが下記となります。
ということで、複数フェーズによる脆弱性対策が必要になることから、定期的なパッチ適用が肝要ということです。2025年1月30日木曜日
ADデータベースのページサイズが32Kになっているか確認したい
の補足で、ADデータベースのページサイズが32Kになっているか確認する方法をまとめます。
上記資料では、
Active Directory ドメイン サービスで Database 32k ページのオプション機能を有効にする
に基づいてADデータベースのページサイズが32Kにできるところまで確認しました。
が、msDS-JetDBPageSize 属性だけ見ていても変更に気づけないかもと思いました。なので、msDS-JetDBPageSize 属性と併せて確認すると良い属性として、msDS-EnabledFeatureが妥当なのかや、別の方法でも確認可能なことをコミュニティメンバー(高井さん、ありがとうございます!)にアドバイスいただきました。
本稿では、msDS-JetDBPageSize 属性以外にに確認すると良い属性、それとはまた別の方法について、当方が確認した結果を記載します。
msDS-JetDBPageSize 属性と併せて、msDS-EnabledFeature属性も確認すると良い
Get-ADObject -LDAPFilter "(ObjectClass=nTDSDSA)" -SearchBase "CN=Configuration,DC=sshzk2016,DC=local" -properties msDS-JetDBPageSize | FL distinguishedName,msDs-JetDBPageSize
Get-ADObject -LDAPFilter "(ObjectClass=nTDSDSA)" -SearchBase "CN=Configuration,DC=sshzk2016,DC=local" -properties ,msDS-EnabledFeature | FL distinguishedName,msDS-EnabledFeature
msDS-EnabledFeature : {CN=Database 32k Pages Feature,CN=Optional Features,CN=Directory Service,CN=WindowsNT,CN=Services,CN=Configuration,DC=sshzk2016,DC=local, CN=Recycle Bin Feature,CN=OptionalFeatures,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=sshzk2016,DC=local}
属性の確認以外で確認する方法
IsDisableable : FalseName : Database 32k Pages Feature
2024年12月29日日曜日
2024年12月14日土曜日
2024年12月1日日曜日
Windows Server 2025 Active Directoryへのローリングアップグレード その1
手元の環境にあるWindows Server 2022 Active Directoryから、Windows Server 2025 Active Directoryへのローリングアップグレードを想定しています。
まずは下調べとして、関連ドキュメントのリストアップを行いました。
には、変更点が簡単にまとめられているので、日本語に訳して引用します。
Active Directory (AD): ID と認証のゴールド スタンダードは、新しいセキュリティ機能によってさらに向上し、スケーラビリティの向上、プロトコル、暗号化、強化、新しい暗号化サポートの改善により、進化する脅威に対して環境を強化できます。
Windows Server 2025 の新機能 -> [Active Directory ドメイン サービス]
には、変更点の詳細がまとめられています。こちらから更に、いくつかの情報を辿れます。
- Windows Server Active Directory スキーマの更新
こちらを確認すると、最終的にスキーマバージョンは91になりそうです。 - Windows Server の役割と機能のアップグレードと移行
からは
Active Directory Domain Services and DNS Server Migration Guide
があります。移行元となるバージョンが結構古いものの、移行のフローがあります。ただ、
Overview of the migration process for these roles
に書かれているフローは、ちょっとアレンジが必要かもしれません。
下記は、中級者向けにまとめられたラーニングパスです、アップグレード以外の情報もありますね。
Microsoft Applied Skills: Active Directory Domain Services を管理する
2024年10月11日金曜日
Kerberos認証についてのリンク集
Windows 2000 Server リソースキット 3 分散してステムガイド 上 があるとKerberos認証の詳細をおりに触れて振り返れます。でも最近は、なかなか見かけませんね。
概要の振り返りが可能な公式情報を探していたところ、下記を見つけたのでリンクを貼っておきます。
- Microsoft Kerberos
補足ですが、このツリーの並びにNTLMの公式情報もあります。 - Kerberos Authentication Overview
- Kerberos 認証のトラブルシューティング ガイダンス
Kerberos認証を用いた際のトラブルシューティング19件が、同じツリーレベルに載っています。
2024年8月30日金曜日
PowerShellモジュール AsHciADArtifactsPreCreationTool を手動インストールしてみた
Azure Stack HCI バージョン 23H2 デプロイ用に Active Directory を準備する
に基づいて進めるわけですが、前提条件の
Install-Module AsHciADArtifactsPreCreationTool -Repository PSGallery -Force
がうまくいかない事態が発生しました。PSGalleryへのリセットが何度リトライしても上手くいかないため、モジュールを手動インストールすることとなり。。。
AsHciADArtifactsPreCreationTool 10.2402
から、Manual Downloadをクリックし、「Download the raw nupkg file」をクリックしてnupkgファイルをダウンロードします。
パッケージの手動ダウンロード を見たところ、拡張子をzipに変更すると普通に解凍できました。_rels フォルダーにある.rels ファイルを見たところ、インストール時の依存関係は特にないようです。拡張子psd1とpsm1を"C:\Program Files\WindowsPowerShell\Modules\ashciadartifactsprecreationtool\10.2402.0"にコピーします。
Import-Moduleでインポートしましたが、バージョンが無いですね。手動インストールはこういうことが起きるのですね。
ADドメインコントローラー以外で、実行してみたところ下記のエラーを得ました。
AD用のPowerShellとグループポリシー管理ツールを追加すれば、問題無く実行できますね。2024年7月26日金曜日
Active DirectoryのKerberos認証に対する新たな3段適用更新プログラムがリリースされていました
CVE-2021-42287 で追加されたイベント メッセージ ID 35 , 37 と脆弱性対応の流れについて
で、Active DirectoryのKerberos認証に対する3段適用更新プログラムは、収束したと思っていました。ですが、教えていただいた話からKerberos認証に対する新たな3段適用更新プログラムがリリースされていました。それは、
KB5037754: CVE-2024-26248 および CVE-2024-29056 に関連する PAC 検証の変更を管理する方法
です。最大深刻度は重要なのですが、すべてのWindowsに適用が必要とのこと。つまりActive Directoryドメインコントローラー含むWindows ServerとWindowsクライアントが対象になります。
※もちろんサポートライフサイクルから外れているものは、もうどうしようもないと思いますい。拡張セキュリティ更新プログラム(ESU)が残っている場合は、その限りではないとも思います。
KB5037754: CVE-2024-26248 および CVE-2024-29056 に関連する PAC 検証の変更を管理する方法
は、今年の4月9日に最初のセキュリティ更新プログラムがリリースされました。このリリースでは互換モードです。上記リンクより文面引用します。
最初のデプロイ フェーズは、2024 年 4 月 9 日にリリースされた更新プログラムから始まります。 この更新プログラムは、CVE-2024-26248 および CVE-2024-29056 で 説明されている特権の脆弱性の昇格を防ぐ新しい動作を追加しますが、環境内の Windows ドメイン コントローラーと Windows クライアントの両方が更新されない限り、適用されません。
新しい動作を有効にし、脆弱性を軽減するには、Windows 環境全体 (ドメイン コントローラーとクライアントの両方を含む) が更新されていることを確認する必要があります。 監査イベントは、更新されていないデバイスを識別するためにログに記録されます。
2024年10月15日以降にリリースされるセキュリティ更新プログラムでは、強制モードすなわち、既定でセキュリティで保護された動作になるそうです。
最後に、2025年4月8日以降にリリースされるセキュリティ更新プログラムは、互換モードを一切サポートしません。
以上、パッチマネジメントは計画的に進める必要ありです。Active Directoryドメインコントローラーのローリングアップグレード時になって、慌てないようにしたいものです。。。
2024年6月15日土曜日
New-HciAdObjectsPreCreation は、PDCエミュレーターで実行したほうがよいのかも
Azure Stack HCIクラスターの命名順から、別のOUを指定して New-HciAdObjectsPreCreation しました。が、失敗。。。
※今回は、AzureへのAzure VPNセッションは接続済みであることを確認済みです。念のため。なぜこのようなことになるか。新しく作成したOUが、PDCエミュレーターに複製していないから。オンプレミスとAzureのADサイトは別々ゆえ、複製タイミングに合わないから、複製されていないわけです。
ただちにレプリケートして New-HciAdObjectsPreCreation を再実行したところ、問題なく成功。
OUを作成するADドメインコントローラー (AD DC)とPDCエミュレーターのADサイトが別々の場合、New-HciAdObjectsPreCreation はPDCエミュレーターで実行したほうがよいのかも。2024年6月12日水曜日
通信が不安定だったため、New-HciAdObjectsPreCreationの実行中に引かなくても良いトラブルを引いた
Azure Stack HCI OS 23H2のデプロイを進めています。
Prepare Active Directory for Azure Stack HCI, version 23H2 deployment
を実行していた時のこと。
※ユーザー名だけでよいのに、ドメイン名をつけてしまった失敗は、さておき。
コマンドレットの内容を見ていると、GPOの継承ブロックで失敗しているような。。。「指定されたドメインがないか、またはアクセスできません」とのこと。
OUとユーザーは、作成できていました。Prepare Active Directory for Azure Stack HCI, version 23H2 deployment に載っている別スクリプトも試しに実行してみましたが、当然うまくいかない。Copilotに上記画像のキーワードを与えて、いくつか当たってみました。下記に近いかなと。
Cannot disable group policy inheritance from domain
ということで、グループポリシーの管理コンソールを開こうとすると、接続不調によると思われるダイアログが表示されました。
続行してみたらダメ。何度かリトライしてもだめ。本環境のPDCエミュレータは、Azure上にあるので、Azure VPNの状態を見ます。案の定、未接続。。。
(固定IPアドレスではない故)ローカルゲートウェイのパラメーターを修正して再接続完了。New-HciAdObjectsPreCreationの実行がようやく成功。。。2024年5月3日金曜日
2024年4月のセキュリティ更新プログラムで、既知の問題が2つ出ています。
おもにWindows Server 2022に影響ありますが、
2024 年 4 月 9 日 — KB5036909 (OS ビルド 20348.2402)
で、下記の通り既知の問題が2つ出ています。文面を引用します。
- 2024 年 4 月のセキュリティ更新プログラムをインストールした後の NTLM トラフィックの問題
ドメイン コントローラー (DC) に 2024 年 4 月のセキュリティ更新プログラム (KB5036909) をインストールすると、 NTLM 認証トラフィックが大幅に増加する可能性があります。 この問題は、環境内のプライマリ ドメイン コントローラーの割合が非常に少なく、NTLM トラフィックが多い組織に影響を与える可能性があります。
次の手順: 解決に取り組んでおり、今後のリリースで更新プログラムを提供します。
影響を受けるプラットフォーム: - クライアント: なし
- サーバー: Windows Server 2022、Windows Server 2019、Windows Server 2016、Windows Server 2012 R2、Windows Server 2012、Windows Server 2008 R2、Windows Server 2008
- 2024 年 4 月のセキュリティ更新プログラムをインストールした後、VPN 接続が失敗する可能性があります
Windows デバイスは、2024 年 4 月のセキュリティ更新プログラム (KB5036909) または 2024 年 4 月のセキュリティ以外のプレビュー更新プログラム をインストールした後、VPN 接続エラーに直面する可能性があります。
次の手順: 解決に取り組んでおり、今後のリリースで更新プログラムを提供します。
影響を受けるプラットフォーム: - クライアント: Windows 11バージョン 23H2;Windows 11、バージョン 22H2、Windows 11、バージョン 21H2、Windows 10、バージョン 22H2、Windows 10、バージョン 21H2。
- サーバー: Windows Server 2022、Windows Server 2019、Windows Server 2016、Windows Server 2012 R2、Windows Server 2012、Windows Server 2008 R2、Windows Server 2008。
2024年4月21日日曜日
ADドメインに参加しているメンバーサーバーのホスト名が変更できません。
過日、タイトルに記載した事象に遭遇しました。
検索キーワードをいろいろ試していく中で、下記を見つけました。
Windows ベースのコンピューターをドメインに参加させるときに発生するエラーのトラブルシューティング方法
に、NetSetup.log をみると何かわかりそうです。所在は、%windir%\debug\Netsetup.log であることもわかりました。
実際に、内容を確認してみました。0x54fがエラーコードのようですね。
0x54fについて、調べてみたのですが、下記にあるような0x54bしか見つからない。。。ログをさかのぼって見ていて、下記に目が留まりました。
NetpChangeMachineName: generated netbion name
ということです。NetBIOS名だとすれば重複できないと判断しました。
結果、いろいろご協力をお願いした結果、サブドメインに同じNetBIOS名のコンピューターオブジェクトがあると判明。。。サブドメインのコンピューターオブジェクトを削除したところ、無事に ADドメインに参加しているメンバーサーバーのホスト名が変更できました。
- シングルドメイン環境では、ホスト名の重複は検出しやすいと思います。
- シングルフォレストのマルチドメイン環境では、NetBIOSホスト名という観点で、ホスト名重複とみなされると理解しました。これはグローバルカタログでの検出になります。よってトップドメイン、サブドメインのすべてでホスト名重複を調べる必要有りです。
ということで、シングルフォレストのマルチドメイン環境で、ホスト名重複にご注意ください。




































