Azure AD ConnectでAzureADKerberosが見つからない時のkrbtgt_AzureADキーローテーション手順

Azure AD Connect 環境で Cloud Kerberos trust（クラウド Kerberos トラスト）を使う場合、Active Directory 側に作成される krbtgt_AzureAD のキーローテーション（鍵更新）は重要です。しかし「AzureADKerberos モジュールが見つからない」「psd1 がない／読み込めない」などで手が止まりがち。本記事では PHS（パスワードハッシュ同期）を維持したまま、モジュール準備から安全なキー更新までを手順付きで解説します。

症状：AzureADKerberos が見つからず krbtgt_AzureAD をローテーションできない

Cloud Kerberos trust（クラウド Kerberos トラスト）や Microsoft Entra Kerberos（旧 Azure AD Kerberos）を運用していると、監査やセキュリティ基準に合わせて krbtgt_AzureAD のキーローテーションを実施したくなる場面があります。ところが、いざ手順を進めようとすると Azure AD Connect（Microsoft Entra Connect）サーバー上で AzureADKerberos モジュール／フォルダーが見当たらない、あるいは AzureADKerberos.psd1 はあるが Import-Module に失敗する、といった理由で作業が進まないことがあります。

よくある状況	発生しやすい原因	最短の解決ルート
AzureADKerberos フォルダー自体が見つからない	探している場所が違う／製品バージョンや構成差／必要コンポーネント未展開	PowerShell Gallery 版 AzureADHybridAuthenticationManagement を導入して実行環境を整える
AzureADKerberos.psd1 はあるが Import-Module で DLL 参照エラー	Azure AD Connect をカスタムパスにインストールしたため psd1 が既定パス前提で DLL を参照	psd1 内の DLL パス（4か所）を実インストール先に修正して Import-Module
キー更新はしたいが PHS サインインへの影響が不安	krbtgt_AzureAD の役割と影響範囲が見えにくい	「何が影響し、何が影響しないか」を切り分けて、検証→本番の順で実施

前提整理：Cloud Kerberos trust と krbtgt_AzureAD の関係

Cloud Kerberos trust を有効化すると、オンプレ AD DS 側には AzureADKerberos というコンピューターオブジェクトが作成されます。このオブジェクトは読み取り専用ドメインコントローラー（RODC）のように見えるものの、実体としての物理サーバーに紐づくわけではなく、Microsoft Entra ID がオンプレ AD の TGT を発行するための「論理的な KDC 連携点」として利用されます。

同時に、AD の Users コンテナーには CN=krbtgt_AzureAD という 無効化されたユーザーアカウント が作られ、これが Microsoft Entra Kerberos サーバーの TGT 暗号化キーを保持します。つまり krbtgt_AzureAD のキーローテーション＝Entra Kerberos の TGT キー更新です。

重要なのは、既存の PHS（パスワードハッシュ同期）によるクラウドサインイン方式と、Cloud Kerberos trust（オンプレ資源への Kerberos SSO）は役割が異なる点です。krbtgt_AzureAD の更新は「オンプレ AD と Entra ID の間で Kerberos のチケット交換を成立させる」ための鍵更新であり、PHS でのパスワード照合そのものを作り替える作業ではありません。Microsoft も、キーローテーションは定期的に行うべきで、かつ 必ず指定のツール（コマンド）で実施して両側に反映させるよう明記しています。

作業前チェック：失敗しやすいポイントを先に潰す

キーローテーションはコマンド一発で終わるように見えて、実際には「実行環境」「権限」「AD 側の状態」でつまずきがちです。まずは次のチェックを満たしているか確認しましょう。

チェック項目	確認方法（例）	目安
DC の要件	OS バージョンとパッチ、Kerberos 暗号設定	Windows Server 2016 以降（必要な更新適用）、AES256 が許可
必要権限	ドメイン側：Domain Admins +（フォレストなら）Enterprise Admins クラウド側：Hybrid Identity Administrator	Set-AzureADKerberosServer 実行に必要
実行端末	Microsoft Entra Connect（Azure AD Connect）サーバー、または依存 DLL がある端末	「どこでも良い」わけではない
AD レプリケーション	repadmin /replsummary、イベントログ、サイト間遅延	大きな遅延や失敗がない
メンテナンス計画	影響範囲（WHfB / FIDO2 / Azure Files 等）とロールバック手順の用意	テスト→本番の順で段階適用

原因の切り分け：AzureADKerberos が「ない」ように見える代表パターン

探している場所が違う（フォルダー名が環境で揺れる）

Azure AD Connect のインストール先やバージョンにより、Program Files 配下のフォルダー名が揺れることがあります。まずは「決め打ち」ではなく、psd1 ファイル名で横断検索するのが確実です。

