【よくあるお問い合わせ】Windows × Okta × Office 365 の認証キャッシュ問題

ごきげんよう、IDチームのわかなです！

本記事は、Okta を IdP として Office 365 を利用しており、Entra Join（旧 Azure AD Join）環境の Windows 端末を管理している IT 管理者を対象としています。

「ユーザーが何もしていないのに、Oktaアカウントが定期的にロックされる」
このような状況に遭遇したことはないでしょうか。

本記事では、Entra Join 環境で Okta を IdP として Office 365 を利用している組織で発生しうる、認証キャッシュ起因のロックアウト問題について、背景知識から対処法まで解説します。

事象の概要

症状

• ユーザーがパスワードを間違えていないのに、Oktaアカウントがロックアウトされる
• スリープ復帰後やPC放置後に発覚することが多い
• ロック解除しても数日〜数週間で再発する
• ユーザー本人はブラウザでのサインインやOkta Verifyでの認証に問題がない

影響を受ける環境

• Windows 10/11 端末が Entra Join されている
• Okta が IdP として Office 365 に SSO を提供している（WS-Federation 連携）
• ユーザーが Outlook / Teams / OneDrive などの Office リッチクライアントを利用している

背景知識：Windows の認証キャッシュの仕組み

本事象の理解には、Windows の認証の仕組みを知っておくと原因の切り分けがスムーズになります。

Kerberos 認証とは

Kerberos は、チケットと呼ばれる暗号化された認証トークンを使って、パスワードをネットワーク上に流さずに認証を行うプロトコルです。Active Directory 環境では標準の認証方式として使われています。

認証フローの概要

1. ユーザーが Windows にサインイン（パスワード or Windows Hello）
2. KDC（Key Distribution Center）に認証リクエスト
3. KDC が TGT（Ticket Granting Ticket）を発行
4. TGT を使ってサービスチケットを取得
5. サービスチケットで対象サーバにアクセス

重要なのは、パスワードは最初の①でしか使わないという点です。以降はチケットだけでやりとりします。

TGT さえ持っていれば、新しいサービスにアクセスするたびにパスワード入力は不要です。これが SSO の基本的な仕組みです。

ただし、Entra Join 環境ではオンプレ AD のドメインに参加していないため、従来の Kerberos チケットは使われません。klist を実行しても「キャッシュされたチケット: (0)」となり、klist purge も効果がありません。

PRT と WAM

Entra Join 環境では、オンプレ Kerberos の代わりに以下の仕組みが使われます。

PRT（Primary Refresh Token） は、いわば Entra ID 版の TGT です。

WAM（Web Account Manager） は、Office リッチクライアントのトークン管理を担う OS コンポーネントです。

Outlook が Exchange Online にアクセスしたい
  → WAM に「トークンちょうだい」
  → WAM が PRT で Entra ID からアクセストークンを取得
  → Outlook がアクセストークンで Exchange Online にアクセス

WAM の認証優先順位

PRT の更新時、WAM は以下の優先順位で認証を試みます。

1. Windows Hello の鍵（Public Key Credential）
2. PRT のリフレッシュトークン
3. パスワード由来の鍵 / 平文パスワード

Windows Hello が無効で PRT 更新にも失敗すると、キャッシュされた平文パスワードでフォールバック認証が行われます。このパスワードが古い場合に、問題が発生します。

klist cloud_debug コマンドで、この状態を確認できます。

• Public Key Credential Present: 0：Windows Hello の鍵がない
• Password-derived Keys Present: 1：パスワード由来の鍵あり
• Plaintext Password Present: 1：平文パスワードがキャッシュされている

Plaintext Password Present: 1 かつ Public Key Credential Present: 0 の組み合わせが、この問題が発生しやすい状態です。

Okta で何が起きているのか

背景知識を踏まえて、Okta 側で実際に何が起きているのかを見ていきます。

Okta システムログに現れる共通パターン

この事象が発生しているユーザーのシステムログを確認すると、ロックアウト前に以下の特徴を持つ INVALID_CREDENTIALS イベントが累積しています。

ログを読むときのポイント：

1. User-Agent が Windows-AzureAD-Authentication-Provider/1.0
   • ブラウザではなく、Windows OS のバックグラウンドプロセスからのリクエストです。ユーザーが手動で何かしたわけではありません。

   

2. リクエスト先が WS-Federation エンドポイント
   • /app/office365/.../sso/wsfed は、Modern Auth（OAuth 2.0）ではなくレガシー認証経路です。

   

3. 1〜2時間間隔で深夜にも発生
   • ユーザーが操作していない時間帯にも発生しているため、バックグラウンドのトークン更新処理であることが分かります。

全体像

ここまでの内容を整理すると、以下のような流れになります。

[Windows端末]
  └─ WAM / TokenBroker
       └─ Azure AD Authentication Provider
            └─ Office 365 WS-Fed SSO (Okta経由)
                 └─ キャッシュされた古いパスワードで認証試行
                      └─ INVALID_CREDENTIALS × n回
                           └─ Okta ロックアウト閾値に到達

WAM が TokenBroker キャッシュに保存された古いパスワードを使って Okta に認証を繰り返し、閾値に達してロックアウトに至ります。

なぜ古いパスワードが残るのか

厄介なのは、この問題の発生トリガーが複数あることです。

確認手順

①Okta システムログの確認

まずは Okta 側で原因の切り分けを行います。以下のフィルタで該当ユーザーのログを確認してみてください。

