2026.09.14 17:47 (更新: 2026.09.14)

Okta の Office 365 プロビジョニング再認証、対象と手順をまとめました

クラウドセキュリティアーキテクト

はじめに

こんにちは！IdentityチームのKaitoです。

Okta の Office 365 アプリで User Sync / Universal Sync のプロビジョニングを使っている環境では、2026年9月30日までに管理者による再認証が必要です。期限を過ぎると、Office 365 への同期が止まります。この記事を書いている時点で期限まで3週間を切っているので、「うちの環境、対象だっけ？」という方はぜひこのまま読み進めてください！

何が変わるのか

Okta が Office 365 のユーザーを同期するとき、これまでは Microsoft Entra ID 側に用意した「サービスアカウント」の権限を借りて処理していました。今回、この方式が「アプリケーションベース認証（Application-Based Authentication、ABA）」に切り替わります。

ABA では、お客様の Entra ID テナントの中に Okta 専用のアプリ登録が作成されます（Entra ID の仕組み上、対応するサービスプリンシパルも作られます）。以後はそのアプリの権限でプロビジョニングが実行されます。Okta のサポート記事では、レガシーなサービスアカウント方式から、より安全な ABA 方式へ Okta が先回りしてアーキテクチャを近代化するものと説明されており、9月30日の期限は Microsoft 側の強制適用期限として案内されています。

対象になる環境

Okta のサポート記事によると、対象は次の条件を満たす環境です。

Okta の Office 365 または Office 365 GCC High アプリで、プロビジョニングを有効にしている
プロビジョニングの種類が User Sync または Universal Sync
Okta 側の連携方式が従来の MSOL ベースでも Microsoft Graph ベースでも対象
Okta Identity Engine と Classic Engine の両方が対象

補足ですが、Okta のサポート記事には「MSol も MS Graph も対象」と書かれています。ここでいう MSOL は、Okta の Office 365 連携が以前使っていた旧方式で、Microsoft が廃止した MSOnline PowerShell コマンドレットと Azure AD Graph に依存していたものです。Okta はこの旧方式を Microsoft Graph ベースに更新するよう 2024年末を期限に案内しており、Microsoft 側も MSOnline PowerShell を2025年4〜5月に、Azure AD Graph を2025年8月31日に完全廃止しています。したがって、現在動いている環境は基本的に Microsoft Graph ベースのはずです。Okta の記事が両方を列挙しているのは、連携方式を問わず対象であることを示すためと読むのが自然です。

一方で、SSO のみで使っていてプロビジョニングが無効な環境は対象外です。Profile Sync や「Licenses and Roles Management Only」だけを使っている環境も、今回の再認証の案内には含まれていません。また、2026年8月の月次リリース以降に新規作成した Office 365 アプリは、最初から ABA で構成されるため対応不要です。

確認方法

Okta Admin Console にサインインし、「Applications」＞「Applications」から Office 365 アプリを開く
「Provisioning」タブで API Integration が有効になっているか、プロビジョニングの種類が何かを確認する
User Sync または Universal Sync で、まだ再認証していなければ対象

Office 365 アプリを複数インスタンス運用している場合は、それぞれ確認が必要です。ここは見落としやすいポイントなので要注意です。

期限を過ぎると何が起きるか

2026年9月30日以降、再認証が済んでいない環境では User Sync / Universal Sync のプロビジョニングが停止します。公式には「プロビジョニングが停止する」とだけ書かれていますが、User Sync / Universal Sync が担っているユーザーの作成・更新・無効化が Entra ID 側に反映されなくなる、と理解しておくとよいと思います。

再認証の手順

事前に用意するものは2つです。

Okta 側：App Administrator 以上のロールを持つアカウント
Entra ID 側：MFA が有効なグローバル管理者（Global Administrator）アカウント（Okta のサポート記事の記載によります）

手順は次のとおりです。

