1.はじめに

本記事は、OktaをIdP、Microsoft365の認証(Entra IDによる認証)をSPにした場合の記事です。

Microsoft 365は、Entra IDをデフォルトのIDaaS (Identity as a Service）としていますが、他のIDaaSに設定して利用することも可能です。フェデレーションと呼ばれる設定となり、Entra IDによる認証の際に、他のIDaaSにリダイレクトされ、認証OKの場合は、再度リダイレクトされて、リソースにアクセスできます。

ちなみに、前回の記事では、過去Microsoft 365の認証をフェデレーションする場合において、最有力の候補であったADFSに関して、記載しました。こちらもご参考まで。

とはいえ、Entra IDを除いた場合は、ADFSを利用するよりも他のIDaaSを利用すること方が主流となります。
Oktaは、人気のあるIDaaSですので、今回ピックアップし、設定手順をご説明します。
なお、OktaはIdentity Engine(新しい基盤、旧基盤はClassic Engine)を利用しています。

また、Oktaの環境準備に関しては、以下記事をご覧くださいませ。

2.WS-Fedarationとは

今回、Microsoft 365のフェデレーションを構成する前に、WS-Fedarationに触れておきます。

WS-Fedarationとは、IBMやMicrosoft社によって開発されたクレームベースの認証方式となります。現在は、SAMLやOpenID Connectといった認証方式を利用される方が多いですが、Microsoft 365のフェデレーションのためには、WS-Fedarationを利用する必要があります。

SAMLプロトコルに似ており、ユーザーID を検証した後、IdP側は、Request Security Token Response （RSTR）を返します。このRSTR の中には、SAML アサーションが含まれます。

WS-Federationの詳細は、Microsoftの公式サイトに記載がありますので、下記よりご確認いただけます。

3.設定手順

3-1.プライマリドメインの設定

フェデレーションの設定をするためには、XXX.onmicrosoft.comをプライマリのドメインにする必要があります。
「Entra 管理センター > 設定 > ドメイン名」から、プライマリドメインをXXX.onmicrosoft.comに変更しましょう。すでに変更済みであれば作業不要です。
なお、プライマリドメインに設定していると、新しいユーザーを作成したときに、そのユーザーの既定のドメイン名にプライマリドメインが設定されたりします。

もし、カスタムドメインを追加していないようであれば、以下記事をご覧くださいませ。

3-2.OktaへのOffice 365の登録

Oktaの管理ポータルに移動します。「Applications > Applications」を選択し、「Browse App Catalog」をクリックします。

カタログから「Office」と検索して、「Microsoft Office 365」を選択します。

「Add Integration」をクリックします。
なお、画像キャプチャを添付しますが、連携時に利用可能な機能もこちらで確認することができます。

個人的に重要と感じるのが、Provisioningのところです。
これは、SCIM（System for Cross-domain Identity Management）やAPIによるユーザプロビジョニングのことを示しています。SSOはできるが、ユーザプロビジョニングはできないSaaSもあったりするので、事前に確認しておく必要があります。

設定画面に入っていきます。
General Settingのところでは、Microsoft側のドメイン情報を入力します。
上部の「Microsoft Tenant Name」に関しては、[固有].onmicrosoft.comにおける[固有]の部分を入力し、「Your Office 365 company domain」に関しては、今回利用したい（OktaをIdPとして利用したい）ドメイン情報を入力します。

Sign-On methodsに関しては、「WS-Federation」を選択します。

次に、「I want to configure WS-Federation myself using PowerShell」にチェックをいれます。
「View Setup Instructions」をクリックすると、新しくタブが開きます。

新しく開いたページには、powershellコマンドが表示されます。表示されたコマンドは、実際にテナント単位の情報を反映しているため、コマンドを実行するだけで、WS-Federation完了です。

ポイント：Microsoft Graph API
2023年6月ごろに、Azure AD Graph や MSOnline Powershell モジュールは廃止になっています。
OktaのHelpページは、すでにコマンド反映済みでしたが、情報媒体によっては古いことがあるので注意をする必要があります。

https://jpazureid.github.io/blog/azure-active-directory/how-to-determine-depreacated-azuread-msol/

例えば、コマンド体系が変わっており、Get-MsolUserやGet-AzureADUserコマンドが、Get-MgUser コマンドに変更になっています。

もし、Graph PowerShell SDKをインストールしていなければ、以下URLを確認して入れる必要があります。
例えば、以下コマンドをPowerShellで実行することで、インストールできます。

Install-Module Microsoft.Graph

https://learn.microsoft.com/ja-jp/powershell/microsoftgraph/installation?view=graph-powershell-1.0

コマンドを投入した際の画面は以下の通りとなります。
各コマンド実行後に、ブラウザにリダイレクトされて、認証が発生しています。

なお、ここで実行しているコマンドは、New-MgDomainFederationConfiguration で、新しいフェデレーションドメインを作成することが可能となっています。
以下はサンプルコマンドと公式のコマンドリファレンスです。


New-MgDomainFederationConfiguration `
  -DomainId example.com `
  -DisplayName example.com `
  -IssuerUri https://[***] `
  -PreferredAuthenticationProtocol "wsFed" `
  -ActiveSignInUri https://dev-[***].okta.com/app/office365/[***]/sso/wsfed/active `
  -PassiveSignInUri https://dev-[***].okta.com/app/office365/[***]/sso/wsfed/passive `
  -MetadataExchangeUri https://dev-[***].okta.com/app/office365/[***]/sso/wsfed/mex `
  -SigningCertificate [***] `
  -SignOutUri https://dev-[***].okta.com/app/office365/[***]/sso/wsfed/signout `
  -FederatedIdpMfaBehavior [***]

コマンド補足
今回実行したコマンドは、Oktaのヘルプページの情報に、以下コマンドを加えて、Microsoft Graphから明示的に切断しています。
下記コマンドを実施しない場合は、資格情報が保持され、再アクセスがスムーズになりますが、すぐ再アクセスをしないなら、明示的に切断しておいた方がよいと思います。（個人的な意見です）

Disconnect-MgGraph

Entra 管理センターに移動し、「設定 > ドメイン名」からカスタムドメイン名を確認します。
すると、今回対象としたドメインのフェデレーションが有効になっていることが確認できました。

フェデレーションは、ドメイン単位の設定可能です。
あるドメインAは、ADFSによってフェデレーションさせて、あるドメインBは、Oktaでフェデレーションさせて、あるドメインCは、Entra IDでそのまま認証・認可させることができたりします。

4.ユーザのプロビジョニング

4-1.注意点

フェデレーションの設定をしている場合、Entra IDでは、フェデレーション対象ドメインを利用して、新規ユーザを作ることができません。

NG例：Entra IDで直接　[username]@[フェデレーションのドメイン] を作成
OK例：Entra IDで直接　[username]@[マネージドドメイン] を作成
OK例：Oktaでユーザを作り、Entra IDにユーザ同期

Entra IDで直接、[username]@[フェデレーションのドメイン] を作成しようとすると、以下のようにエラーが出力されます。

4-2.Oktaを利用したIDプロビの設定

上記注意点がありますので、ユーザの作成は、Oktaを利用する必要があります。なお、Active DirectoryからEntara Connectを利用してもEntra IDにユーザを作成することは可能な模様です。

「Applications」から、M365を選択し、「Sign On」に移動します。

「Advanced API Access」の「Allow administrator to consent for Advanced API access」にチェックを入れます。その後、Authenticate with Microsoft Office 365をクリックします。

認証フォームがポップアップし、要求されるアクセスの許可を「承諾」すると完了となります。

「Provisioning」に移り、「Configure API Integration」をクリックします。

「Enable API integration」にチェックを入れます。

グローバル管理者権限を持つユーザを入力します。（自動で入力される場合もあります）
入力したら、「Test API Credentials」をクリックします。

問題なければ、Microsoft Office 365 was verified successfully!　と表示されますので、「SAVE」をクリックします。

To App , To Oktaというサイドメニューが表示されるようになりました。

必要なIDプロビの作業に関して、「Enable」にチェックを入れて、「Save」を押して完了です。

4-3.IDプロビのためのユーザ割り当て（手動）

Oktaの管理ポータルで、「Directory > People」に移動します。
「Add person」よりユーザを作成していきます。

ドメイン名のところは、フェデレーションの設定をしたドメインにして、ユーザを作成します。
入力できましたら、「Save」を押します。

作成したユーザをクリックします。「Applications > Assign Applications」を選択します。

そして、先ほど設定した「Microsoft Office 365」を選択します。

アサイン時には、ライセンスやロールもセットで付与することが可能です。

Immutable ID
アプリの登録時に、Immutable IDの設定も可能となっています。
任意で設定しない場合は、Entra ID側にランダムな値が自動で割り当てられます。
加えて、一度設定したImmutable IDは上書きすることができないので注意する必要があります。

以下画像のように、ユーザーにアプリを割り当てることができました。

4-4. 動作確認

それでは作成したユーザで、動作確認を行います。
Entra IDの認証が発生する何らかのサイトにアクセスします。

ユーザ情報を入力するとOktaの認証フォームにリダイレクトされました。次へをクリックし、パスワードを入力すると、無事Microsoft側のサービスにログインすることができました。

加えて、Oktaの「Reports > System Log」に、フェデレーションでの認証ログが残っていることが確認できました。

5.おわりに

これでOktaをIdPにしたM365のフェデレーションは一応完了です。
ただ実運用上だと、大量にあるライセンスやロールの割り当てなどを手動で実施するのは、大変です。
そのため、Okta Workflowを利用したりするなど、工夫が必要かもしれませんね。