ごきげんよう、IDチームのわかなです！
Okta と Entra ID を WS-Federation で連携している環境で、こんな疑問を持ったことはありませんか？
- Okta のパスワードは Entra ID に同期されないのに、Windows にパスワードでログインできるのはなぜ？
- Okta でパスワードを変更したら、PC のロック画面にはいつ反映される？
- 退職者のアカウントを無効化したら、すぐに PC にログインできなくなる？
実際にお客様からこの質問を受けて、最初は「キャッシュで検証してるだけでしょ」と思っていたのですが、調べてみたら全然違いました。Entra Joined 環境で実際の挙動を確認したので、その結果を共有します。
この記事で扱う構成
- Okta がソース（ユーザー管理）
- Okta → Entra ID に WS-Federation でフェデレーション
- 端末は Entra Joined（オンプレ AD なし）
- Okta のパスワードは Entra ID に同期しない（フェデレーションユーザーへのパスワードプロビジョニングはサポート外のため）
検証環境も Entra Joined 済みです。dsregcmd /status で確認すると AzureAdJoined: YES になっています。
初回セットアップ（OOBE）のログイン
新しい端末を Entra Join してセットアップするとき、認証は以下の流れです。
[ユーザー] → UPN入力 → [WAM] → [Entra ID] → フェデレーション検出
→ [Okta にリダイレクト]（WS-Fed パッシブ）
→ PW + MFA 入力 → トークン発行
→ [Entra ID] → PRT 発行 → Windows サインイン完了
→ キャッシュ資格情報がローカルに保存- Windows のログイン画面で UPN（メールアドレス）を入力
- WAM（Web Account Manager） がブラウザベースの認証を起動
- Entra ID がドメインのフェデレーション設定を検出
- Okta にリダイレクト（WS-Federation パッシブフロー）
- Okta の認証画面でパスワード + MFA を入力
- Okta が WS-Fed トークンを発行 → Entra ID に返却
- Entra ID がトークン検証 → PRT（Primary Refresh Token）発行
- Windows にサインイン完了、キャッシュ資格情報が保存される
ポイント:
- ブラウザが開いて Okta の認証画面が表示される（パッシブフロー）
- このとき入力した Okta のパスワードがキャッシュ資格情報としてローカルに保存 される
- オンライン接続が必須
セットアップ後のロック画面パスワード認証
OOBE 完了後のロック画面。ここからが本題です。
ロック解除でパスワードを入力したときの認証は OOBE とは別の仕組み です。ここが最初わからなくて混乱しました。
オンライン時：Cloud AP が Okta にリアルタイムで問い合わせる
[ユーザー] → PW入力 → [Cloud AP] → [Entra ID WS-Trust]
→ フェデレーション検出 → [Okta WS-Trust アクティブ]
→ Okta がPW検証（リアルタイム）
→ 成功: PRT 発行/更新 + キャッシュ更新
→ 失敗: FailedAuthentication → サインイン拒否- ロック画面でパスワードを入力
- Cloud AP プラグイン（Windows の認証モジュール）がパスワードを受け取る
- Cloud AP が Entra ID の WS-Trust エンドポイント にパスワードを送信
- Entra ID がフェデレーション設定を検出 → Okta の WS-Trust エンドポイントに転送
- Okta がパスワードを検証（リアルタイム）
- 成功 → Entra ID が PRT を発行/更新 → キャッシュ資格情報を更新
- 失敗 → Okta が
FailedAuthenticationを返す → サインイン拒否
ここが一番大事なところです。 ブラウザは開かれません。Cloud AP が裏で Entra ID 経由で Okta に直接通信しています。これを WS-Trust アクティブフロー と呼びます。OOBE の WS-Federation パッシブフロー（ブラウザリダイレクト）とは別物です。
「パスワードは常にキャッシュで検証される」と最初思い込んでいたのですが、オンライン時は毎回 Okta に問い合わせていました。つまり Okta でパスワードを変更したら、次のロック解除で即反映されるということです。
実際に Okta が WS-Trust アクティブエンドポイントを公開していることは、MEX（Metadata Exchange）レスポンスで確認できます。UserNameWSTrustBinding という名前のエンドポイントが、Cloud AP がパスワード検証に使うエンドポイントです。
検証環境から Entra ID（login.microsoftonline.com）と Okta の両方に 443 ポートで到達できることも確認しました。
実際の認証時には、Entra ID と Okta の両方にログが残ります。
Entra ID サインインログ では、アプリケーション「OfficeHome」へのサインインとして記録されます。これが Cloud AP 経由でパスワード認証が行われた証跡です。
Okta System Log では、「User single sign on to app」として Microsoft Office 365 への SSO イベントが SUCCESS で記録されます。Okta が実際にパスワードを検証し、トークンを発行したことがわかります。
オフライン時：キャッシュ資格情報にフォールバック
[ユーザー] → PW入力 → [Cloud AP] → Entra ID 接続失敗
→ ローカルキャッシュと照合
→ 一致: サインイン成功（PRT は更新されない）
→ 不一致: サインイン拒否- ロック画面でパスワードを入力
- Cloud AP が Entra ID への接続を試みる → 接続失敗
- ローカルのキャッシュ資格情報と照合
- 一致すればサインイン成功（PRT は更新されない）
Windows Firewall で 443 をブロックして、Entra ID にも Okta にも到達できない状態にすると、TcpTestSucceeded: False になります。この状態ではキャッシュ資格情報でしかログインできません。
ここが怖いところで、オフラインだとキャッシュに残っている旧パスワードでもログインできてしまいます。退職者対応を考えるとき、この挙動は無視できません（後述）。
パスワード変更したらどうなる？
Okta でパスワードを変更した場合の挙動です。
| 状態 | 旧パスワード | 新パスワード | 理由 |
|---|---|---|---|
| オンライン | NG | OK | Okta がリアルタイムで検証するため即反映 |
| オフライン（オンライン認証未実施） | OK | NG | キャッシュに旧パスワードしかない |
| オフライン（一度オンライン認証済み） | NG | OK | キャッシュが新パスワードで更新済み |
オンラインなら即反映、オフラインならキャッシュ更新まで旧パスワードが残る。
オンライン時は Okta がリアルタイム検証するので、パスワード変更が即座に反映されるのは安心です。ただしオフライン環境でしばらく使っているユーザーのキャッシュには旧パスワードが残る点に注意が必要です。
別のユーザーが同じ端末にサインインする場合
ロック画面で「他のユーザー」を選んだ場合は、OOBE と同じ WAM 経由の WS-Federation パッシブフロー になります。
- ブラウザが開いて Okta にリダイレクト → パスワード + MFA
- サインイン成功でユーザープロファイルが作成され、キャッシュ資格情報が保存される
- オンライン必須（キャッシュがないため）
初めてその端末を使うユーザーはキャッシュ資格情報が存在しないので、オフライン環境では初回サインインできません。
退職者をブロックするには
ここからは運用の話です。Entra ID でアカウントを無効化した場合、ロック画面からのサインインは即座にブロックされるでしょうか？
| 認証方式 | オンライン + 無効化 | オフライン + 無効化 |
|---|---|---|
| パスワード | ブロック | キャッシュで突破可能 |
| WHfB（PIN/顔認証） | 継続可能 | 継続可能 |
| Web サインイン | ブロック | ブロック |
パスワード認証はオフライン時にキャッシュで突破できてしまいます。WHfB はデバイスローカルで認証が完結するので、アカウント無効化が反映されません。
これ、けっこう怖くないですか？ 退職者が自宅で機内モードにして PC を開いたら、キャッシュで普通にログインできてしまうということです。
確実にブロックしたい場合は「Web サインイン」 が有効です。
Web サインインとは
ロック画面に埋め込みブラウザを表示し、毎回 Entra ID → Okta のオンライン認証を強制する機能です。キャッシュ資格情報を使わないため、アカウント無効化が即座に反映されます。
Intune での構成:
- 設定カタログ > 認証 > Web サインインを有効にする = 有効
- 設定カタログ > 認証 > 許可された URL で Web サインインを構成する = Okta テナント URL
Web サインインの注意点
ただし万能ではないです。導入前に以下を確認してください。
- Okta デバイストラスト（FastPass）との互換性: Web サインインは埋め込みブラウザ（WebView）で動作するため、Okta Verify との連携ができず、デバイストラストが動作しない可能性が高いです。デバイストラストを必須にしている認証ポリシーがある場合、Web サインインからログインできなくなります。回避策として、デバイス未登録状態からのアクセスにパスワード + OTP 等の代替手段を許可するルールの追加が考えられますが、セキュリティ要件とのトレードオフになります。（参考: Devices known issues | Okta）
- オフライン不可: ネットワーク障害時はサインインできません → LAPS でローカル管理者を確保が必須
- Entra Joined のみ対応: Hybrid Joined は非サポート
構成を考えるときに気にしたこと
- Web サインインを有効にすれば退職者ブロックは確実になる。ただし WHfB（PIN / 顔認証）との併用可否は環境依存のため、導入前に検証が必要
- WHfB のリカバリは2パターンある。MFA リセットで再登録できるケースと、TPM 上のコンテナ削除が必要なケース（ローカル管理者権限が必要）
- LAPS でローカル管理者を確保しておく。WHfB の TPM リセット時やオフライン時の緊急リカバリ手段として
まとめ
| シーン | 認証フロー | プロトコル |
|---|---|---|
| OOBE / 初回サインイン | WAM → Entra → Okta にリダイレクト | WS-Federation（パッシブ） |
| ロック解除（オンライン） | Cloud AP → Entra → Okta が検証 | WS-Trust（アクティブ） |
| ロック解除（オフライン） | キャッシュ資格情報 | ローカル検証 |
- Okta のパスワードは Entra に同期されないが、フェデレーション認証で Windows にログインできる
- ロック画面のパスワード認証は 「常にキャッシュ」ではない。オンライン時は Okta がリアルタイムで検証する
- パスワード変更はオンラインなら 即座に反映
- 退職者対応には Web サインイン（キャッシュ突破防止）+ LAPS（緊急リカバリ）
最初「キャッシュで検証してるだけでしょ」と思っていたのですが、調べてみたら Cloud AP → Entra → Okta の WS-Trust アクティブフローという仕組みがあって、オンライン時はリアルタイムで Okta に問い合わせていました。WS-Federation のパッシブフロー（ブラウザリダイレクト）しか知らなかったので、この発見はかなり勉強になりました。
この記事が、Okta × Entra ID 環境での Windows 端末運用でお困りの方の一助になれば幸いです！
