はじめに こんにちはこんばんは、WS-Federationをこよなく愛するネクストモードのおはらふです
はじめに
こんにちは、 ネクストモード株式会社のサイドウです。
Microsoft365をOktaに認証委任する場合、Lifecycle Management（LCM）ライセンスが無いと幾つか無視できない課題が発生します。
Oktaでは、LCMライセンスを契約することで、Microsoft365等のSP側のアカウント管理を一元化することが可能です。
しかし、Microsoft365の認証だけOktaに統合したい！！LCMを契約するほど利用SaaS数が多くない！！、、、あると思います。
本ブログでは、LCMライセンスが無い場合の、Okta-Microsoft365の連携およびノンストレスな運用をOkta Workflowsを利用して実現します。
環境
以下の環境におけるOkta-Microsoft365の連携が本ブログの対象となります。
・Oktaの契約ライセンス
SSOとUDが利用できる環境（Workflowsは5フローまで無償利用可）。LCMもしくは機能を包含する上位ライセンスは未契約。
・Microsoft365アカウント
クラウド専用ユーザーを使用 ※ADやIDPからの同期ではなく、クラウド上で作成したユーザー
本ブログのゴール
本ブログでは、Okta Workflowsを利用して図のような環境をセットアップします。
このフローにより、以降解説する課題が解決されてノンストレスな環境ができると思います！
フェデレーションの手順については、様々なドキュメントやブログで公開されておりますので割愛します。※公式ドキュメント：https://help.okta.com/ja-jp/content/topics/apps/office365-deployment/configure-sso.htm
フェデレーションが完了すると、EntraID-[カスタムドメイン]のページで以下の通り、特定ドメインのフェデレーションにチェックマークが表示されます。
Okta（LCM無し）とM365を連携すると、どんな課題が発生するのか
①Microsoft365の新規ユーザーがGUI上で作成できない
一つ目の課題が最も大きな課題です。フェデレーション設定後、EntraIDのGUI上で新規ユーザーを作成すると以下のエラーメッセージが表示され、ユーザー作成ができません。
【原因】
フェデレーションされたドメイン内のユーザーを作成する場合「immutable ID（オンプレミスの不変ID）」という属性値が必須属性となります。この属性値がGUI上で設定できないため、GUI上でのクラウド専用ユーザー作成が不可になる仕様です。
【immutable IDとは】
オンプレミスのAvtive DirectoryやIDP等のアカウントをEntraIDにプロビジョニングした際に発行される一意の値です。
フェデレーション設定されたドメインの場合、EntraIDのアカウントとフェデレーション先（今回であればOktaアカウント）を紐づける値として使用されるため、アカウント作成時の必須属性となります。
【回避策】
１．Microsoft Graph APIを使用して、Powershell等からコマンド実行によりimmutableIDを付与したアカウントを作成する
キャプチャように、APIで新規ユーザーを作成する場合は、immutableIDを指定できるためユーザー作成が可能となります。
２．アカウント作成の度に、フェデレーション設定を解除する。（作成後に結局コマンドでimmutableIDを設定する必要有）
３．Okta Lifecycle Managementを契約して、OktaアカウントをMicrosoft365にプロビジョニングする
②連携アプリケーションへの割当作業をユーザー毎に実施する必要がある
①の課題を許容し、毎度コマンドでユーザーを作成する運用にしたとしても、まだ面倒な作業が残っています。
まずは、アプリケーションへのユーザー割り当ての画面キャプチャを見ていただきましょう。
ユーザー名には「Microsoft365アカウントのUPN」、不変IDには「immutableID」をユーザー毎に設定する必要があります。
ユーザー毎に値が変わるはずなので、もちろん「グループで一括登録」みたいな効率的な事はできません。
一人二人なら良いですが、2~30人のユーザーを一気にやるとなると想像するだけで面倒ですよね。（画面を行ったり来たり、、ミスも発生しそうです）
Okta Workflowsで解決しよう！！
・フローの概要
冒頭お伝えした通りキャプチャのフローを作成します。あくまでブログ用のシンプルなフローですので、実際に導入される際はエラー処理を入れることを強くお勧めします。（Microsoft365上に既にユーザーが存在する場合、既にアプリケーションに割り当てられている場合等）
また、フローはいくらでも修正できますので、例えば「ライセンス付与まで自動化」や「アプリケーション割当後のユーザー通知」等、環境に合わせてカスタマイズください。
・フローの詳細
１．トリガー
[User Added to Group（グループへのユーザー追加）]をトリガーとします。しかし、これだけだと、どのグループへのユーザー追加でもフローが回ってしまうため、条件分岐でグループ名を指定します。
※キャプチャの解説：グループにユーザーが追加される→グループ名が[Office 365 Assignments]であれば後続を処理する
２．M365への連携用にデータを加工する
以下のように、M365側のドメインがOktaで使用中のドメインと異なる場合を想定しています。M365への連携用としてデータの加工を行っています。
oktaアカウントのPrimary email = user01@oktadom.co.jp
M365のUPN = user01@example.co.jp
※キャプチャの解説：
[Read User]…グループに追加されたユーザーの情報を取得する
[Text Split]…取得したユーザー情報の内、[Primary email]を[@]を仕分け文字として分ける
[List At]…[Text Split]で作成した配列の1番目の値を取得する（例であればuser01が格納される）
[Text Compose]…[List At]で取得した文字列にM365のドメインを結合する（outputにuser01@example.co.jpが格納される）
３．処理実行
いよいよM365にユーザーを作成します。作成後の処理として、OktaのSSO用アプリケーションにユーザーを追加→追加したユーザーのアプリケーションプロファイルを更新します。
※キャプチャの解説
[Azure Active Directory Create Cloud User]…EntraIDのユーザーを作成します。今回はOktaユーザーのIDをimmutableIDとして利用することにしました。その他属性値はキャプチャを参照ください。（２で加工したデータ等を使っています）
[Okta Assign User to Application for SSO]…SSO用アプリケーションにユーザーを追加します。アプリケーションの固有IDや追加するユーザー情報を指定します。
[Object Construct]…次処理のためのデータ加工です。M365アカウントに設定した[userName]と[immutableID]を格納します。
[Okta Update Application Profile for Assigned User]：アプリに追加したユーザーの設定を更新します。[Object Construct]のoutputをユーザー設定に追加します。課題②のキャプチャ部分の設定が完了します。
作成したフローを動かしてみる
検証用にユーザーを新規作成します。
[Office 365 Assignments]グループにuser01@nextmode.co.jpを追加します。ここから処理開始です。
M365上に自動でユーザーができました！
OktaのSSO用アプリへのユーザー追加、プロファイル設定も自動で完了しています！
最後に
今回はLCMライセンスを未契約の環境向けに、Microsoft365との連携で発生する課題とスマートな対処法を案内させていただきました。
紹介したフローはとても雑な作りですが、冒頭申した通り、エラー処理を作りこんでいけば十分運用で利用できる挙動になるかと思います。
次回ブログもお楽しみに！