PowerShell（管理者）
# 代表的な psd1 を横断検索（時間がかかる場合があります）
Get-ChildItem -Path "C:\Program Files" -Filter "AzureAdKerberos.psd1" -Recurse -ErrorAction SilentlyContinue

# PowerShell モジュールとして見えるか確認
Get-Module -ListAvailable | Where-Object { $_.Name -match "AzureAD.*Kerberos|HybridAuthentication" }

上記で見つかったパスが「思っていた場所と違う」だけ、というケースは多いです。特に C:\Program Files\Microsoft Azure AD Sync\ 配下に DLL 依存が置かれる前提があるため、インストール方法によっては相対参照が崩れます。

カスタムインストールパスにより psd1 の DLL 参照が壊れている

Azure AD Connect セットアップで「カスタムインストール先」を選ぶと、ウィザードが移動するのは一部フォルダー（例：Microsoft Azure AD Sync フォルダー）だけで、AzureADKerberos.psd1 は既定パスを前提に DLL を参照することがあります。その結果、フォルダー自体はあっても Import-Module で失敗し、「モジュールが存在しない」ように見えます。

そもそも関連コンポーネントが展開されていない／手順が古い

近年は、Cloud Kerberos trust や FIDO2 のオンプレ SSO の管理は PowerShell Gallery から配布される AzureADHybridAuthenticationManagement モジュールを使うのが公式手順です。従来の「Azure AD Connect 配下のフォルダーを直接 Import-Module」だけに頼ると、環境差で詰まることがあります。

推奨手順：AzureADHybridAuthenticationManagement を使ってキーローテーションする

「モジュールが見つからない」問題を最短で回避しつつ、Microsoft の推奨どおりに krbtgt_AzureAD を更新するなら、AzureADHybridAuthenticationManagement を導入して Set-AzureADKerberosServer -RotateServerKey を実行する流れが堅実です。別ツールで krbtgt_AzureAD を更新すると、オンプレ AD と Entra ID の両方に整合した形で反映できない可能性があるため注意してください。

モジュールのインストール