Okta Admin Console の「Applications」から対象の Office 365 アプリを開く
「Provisioning」タブ＞左メニューの「Integration」を選び、「Edit」をクリック
「Re-authenticate with Microsoft Account」ボタンを押し、Entra ID のグローバル管理者でサインインして、要求される権限に同意する
「Save」で保存し、その後のプロビジョニングがエラーなく動いていることを確認する

実際の画面はこんな感じです。「Integration」を開くと、API が認証済みであっても「Re-authenticate with Microsoft Account」ボタンが表示されます。設定変更作業はここから開始できます。

Entra ID の同意画面

ボタンを押すと Entra ID のサインイン画面に飛び、サインイン後に「要求されているアクセス許可」という画面が出ます。ここで初見の方が戸惑うのが、太字で「このアプリケーションは、Microsoft またはお客様の組織によって公開されたものではありません」と表示される点です。

これは、同意先のアプリが Okta 社の提供するマルチテナントアプリ「Okta Microsoft Graph Client」だからです。Microsoft 製でも自社製でもない第三者のアプリに対して、Microsoft が機械的に出している注意書きであって、この文言だけで危険と判断する必要はありません。アプリ名が Okta の管理者同意ヘルプに記載されている「Okta Microsoft Graph Client」と一致していることを確認してください。

今回の再認証で新たに同意を求められる権限は2つです。Okta のサポート記事によると Application.ReadWrite.All と AppRoleAssignment.ReadWrite.All で、前者は Okta がテナント内にアプリを作成するため、後者はそのアプリへのロール割り当てのために使われます。権限名を見ると強そうに感じますが、Okta の記事では「プロビジョニング処理にのみ使用する」、管理者同意のヘルプページでは「User Sync と Universal Sync のプロビジョニングにのみ使用する」と説明されています。

ただし、同意画面の権限一覧には10項目以上が並びます（弊社の検証環境では11項目でした）。これは上の2つだけでなく、User Sync / Universal Sync が従来から使っている権限（ユーザー・グループ・組織情報の読み書きなど）を含めた、Okta Microsoft Graph Client 全体の権限セットが表示されるためです。一覧の中の「Read and write all applications」と「Manage app permission grants and app role assignments」が、上の Application.ReadWrite.All と AppRoleAssignment.ReadWrite.All に対応しています。同意する前に社内のセキュリティ担当と権限の意味を共有しておくと安心です。内容を確認したら「承諾」を押します。

承諾すると Okta の画面に戻ります。「Microsoft Office 365's API is authenticated」と表示されていることを確認し、「Save」を押して完了です。

注意点・つまずきやすいところ

Preview と Production の両方を持っている場合は、それぞれで再認証が必要です。 現在は Preview、Production のどちらも実施可能です。
再認証後に「The client secret for the ADSync app is invalid or has been removed. Please re-authenticate to remediate the provisioning.」というエラーが出ることがあります。この場合の対処として、Okta のサポート記事では、該当アプリのプロビジョニング設定で「Edit」＞「Save」を再度行うか、Tasks ページから該当のプッシュ処理をリトライするよう案内されています。
グローバル管理者アカウントの MFA が有効になっていないと再認証に進めません。普段 Okta 側で運用していると Entra ID 側の管理者アカウントを触る機会が少ないので、事前に確認しておきましょう。
手順の画面名や要求される権限は、今後のリリースで変わる可能性があります。実施前に Okta の公式ドキュメントで最新の記載を確認してください。

さいごに

「期限が決まっている作業」は、後回しにするほど選択肢が減っていきます。作業自体は Okta と Entra ID の管理者権限がそろっていれば、私の感覚では短時間で終わる内容なので、まだの方は9月中の早いタイミングで実施することをおすすめします。

私自身、まだ Okta と Entra ID の連携を勉強中の身ですが、こうした「仕組みが変わる瞬間」は両方の理解を深めるちょうどいい機会だと感じています。ここまで読んでくださってありがとうございました！

参考リンク

※本記事は2026年9月時点の公開情報に基づいています。Okta 社・Microsoft 社の仕様変更により、記載内容が変わる場合があります。

タグ

Kaito Yanagihara