• outcome.reason = INVALID_CREDENTIALS
• client.user_agent に Windows-AzureAD-Authentication-Provider を含む
• request_uri に /sso/wsfed を含む

上記すべてに該当すれば、WAM 経由のレガシー認証が原因の可能性が高いです。

②端末側の診断

次に、対象端末で管理者権限の PowerShell から以下を実行します。

dsregcmd /status        # Entra 参加状態・PRT の有無
klist cloud_debug       # WAM 層の状態（平文パスワードキャッシュの有無）

③イベントビューアーの確認

ロックアウト発生時刻の前後で、以下のログにトークン更新失敗のエラーがないか確認します。

アプリケーションとサービスログ > Microsoft > Windows > AAD > Operational

対処法

各ステップで1週間程度の経過観察を行い、改善しなければ次へ進みます。

①WAM / TokenBroker キャッシュの削除

資格情報マネージャーからは見えない WAM 層のキャッシュを直接削除します。

# Office アプリをすべて終了してから実行
Remove-Item "$env:LOCALAPPDATA\\Microsoft\\TokenBroker\\Cache\\*" -Force
Remove-Item "$env:LOCALAPPDATA\\Microsoft\\OneAuth\\*" -Force -Recurse
# → PC再起動 → Office で Okta 経由の再サインイン

注意：キャッシュ削除後は、Outlook / Teams / OneDrive 等すべての Microsoft 365 アプリで再サインインが求められます。 ユーザーに事前に伝えたうえで実施してください。

②Office の完全サインアウト + 資格情報クリア

# 資格情報マネージャーから Office 関連エントリを削除
cmdkey /list | Select-String "MicrosoftOffice" | ForEach-Object {
    $target = ($_ -split ":")[1].Trim()
    cmdkey /delete:$target
}
# → Office アプリでサインアウト → 再起動 → 再サインイン

③Entra Join の再実行

キャッシュ削除で改善しない場合、PRT やデバイス登録を含めてリセットします。

注意：Entra Join の再実行は影響範囲が大きいため、慎重に実施してください。

• 離脱中は Entra ID の条件付きアクセスポリシーでデバイス準拠を要求している場合、すべてのクラウドリソースへのアクセスがブロックされます
• BitLocker 回復キーが Entra ID に保存されている場合、離脱前に必ず手元に控えてください（離脱するとデバイスから回復キーにアクセスできなくなる可能性があります）
• Intune 管理下のデバイスでは、離脱により MDM 登録も解除される場合があります。再参加後に MDM の再登録・コンプライアンスポリシーの再評価が必要です
• 再参加完了まで30分〜1時間かかり、その間 Office アプリや社内リソースが一時利用不可になります

必ず業務時間外に、IT部門の管理下で実施してください。

dsregcmd /leave
# → 再起動 → 設定 > アカウント > 職場または学校にアクセス > 接続

④PC 交換

上記すべてで改善しない場合、端末の初期化または交換を検討します。本事象は PC 交換で確実に解消した実績があります。

再発防止策

レガシー認証のブロックは Entra ID でも Okta でも基本

Entra ID の条件付きアクセスでは、レガシー認証のブロックは基本方針の1つです。IMAP / POP3 / SMTP / Exchange ActiveSync といった古いプロトコルは MFA をバイパスできてしまうため、条件付きアクセスポリシーでブロックすることが推奨されています。

今回の問題の根底にあるのも同じ話です。WS-Federation はレガシー認証経路であり、パスワードベースの認証が行われるため、WAM のキャッシュ不整合の影響をまともに受けます。

Okta 側でも同様に、Office 365 アプリの WS-Federation を無効化し Modern Authentication（OAuth 2.0 / OIDC）のみに制限することで、パスワードベースのレガシー認証経路を塞ぐことができます。

ただし、WS-Fed を無効化すると一部の古い Office クライアントや連携アプリに影響が出る可能性があるため、事前に影響範囲を確認してください。Entra ID 側で先にレガシー認証をブロックしている環境であれば、Okta 側も合わせて無効化するのが自然な流れとなります。

Okta 側での WS-Fed 無効化手順

1. Okta 管理画面 → Applications → Microsoft Office 365
2. Sign On タブ → Sign On Methods
3. WS-Federation の「Active」と「Passive」を無効化
4. Modern Authentication（OAuth 2.0 / OIDC）のみ有効にする

まとめ

• Okta のログだけ見ると「パスワード間違い」にしか見えないが、User-Agent と request_uri を確認すればバックグラウンドプロセス起因かどうか判断できる
• 原因は Windows の WAM / TokenBroker キャッシュに古いパスワードが残り続けること
• 根本的な再発防止には Windows Hello の有効化が最も効果的

ID管理は IdP の設定だけで完結するものではなく、端末側の認証キャッシュの挙動までセットで考える必要があります。そして、Entra ID で当たり前に行っているレガシー認証のブロックは、Okta 側でも同様に検討すべきです。Okta と Windows、両方の視点を持つことで、このような「見えにくい問題」にも対処できるようになります。

この記事が、同様の事象でお困りの方の一助になれば幸いです！

参考リンク

• Okta Users Getting Locked Out with Multiple Failed Login Attempts via a Rich Client
• プライマリ更新トークン (PRT) について
• Windows デバイスでのプライマリ更新トークンの問題のトラブルシューティング
• Windows Server 上の AD FS でのアカウント ロックアウトのトラブルシューティング