PowerShell（管理者）
# PowerShell Gallery への接続のため TLS 1.2 を有効化
[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12

# モジュールをインストール

Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

# 念のため読み込み

Import-Module AzureADHybridAuthenticationManagement

このモジュール自体は「DC に到達できる任意の端末」に入れられますが、Kerberos Server オブジェクトの作成は Microsoft Entra Connect サーバー、または Microsoft.Online.PasswordSynchronization.Rpc.dll 依存が入ったサーバーで行う必要があります。実務的には「Azure AD Connect サーバー上で実行」が最も事故が少ない選択です。

Microsoft Entra Kerberos オブジェクトの作成（未作成の場合）

まだ Cloud Kerberos trust を「これから有効化する」段階なら、まずは Kerberos Server オブジェクトを作成して Entra ID に公開します。すでに作成済みの場合は次の「状態確認」に進んでください。

PowerShell（管理者）
# 対象のオンプレ AD ドメイン（例：contoso.com）
$domain = $env:USERDNSDOMAIN

# クラウド側：Hybrid Identity Administrator の資格情報
$cloudCred = Get-Credential -Message 'Microsoft Entra ID の Hybrid Identity Administrator の資格情報を入力'

# ドメイン側：Domain Admins（フォレスト環境なら Enterprise Admins を含む）資格情報
$domainCred = Get-Credential -Message 'Active Directory の Domain Admin（必要に応じて Enterprise Admin）資格情報を入力'

# Kerberos Server オブジェクトを作成し、Entra ID に公開
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred

状態確認（作成済みか／キーの整合性）

作成・更新の前後で必ず Get-AzureADKerberosServer を実行し、オンプレ側とクラウド側の KeyVersion と CloudKeyVersion が一致していること、KeyUpdatedOn が想定どおり更新されていることを確認します。

PowerShell（管理者）
$domain = $env:USERDNSDOMAIN
$userPrincipalName = "[email protected]"

Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential (Get-Credential)

なお、ドメイン資格情報を domain\username 形式で渡すと NTLM 経由になり失敗するケースがあるため、UPN 形式を使う注意点が公式ドキュメントで補足されています。

krbtgt_AzureAD（Entra Kerberos サーバーキー）のローテーション

準備ができたら、次のコマンドで Entra Kerberos サーバーのキー（krbtgt_AzureAD）をローテーションします。ローテーションは定期的に行い、オンプレ AD の krbtgt と同様の運用サイクルに合わせる考え方が推奨されています。

PowerShell（管理者）
$domain = $env:USERDNSDOMAIN

# 事前に取得した資格情報を使う場合
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred -RotateServerKey

実行後はもう一度 Get-AzureADKerberosServer を実行し、KeyVersion/CloudKeyVersion が更新され、かつ両者が一致していることを確認してください。ここが一致していないと、Cloud Kerberos trust のチケット交換で不整合が起きるリスクが高まります。

補足：Azure AD Connect 配下の AzureADKerberos.psd1 を使う場合の注意点

組織の手順書が「Azure AD Connect のインストールフォルダー配下にある AzureADKerberos.psd1 を Import-Module する」前提になっている場合もあります。その場合は次のポイントを押さえると詰まりにくくなります。

代表的な配置場所（例）

場所の例	補足
C:\Program Files\Microsoft Azure AD Sync\	DLL 依存がここにある前提で psd1 が書かれていることがある
C:\Program Files\Microsoft Azure Active Directory Connect\AzureADKerberos\	AzureAdKerberos.psd1 の配置例として言及されることがある
C:\Program Files\Microsoft Azure AD Connect\AzureADKerberos\	バージョンやインストール形態によりフォルダー名が異なる場合がある

カスタムインストール時の psd1 修正ポイント

Azure AD Connect を既定以外のドライブ／フォルダーへ入れている場合、AzureADKerberos.psd1 内の DLL 参照が C:\Program Files\Microsoft Azure AD Sync 前提のままになっていることがあります。この場合は、psd1 内で参照されている 4 つの DLL パスを、実際のインストール先に合わせて書き換える必要があります（編集前に psd1 のバックアップを推奨）。

PowerShell（管理者）
# 例：psd1 の場所が分かっている場合はフルパスで Import
Import-Module "D:\Apps\AADConnect\AzureADKerberos\AzureADKerberos.psd1"

Import-Module が通ったら、その後のキーローテーションは公式ドキュメントのとおり Set-AzureADKerberosServer -RotateServerKey で実施してください。別の方法で krbtgt_AzureAD を更新すると、オンプレ AD と Entra ID の両方へ整合性を保って反映できない可能性があります。

psd1 がどこにも無い場合にやるべきこと

AzureADKerberos.psd1 が見つからない場合でも、すぐに詰みではありません。現実的には次のどれかで解消できることが多いです。

PowerShell Gallery 版（AzureADHybridAuthenticationManagement）に切り替える：公式手順に寄せることで、フォルダー探索問題を回避できます。
実行サーバーが正しいか見直す：Microsoft Entra Connect の稼働サーバー（アクティブ／ステージング）を取り違えていないか確認します。
Microsoft Entra Connect のアップグレード／修復を検討する：古い構成や欠落コンポーネントが原因の場合、ウィザードの「変更／修復」で関連ファイルが揃うことがあります（事前に設定とバックアップを確保）。

特に「PHS のまま維持したい」という要件がある場合、Entra Connect の再構成は 認証方式（PHS/ PTA/ フェデレーション）を変えないこと、同期対象 OU やフィルターを現行どおり引き継ぐことがポイントです。作業前に設定を記録し、可能であればステージングサーバーや検証テナントで手順を再現してから本番に入るのが安全です。

PHS サインインへの影響を最小化する考え方

krbtgt_AzureAD のローテーションは「Cloud Kerberos trust のための Kerberos キー更新」です。PHS は「クラウドでパスワードハッシュを照合する」方式なので、原理的に別レイヤーの話になります。ただし、次のような利用形態がある場合は、キーローテーション後にオンプレ資源アクセスのテストを行うべきです。

影響が出る可能性がある領域	代表例	確認ポイント
Cloud Kerberos trust のオンプレ SSO	Windows Hello for Business（クラウド Kerberos トラスト）、FIDO2 でのオンプレアクセス	キー更新後も Kerberos 交換が成立するか
Entra Kerberos を使うクラウド側ワークロード	Azure Files など（構成により）	アクセスが継続できるか（条件付きアクセスの影響も含む）
AD レプリケーション依存	サイト間遅延が大きい環境	KeyVersion の不一致が起きていないか

運用のコツ：ローテーションを「一回で終わらせない」ために

ローテーション周期は「オンプレ krbtgt の運用サイクル」に合わせる：Microsoft は krbtgt_AzureAD も含め、定期的にローテーションし、既存の krbtgt 運用と同じスケジュールに揃える考え方を示しています。
作業記録を残す：実施日、実行者、対象ドメイン、KeyVersion/KeyUpdatedOn、実施後の簡易テスト結果（オンプレ共有へのアクセスなど）を残すと監査対応が楽になります。
レプリケーションが遅い環境は時間を味方につける：更新直後に「一部 DC だけ古い状態」が起きると切り分けが難しくなります。repadmin で状況を見ながら段階的に確認します。
特権アカウントは安易に対象にしない：AzureADKerberos オブジェクトは RODC と同様の制約があり、特権組み込みグループに直接／間接で所属するユーザーは Cloud Kerberos trust を利用できない旨が案内されています。設計上、特権アカウントの利用は別経路で担保します。

トラブルシューティング（よくあるエラーと対処）

症状／メッセージ例	原因の当たり	対処の方向性
Import-Module で DLL を読み込めない	カスタムインストールで psd1 の参照先が既定パス前提	psd1 内の DLL パスを実インストール先に修正／公式の Gallery 版へ切替
Failed to read secrets from the domain	実行端末が不適切／権限不足／AD への接続・認証方式の問題	Entra Connect サーバーで実行、UPN 形式の資格情報、ネットワークと Kerberos を確認
Get-AzureADKerberosServer で KeyVersion と CloudKeyVersion が一致しない	更新反映が片側に寄っている／レプリケーション遅延	時間を置いて再確認、repadmin で健全性確認、必要なら再度 Set-AzureADKerberosServer を実行
domain\username 形式だと失敗する	NTLM で接続され失敗しやすい	ドメイン管理者資格情報は UPN 形式で入力する

最後に：最短で安全に進めるための実務フロー

作業を「迷子」にしないため、実務フローとしては次の順が安定します。

Entra Connect サーバー（または依存 DLL を満たす端末）を確定する
AzureADHybridAuthenticationManagement を導入し、Get-AzureADKerberosServer で現状を可視化する
未作成なら Set-AzureADKerberosServer でオブジェクトを作成し、作成済みならそのまま -RotateServerKey を実行する
KeyVersion/CloudKeyVersion の一致と、オンプレ資源アクセスの簡易テストで完了判定する
次回に備えて、実施記録と手順書を更新する

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure AD ConnectでAzureADKerberosが見つからない時のkrbtgt_AzureADキーローテーション手順

症状：AzureADKerberos が見つからず krbtgt_AzureAD をローテーションできない

前提整理：Cloud Kerberos trust と krbtgt_AzureAD の関係

作業前チェック：失敗しやすいポイントを先に潰す

原因の切り分け：AzureADKerberos が「ない」ように見える代表パターン

探している場所が違う（フォルダー名が環境で揺れる）

カスタムインストールパスにより psd1 の DLL 参照が壊れている

そもそも関連コンポーネントが展開されていない／手順が古い

推奨手順：AzureADHybridAuthenticationManagement を使ってキーローテーションする

モジュールのインストール

Microsoft Entra Kerberos オブジェクトの作成（未作成の場合）

状態確認（作成済みか／キーの整合性）

krbtgt_AzureAD（Entra Kerberos サーバーキー）のローテーション

補足：Azure AD Connect 配下の AzureADKerberos.psd1 を使う場合の注意点

代表的な配置場所（例）

カスタムインストール時の psd1 修正ポイント

psd1 がどこにも無い場合にやるべきこと

PHS サインインへの影響を最小化する考え方

運用のコツ：ローテーションを「一回で終わらせない」ために

トラブルシューティング（よくあるエラーと対処）

最後に：最短で安全に進めるための実務フロー

この記事を書いた人

コメント

コメントするコメントをキャンセル

Azure AD ConnectでAzureADKerberosが見つからない時のkrbtgt_AzureADキー ローテーション手順

症状：AzureADKerberos が見つからず krbtgt_AzureAD をローテーションできない

前提整理：Cloud Kerberos trust と krbtgt_AzureAD の関係

作業前チェック：失敗しやすいポイントを先に潰す

原因の切り分け：AzureADKerberos が「ない」ように見える代表パターン

探している場所が違う（フォルダー名が環境で揺れる）

カスタム インストール パスにより psd1 の DLL 参照が壊れている

そもそも関連コンポーネントが展開されていない／手順が古い

推奨手順：AzureADHybridAuthenticationManagement を使ってキー ローテーションする

モジュールのインストール

Microsoft Entra Kerberos オブジェクトの作成（未作成の場合）

状態確認（作成済みか／キーの整合性）

krbtgt_AzureAD（Entra Kerberos サーバー キー）のローテーション

補足：Azure AD Connect 配下の AzureADKerberos.psd1 を使う場合の注意点

代表的な配置場所（例）

カスタム インストール時の psd1 修正ポイント

psd1 がどこにも無い場合にやるべきこと

PHS サインインへの影響を最小化する考え方

運用のコツ：ローテーションを「一回で終わらせない」ために

トラブルシューティング（よくあるエラーと対処）

最後に：最短で安全に進めるための実務フロー

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

Azure AD ConnectでAzureADKerberosが見つからない時のkrbtgt_AzureADキーローテーション手順

カスタムインストールパスにより psd1 の DLL 参照が壊れている

推奨手順：AzureADHybridAuthenticationManagement を使ってキーローテーションする

krbtgt_AzureAD（Entra Kerberos サーバーキー）のローテーション

カスタムインストール時の psd1 修正ポイント

コメントするコメントをキャンセル