Microsoft Entra Kerberosの鍵ローテーションでは、切り替え直後に旧鍵で暗号化されたリファーラルチケットが残り、一時的に認証へ失敗することがありました。今回一般提供された改善では、受信側の信頼リファーラルをプライマリ鍵とセカンダリ鍵の両方で検証します。
これにより、鍵の伝播やチケット更新のタイミングが完全にはそろっていない時間帯でも、認証を継続できる可能性が高まります。ただし、メンテナンス計画や鍵バージョンの確認が不要になるわけではありません。運用担当者は、対応コマンドによるローテーション、Trusted Domain Objectの状態確認、実際の業務リソースを使った接続テストを引き続き実施する必要があります。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Entra Kerberosの二重鍵検証が一般提供
Microsoftは、Microsoft Entra Kerberosの鍵ローテーションについて、特に「incoming trust referral flows」、つまり受信側の信頼リファーラルを使用する環境での信頼性向上を一般提供しました。
従来は、リファーラルチケットがセカンダリ鍵で暗号化されていると、ローテーション中に認証へ失敗する場合がありました。改善後は、検証時にプライマリ鍵だけでなく、セカンダリ鍵でも復号を試みます。(Microsoft Learn)
| 項目 | 改善前 | 一般提供後 |
|---|---|---|
| 新しいチケットに使う鍵 | プライマリ鍵 | プライマリ鍵 |
| 既存チケットを保護する鍵 | セカンダリ鍵として保持 | セカンダリ鍵として保持 |
| 信頼リファーラルの検証 | セカンダリ鍵のチケットで失敗する場合があった | プライマリ鍵とセカンダリ鍵の両方で復号を試行 |
| 主な効果 | 鍵切り替え時に一時的な認証中断が起きる可能性 | 鍵ロールオーバー中の認証継続性を向上 |
| 管理者の作業 | 鍵ローテーションと動作確認 | 従来どおり鍵ローテーションと動作確認が必要 |
ここでいう「二重鍵検証」は、Microsoft Entra管理センターに新しい設定スイッチが追加されたという意味ではありません。公式情報では、鍵ローテーション時の検証ロジックを改善した変更として案内されており、専用の有効化操作や新しい管理コマンドは示されていません。
プライマリ鍵とセカンダリ鍵の役割
Microsoft Entra Kerberosでは、オンプレミスのActive Directory Domain ServicesとMicrosoft Entra IDの間で共有するKerberosサーバー鍵を使用します。この鍵は、Microsoft Entra IDが発行するTicket Granting Ticketを保護するためのものです。
鍵ローテーション時には、次のように2世代の鍵を保持します。(Microsoft Learn)
| 鍵 | 役割 |
|---|---|
| プライマリ鍵 | 新しく発行するKerberosチケットに使用する |
| セカンダリ鍵 | ローテーション前に発行された既存チケットを検証するために保持する |
ローテーションを行うと、新しく生成された鍵がプライマリ鍵になります。それまでのプライマリ鍵はセカンダリ鍵へ移動し、旧鍵で保護されたチケットが自然に期限切れになるまで検証に利用されます。
二重鍵検証は、2本の鍵を同時に使って新しいチケットを発行するアクティブ・アクティブ構成ではありません。新しいチケットはプライマリ鍵で発行し、セカンダリ鍵は切り替え前のチケットを受け入れるために使います。
なぜ鍵ローテーション中に認証失敗が起きていたのか
鍵ローテーションは、すべてのKDCやクライアント、キャッシュ済みチケットが一瞬で新しい状態へ切り替わる処理ではありません。
公式ドキュメントでは、ローテーション後の鍵がKerberos KDCサーバー間へ伝播するまでに数時間かかる場合があると説明されています。伝播中は、次の状態が一時的に混在します。(Microsoft Learn)
- 新しいプライマリ鍵で発行されたチケット
- 旧プライマリ鍵、つまり現在のセカンダリ鍵で保護されたチケット
- ローテーション前からクライアントにキャッシュされているチケット
- 伝播タイミングの違いによって旧鍵で処理された信頼リファーラル
従来の受信信頼リファーラルでは、このうちセカンダリ鍵で暗号化されたリファーラルチケットを正しく復号できない場合がありました。
改善後は、受信したリファーラルを検証するときに両方の鍵を利用できます。プライマリ鍵で扱えないチケットであっても、有効なセカンダリ鍵で保護されていれば認証を継続できます。
ローテーション中の動きを具体例で確認
次の時刻は動きを説明するための例です。
| 時刻 | 状態 |
|---|---|
| 2:00 | Kerberosサーバー鍵をローテーション |
| 2:05 | 新しい鍵がプライマリ鍵、直前の鍵がセカンダリ鍵になる |
| 2:20 | 一部のキャッシュや処理経路では、セカンダリ鍵で保護されたチケットが残っている |
| 2:30 | 受信信頼リファーラルをプライマリ鍵とセカンダリ鍵の両方で検証 |
| 数時間後 | KDC間への鍵伝播とチケット更新が進み、新しいプライマリ鍵へ収束する |
二重鍵検証によって改善されるのは、主にこの「新旧の鍵が正しく共存している移行期間」です。
受信信頼リファーラルとは
受信信頼、またはincoming trustとは、オンプレミスのAD DS側から見て、Microsoft Entra IDをKerberosの信頼先として扱う構成です。
Azure Filesのクラウド信頼構成では、オンプレミスAD DSがMicrosoft Entra IDをKerberos Key Distribution Centerとして信頼します。これにより、AD参加済みクライアントはMicrosoft Entra IDからKerberosチケットを取得し、Azureファイル共有などへアクセスできます。(Microsoft Learn)
代表的な構成は次のとおりです。
| 構成 | 主な用途 | 信頼オブジェクト |
|---|---|---|
| Azure Filesのクラウド信頼 | AD参加済み端末からSMBファイル共有へアクセス | Microsoft Entra Kerberos Trusted Domain Object |
| Azure SQL Managed Instanceのincoming trust-based flow | AD参加済み端末や既存アプリからWindows認証で接続 | Microsoft Entra Kerberos Trusted Domain Object |
| モダン対話型フロー | Microsoft Entra参加またはハイブリッド参加端末から接続 | SQL Managed Instanceの構成では顧客AD内の信頼オブジェクトを必要としない |
Azure SQL Managed Instanceでは、incoming trust-based flowはAD参加済みクライアント向けの認証方式です。オンプレミスADに信頼オブジェクトを作成し、Microsoft Entra IDへ登録したうえで、KDCプロキシをグループポリシーから構成します。(Microsoft Learn)
今回の改善で変わることと変わらないこと
改善が期待できるケース
次の条件に当てはまる障害は、二重鍵検証によって発生しにくくなります。
- 鍵ローテーションの直後だけ認証が不安定になる
- 同じユーザーでも成功と失敗が一時的に混在する
- 新しく取得したチケットでは成功するが、既存セッションでは失敗する
- 信頼リファーラルがセカンダリ鍵で暗号化された場合に失敗する
- 鍵の伝播が完了するまでの時間帯にだけエラーが発生する
改善後も別途対処が必要なケース
二重鍵検証は、すべてのMicrosoft Entra Kerberos障害を解決する機能ではありません。
| 症状・原因 | 確認すべき項目 |
|---|---|
| ローテーションとは無関係に常時失敗する | Trusted Domain Object、SPN、サービスプリンシパル、権限 |
| 一部の端末だけ失敗する | KDCプロキシGPO、端末の参加状態、ネットワーク、ポリシー適用 |
| オンプレミス側とクラウド側の鍵情報が異なる | KeyVersionとCloudKeyVersion、伝播状況 |
CloudTrustDisplayが空欄 | Trusted Domain Objectの作成・登録状態 |
| 古いチケットを使い続けて失敗する | チケットの有効期限、Kerberosキャッシュ |
| 特定のサービス名だけ失敗する | SPN、接続先FQDN、サービス側のMicrosoft Entra構成 |
| 手動で鍵や関連オブジェクトを変更した | 対応コマンドで構成を再確認し、必要に応じてMicrosoftサポートへ相談 |
特に重要なのは、今回の対象がMicrosoft Entra Kerberosのサーバー鍵である点です。Azure Storageのアクセスキー、アプリ登録のシークレット、証明書、通常のAD DS krbtgtアカウントとは別のライフサイクルとして扱う必要があります。
鍵ローテーション前に現在の状態を記録する
ローテーションを実行する前に、オンプレミス側とMicrosoft Entra側の鍵情報を記録します。
Microsoft Entra Kerberosの管理には、AzureADHybridAuthenticationManagement PowerShellモジュールを使用します。(Microsoft Learn)
$domain = "contoso.com"
$domainCred = Get-Credential
$cloudUserName = "[email protected]"
Get-AzureADKerberosServer `
-Domain $domain `
-DomainCredential $domainCred `
-UserPrincipalName $cloudUserName |
Select-Object DomainDnsName, KeyVersion, CloudKeyVersion, `
KeyUpdatedOn, CloudKeyUpdatedOn, CloudTrustDisplay主に確認する項目は次のとおりです。
| 項目 | 確認内容 |
|---|---|
DomainDnsName | 対象ドメインが正しいか |
KeyVersion | オンプレミスAD側の鍵バージョン |
CloudKeyVersion | Microsoft Entra側の鍵バージョン |
KeyUpdatedOn | オンプレミス側の最終更新日時 |
CloudKeyUpdatedOn | クラウド側の最終更新日時 |
CloudTrustDisplay | 受信信頼が正しく登録されているか |
incoming trust-based flowが正常に構成されている場合、公式手順の出力例ではCloudTrustDisplayに次の値が表示されます。(Microsoft Learn)
Microsoft.AzureAD.Kdc.Service.TrustDisplayローテーション前の時点でKeyVersionとCloudKeyVersionが一致していない場合は、すぐにローテーションを重ねるのではなく、既存構成や前回の伝播状況を先に確認してください。
認証中断を抑える鍵ローテーション手順
事前に実利用のテスト経路を決める
単にPowerShellコマンドが成功したかどうかだけでは、認証の継続性を確認できません。
事前に次のような実利用テストを決めておきます。
- Azure Filesを使用している場合は、SMB共有のマウント、読み取り、権限に応じた書き込み
- Azure SQL Managed Instanceの場合は、Windows認証による接続と影響のない参照クエリ
- サービスアカウントを使用するアプリでは、サービス起動と実際の接続処理
- 複数拠点がある場合は、主要拠点ごとの代表端末からの接続
- 古いセッションと新しいセッションの両方からの接続
特に、ローテーション前からチケットを保持しているテスト端末と、ローテーション後に新しくサインインする端末を分けると、セカンダリ鍵とプライマリ鍵の両経路を確認しやすくなります。
対応コマンドで鍵をローテーションする
incoming trust-based flowの公式手順では、次の形式で鍵をローテーションします。(Microsoft Learn)
Set-AzureADKerberosServer `
-Domain $domain `
-DomainCredential $domainCred `
-UserPrincipalName $cloudUserName `
-SetupCloudTrust `
-RotateServerKey利用しているモジュールのバージョンや構成によって、-CloudCredentialなど異なる認証パラメーターを使用する例もあります。実行時は、導入時に採用したシナリオの最新公式手順と、実際にインストールされているモジュールのパラメーターを確認してください。
Microsoftは、Microsoft Entra Kerberosサーバーの鍵を別のツールで変更せず、Set-AzureADKerberosServerを使用するよう案内しています。このコマンドにより、オンプレミスAD DSとMicrosoft Entra IDの両方へ鍵情報が更新されます。(Microsoft Learn)
伝播完了を待ってから再確認する
鍵ローテーション後は、すぐに全環境が同じ状態になるとは限りません。公式手順では、KDCサーバー間への伝播に数時間かかる場合があると説明されています。
そのため、次の順序で確認します。
- ローテーション直後にコマンドの成功を確認する
- テスト端末から既存セッションのアクセスを確認する
- 別端末または新しいセッションから新規認証を確認する
- 数時間後に鍵バージョンと更新日時を再確認する
- 業務時間帯を含めて認証エラーの増加がないか監視する
通常は、24時間以内に何度も鍵をローテーションしないでください。公式手順では、鍵配布のタイミングを考慮し、通常のローテーションは24時間以内に1回とされています。(Microsoft Learn)
ローテーション後の確認方法
鍵バージョンを再取得する
ローテーション後、同じコマンドを再実行します。
Get-AzureADKerberosServer `
-Domain $domain `
-DomainCredential $domainCred `
-UserPrincipalName $cloudUserName |
Select-Object DomainDnsName, KeyVersion, CloudKeyVersion, `
KeyUpdatedOn, CloudKeyUpdatedOn, CloudTrustDisplay確認のポイントは次のとおりです。
KeyVersionがローテーション前から更新されているCloudKeyVersionも更新されている- 伝播完了後に両方のバージョンが整合している
KeyUpdatedOnとCloudKeyUpdatedOnが想定した日時になっているCloudTrustDisplayが維持されている
直後に差が見つかった場合でも、伝播時間の範囲内であれば、まず時間を置いて再確認します。焦って連続ローテーションを行うと、障害原因の切り分けが難しくなります。
クライアントのKerberosチケットを確認する
Windowsでは、klistコマンドで現在キャッシュされているTGTやサービスチケットを確認できます。(Microsoft Learn)
klistTGTだけを確認する場合は、次のコマンドを実行します。
klist tgt確認する主な項目は、接続先サービス、チケットの有効期限、対象ドメイン、暗号化方式です。
ローテーション直後の確認では、最初からすべてのテスト端末でチケットを削除しないことが重要です。キャッシュをすべて削除すると、新しいプライマリ鍵で取得する経路しかテストできず、セカンダリ鍵で既存チケットを検証できるか確認できなくなるためです。
既存チケットを使ったテストが終わった後、管理されたテスト端末で新規取得を確認する場合は、必要に応じて次のコマンドを使用します。
klist purgeklist purgeはキャッシュ済みチケットを削除するため、リソースへ一時的に認証できなくなる可能性があります。業務中の利用者端末やサーバーで安易に実行せず、テスト端末に限定してください。
古い鍵を完全に廃止するには2回のローテーションが必要
1回目のローテーションでは、ローテーション前のプライマリ鍵がセカンダリ鍵として残ります。そのため、旧鍵を完全に廃止するには、既存チケットの有効期限と鍵の伝播を考慮したうえで、2回目のローテーションが必要です。
Microsoftも、元のプライマリ鍵とセカンダリ鍵を完全に廃止する場合は、古い鍵で保護されたチケットが期限切れになったことを確認してから、ローテーションを2回実施するよう案内しています。(Microsoft Learn)
ただし、次のような連続実行は避けてください。
1回目のローテーション
↓ 数分後
2回目のローテーション短時間で2回実行すると、セカンダリ鍵として保持すべき鍵まで早期に入れ替わり、まだ有効なチケットを検証できなくなる可能性があります。
2回目を実行する時期は、次の条件を満たしてから判断します。
- 組織で設定しているKerberosチケットの最大有効期間を経過している
- 鍵の伝播が完了している
- 旧セッションの利用が終了している
- 認証エラーが安定している
- オンプレミス側とクラウド側の鍵バージョンが整合している
-Forceは通常運用の高速化オプションではない
公式手順では、作成直後などの理由で24時間以内に再度ローテーションする必要がある場合、-Forceを付ける例が示されています。
Set-AzureADKerberosServer `
-Domain $domain `
-DomainCredential $domainCred `
-UserPrincipalName $cloudUserName `
-SetupCloudTrust `
-RotateServerKey `
-Forceただし、-Forceを付けてもKDC間の伝播が瞬時に完了するわけではありません。
-Forceは、通常の待機時間を無視して安全に連続ローテーションできることを保証するオプションではないため、障害対応で使用する場合も、現在の鍵バージョン、チケット有効期間、影響範囲を確認してから実行します。
運用で失敗しやすいポイント
AD側のアカウントを手動でリセットする
Microsoft Entra Kerberosでは、オンプレミスAD内にAzureADKerberosコンピューターオブジェクトや、関連するKerberosサービスアカウントが作成されます。
これらを通常のAD管理ツールから手動で変更すると、オンプレミス側とMicrosoft Entra側の鍵情報がずれる可能性があります。鍵ローテーションには必ず対応するSet-AzureADKerberosServerコマンドを使用します。
GAになったためメンテナンスが不要だと判断する
二重鍵検証は、正常なプライマリ鍵とセカンダリ鍵が存在する移行期間の耐障害性を高める改善です。
次の問題までは解消しません。
- Trusted Domain Objectの未作成
- 間違ったドメインやテナントへの登録
- KDCプロキシGPOの設定ミス
- SPNの不足や重複
- 必要権限の不足
- ネットワークや名前解決の問題
- オンプレミスとクラウドの鍵更新が途中で失敗した状態
したがって、一般提供後も計画停止時間または影響を監視できる変更時間帯を設定するのが安全です。
テスト前に全端末のチケットを削除する
全端末のキャッシュを消去してからテストすると、新しいプライマリ鍵による認証しか確認できません。
二重鍵検証の効果を確認するには、次の2種類を分けます。
| テスト | 確認できる内容 |
|---|---|
| ローテーション前からサインインしている端末 | 既存チケットやセカンダリ鍵の受け入れ |
| ローテーション後に新しくサインインした端末 | 新しいプライマリ鍵によるチケット発行 |
コマンド成功だけで作業を終了する
PowerShellコマンドが成功しても、業務アプリケーションの認証が成功するとは限りません。
最終判断は、Azure FilesのSMBアクセスやAzure SQL Managed InstanceのWindows認証など、実際の利用経路で行います。
ローテーション作業の実務チェックリスト
| タイミング | 確認項目 |
|---|---|
| 作業前 | 対象ドメイン、テナント、Trusted Domain Objectを確認 |
| 作業前 | KeyVersionとCloudKeyVersionを記録 |
| 作業前 | CloudTrustDisplayを確認 |
| 作業前 | 既存セッション用と新規セッション用のテスト端末を準備 |
| 作業前 | Azure FilesやSQL Managed Instanceなどの実利用テストを定義 |
| 作業中 | Set-AzureADKerberosServerでローテーション |
| 作業中 | AD管理ツールから関連アカウントを手動変更しない |
| 作業直後 | 既存セッションと新規セッションの両方で接続確認 |
| 作業後 | 数時間の伝播時間を考慮して鍵情報を再取得 |
| 作業後 | 認証エラー、接続失敗、問い合わせ件数を監視 |
| 次回作業 | 古い鍵の完全廃止が必要な場合のみ、期限経過後に2回目を計画 |
二重鍵検証に関するよくある疑問
一般提供後に管理者が設定を有効化する必要はある？
公式の一般提供情報では、二重鍵検証専用の設定スイッチや追加コマンドは案内されていません。受信信頼リファーラルを検証するMicrosoft Entra側のロジック改善として扱われています。
ただし、Trusted Domain ObjectやKDCプロキシGPOなど、既存のincoming trust-based flowの構成は引き続き必要です。
クライアントの更新は不要？
今回の変更だけを有効化するためのクライアント設定は案内されていません。一方、Microsoft Entra Kerberosや各ワークロードが定める対応OS、参加状態、更新プログラムなどの既存要件は引き続き満たす必要があります。
鍵ローテーションを営業時間中に行ってもよい？
二重鍵検証によって認証中断のリスクは下がりますが、ゼロになるわけではありません。初回実施や重要システムでは、影響を監視できる変更時間帯に実施するのが安全です。
Azure Storageのアクセスキーも二重鍵検証の対象？
対象ではありません。今回の改善はMicrosoft Entra Kerberosのサーバー鍵と信頼リファーラルの検証に関するものです。Azure Storageのkey1やkey2とは別の鍵です。
鍵ローテーション手順は変えず、検証範囲を広げる
Microsoft Entra Kerberosの二重鍵検証が一般提供されたことで、受信信頼リファーラルでは、セカンダリ鍵で保護されたチケットも検証できるようになりました。鍵ローテーション中に新旧のチケットが混在しても、認証を継続しやすくなる改善です。
一方、ローテーションコマンドや運用設計そのものが不要になったわけではありません。
まずGet-AzureADKerberosServerで現在の鍵バージョンと信頼状態を記録し、対応するSet-AzureADKerberosServerコマンドでローテーションします。その後は数時間の伝播時間を考慮し、既存セッションと新規セッションの両方から実際の業務リソースへ接続してください。
この順序を守ることで、一般提供された二重鍵検証の利点を生かしながら、鍵ローテーションによる認証中断を最小限に抑えられます。
コメント