どーも、たつみんです。
今回はOkta Identity Engine（以下、OIE環境）でAzure ADとのフェデレーションを行う際に気を付けるポイントやこうするといいんじゃないかなってポイントを具体的にご紹介しようと思います。
Classic環境の時は以下のブログにお世話になっていました。今回はこのClassic環境でのブログをもとにOIE環境ならではのポイントを押さえた解説記事です。
はじめに
OktaとAzure ADをフェデレーションという方法で連携することで以下のことが可能となります。
- Office 365へのログインがOktaで行うことが可能となる
- Azure AD/Intuneの管理者がそれぞれの管理ポータルにログインする際にOktaで行うことが可能となる
- Windows端末をAzure AD Joinする際にOktaで認証を行うことが可能となる
つまりAzure AD/Intune/Office365といったMicrosoft系の認証をOktaに一元化できるということです。
設定作業
早速作業に入る前に今回の検証で利用する環境は以下のとおりです。
- Azure ADプライマリ ドメイン
- homeengrcom.onmicrosoft.com
- 追加するカスタムドメイン
- home-engr.com
- ドメイン レジストラ
- AWS Route53
- Okta
- 検証環境
Azure ADの事前準備
最初にAzure ADでカスタムドメインが設定されているかをご確認ください。プライマリ ドメインであるonmicrosoft.comドメインしか設定されていない場合はカスタムドメインを追加する設定を行う必要があります。
onmicrosoft.comドメインとカスタムドメインについて
Oktaとのフェデレーション設定ではプライマリ ドメインであるonmicrosoft.comドメインで連携設定を行い、カスタムドメインを操作するイメージです。
この二つのドメインの役割の違いが混乱の元となり、設定を行う際に取り違えてしまう事例が非常に多いようです。それぞれ別の役割があるという点をあらかじめしっかりと認識しておくとよいでしょう。
以降の設定の説明の中でもonmicrosoft.comドメインとカスタムドメインは明確に区別して記載をしますので注意しながら読み進めていただければと思います。
カスタムドメインの追加
カスタムドメインを追加していない場合は以下のドキュメントを参照し設定を行います。
今回は私の環境になりますがダイジェスト版として手順を掲載します。ご利用されているドメイン レジストラによって操作が異なりますのでその点はご了承ください。
- Azure AD管理画面( https://portal.azure.com/ )から管理>カスタム ドメイン名へ移動し、カスタムドメインの追加をクリックします。
- 右側に追加したいドメインを入力し、ドメインの追加をクリックします。
- 以下のようにドメイン レジストラで追加すべき情報が表示されます。
- 今回の場合、ドメイン レジストラはAWS Route53なので、AWS Route53のホストゾーンから該当のドメインを選択し、レコードの作成をクリックします。
- レコードタイプをTXTを選択し、値とTTLを3.で表示された値を入力し、レコードを作成をクリックします。
- Azure ADの画面に戻り、確認をクリックします。
- 画面が更新され以下のように状態が
確認済みとなったことを確認します。
ドメイン レジストラによってはTXTレコードの反映に数時間単位で時間がかかる場合があります。
- 一つ前の画面に戻り、以下のようにカスタムドメインが追加され、状態が
確認済みとなっていることを確認します。
プライマリドメインについて
カスタムドメインとして追加したドメインはプライマリとして設定をしたくなりますが、プライマリドメインはあくまでもonmicrosoft.comドメインの状態とする必要があります。
設定を行うAzure AD側の管理者アカウントについて
onmicrosoft.comドメインのアカウントでなおかつ、グローバル管理者の権限が必要となります。また、設定を行う中でこのアカウントに対してMFAが有効化されているとOktaでの設定が行えないため無効化しておきます。
今回はAzure ADテナント全体に対してMFAを無効化して進めます。
Azure ADのプロパティ>セキュリティの既定値の管理>セキュリティの既定値の有効化をいいえを選択します。
理由についてはなんでもいいので選択し、保存をクリックします。今回は条件付きアクセスを使用しているを選択しました。
非ASCII文字の扱いについて
一般的にOktaを含むIdPでは漢字、ひらがな、カタカナのような非ASCII文字を利用することは好ましくありません。OktaとAzure ADをフェデレーション設定をするとOkta上のユーザー情報であるFirst name、Last nameがAzure ADに反映されます。そのためもしOktaやAzure ADで非ASCII文字を利用している場合はあらかじめ変更をしておきましょう。
特にWindows端末をAzure AD Joinする場合はusers フォルダへの影響もあります。詳細は以下のブログのケース① Azure AD Join 時の問題をご参照ください。
Oktaでの設定
カスタムドメインの追加と、Azure AD側の管理者アカウントの準備ができたらOktaで設定を行っていきます。
SSO設定
- Okta管理画面Applications>ApplicationsからBrowse App Catalogをクリックします。
- カタログのトップページにMicrosoft Office 365があるのでクリックします。
もしなければMicrosoft Office 365で検索します。
- Add Integrationをクリックします。
- Microsoft Tenant Nameに
onmicrosoft.comドメインの先頭部分のみを入力し、Nextをクリックします。
カスタムドメインと混同しやすいので注意して入力しましょう。
- Office 365 Admin UsernameとPasswordには
onmicrosoft.comドメインのグローバル管理者アカウントの認証情報を入力します。
- Office 365 DomainsのFetch and Selectをクリックします。
- Select domains for federationでカスタムドメインを選択します。
選択肢に表示されるonmicrosoft.comドメインは選択しないでください。
- カスタムドメインが反映されたことを確認します。
- Advanced API AccessでAuthenticate with Microsoft Office 365をクリックします。
- サインイン画面で、
onmicrosoft.comドメインのグローバル管理者アカウントでサインインを行います。
- Okta Microsoft Graph Clientに対してアクセス許可を与えるために承諾をクリックします。
Azure側に作成されたOkta Microsoft Graph Clientについては後述します。
- Oktaの画面に戻ってくるのでDoneをクリックします。
Provisioning設定
- Provisioningタブに移動し、Configure API Integrationをクリックします。
- Import Groupsのチェックを外します。
このチェックがついているとAzure AD上のグループをOktaに読み取り専用のグループとして取り込まれます。明確なユースケースがない場合は不要なOktaグループが増えてしまい混乱の元となるため、チェックは外しておきます。
チェックを外すと以下のような確認画面が表示されますので内容を確認し、Continueをクリックします。
- Enable API integrationにチェックを入れ、
onmicrosoft.comドメインのグローバル管理者アカウントの認証情報を入力し、Test API Credentialsをクリックします。
- 以下のように
Microsoft Office 365 was verified successfully!と表示されたことを確認し、最後にSaveをクリックします。
- To Appに移動し、Office 365 Provisioning Typeを選択します。ここではUniversal Syncとしました。
4種類あるProvisioning Typeの解説は後述します。
- ProviosioningオプションはCreate Users、Update User Attributes、Deactivate Users、Sync Passwordすべてにチェックを入れ、Password typeはSync Okta Passwordを選択します。
Sync Passwordについては後述するレガシー認証をすべて排除できるのであれば、あえて有効化しないことも可能です。
- Microsoft Office 365 Attribute MappingsでUsage locationについて編集ボタンをクリックします。
- 以下のようにAttribute valueに指定されている数式の部分でデフォルトで
USとなっている箇所をJPとします。
これによりOktaでアサインされたユーザーはAzure AD上でユーザーの利用場所が日本となります。利用場所の設定がUS状態のままだと正しくライセンス付与が行えないことがあるために設定をします。
Provisioning状態の確認
- 確認のためAssignmentsタブに移動し、検証するための
カスタムドメインを持つ検証用ユーザーをアサインします。この時にLicensesやRoleについても割り当てを行うことができますが現時点では一旦チェックをは入れずにアサインを行いました。
Oktaでの効率的なLicenseやRole管理については後述します。
- 正常にProvisioningされたかを確認するためにAzure ADの管理画面を確認します。
ユーザーにOktaでアサインしたユーザーが存在することを確認します。
- そのユーザーをクリックし、プロパティを表示します。
この時、オブジェクトIDとオンプレミスの不変IDが表示されていることを確認します。
- Okta画面でAssignmentsからユーザーの編集ボタンをクリックします。
- この時に表示された
External IdがAzure ADのオブジェクトIDと、Immutable IDがAzure ADのオンプレミスの不変IDと一致していることを確認します。これらの値が一致していない場合はうまく設定ができていない可能性があります。なにかトラブルが起きた時に状況把握するひとつの要素としてこれらの値の関係性は覚えておくと役立ちます。
SSOの確認
- シークレットブラウザなどで検証するユーザーでOktaにログインします。
- ダッシュボードに表示されているMicrosoft Office365 Office Portalなどをクリックし、正常にログインできることを確認します。
各設定の解説
Okta Microsoft Graph Clientについて
SSO設定の手順11.によってAzure ADのエンタープライズ アプリケーションにOkta Microsoft Graph Clientというアプリが作成されます。OktaでSSOやProvisioningを実現する際にはこのアプリケーションがAzure AD側のGraph APIを実行しています。
もし、Oktaとの連携を取りやめる場合やOkta側のアプリケーションを削除し再度設定をゼロベースでやり直す場合などはOkta側でのアプリケーション削除に加えて、Azure AD側のこのOkta Microsoft Graph Clientについても削除する必要があります。
削除するにはエンタープライズ アプリケーションの一覧からOkta Microsoft Graph Clientを選択し、プロパティに移動し、削除をクリックします。
Provisioning Typeの解説
下図のようにOktaで制御できる項目がLicenses and Roles Management Only<Profile Sync<User Sync<Universal Syncの順となっています。
なお、User SyncおよびUniversal Syncについては、Azure AD Connectなどを使用している場合は利用できないなどの留意点がございます。詳細は図の引用元でもある以下のOkta公式ドキュメントをご確認ください。
Deprovisioningオプションについて
Provisioningの設定でCreate Users、Update User Attributes、Deactivate Usersとチェックをつけましたが、Deactivate Usersのことを指して特にDeprovisioning（デプロビジョニング）と言うことがあります。
OktaのMicrosoft Office 365アプリケーションでは有効/無効を切り替えるチェックボックス以外に、有効にした時に表示されるオプションがEarly Access（早期アクセス機能）として存在します。
有効化すると下図のようにメニュー項目が表示され4つのオプションが選択可能となります。これによりDeprovisioningを行った際にサインインをブロックするだけなのか、ライセンスも剥奪するのかなど、より柔軟な運用を組むことができます。
この機能を利用するにはOktaサポートに連絡する必要があります。詳細については以下のOkta公式ドキュメントをご参照ください。
認証ポリシーについて
Oktaでは通常、新しく追加アプリケーションはDefultラベルが付いた認証ポリシーに割り当てられますが、Microsoft Office 365アプリケーションは専用ポリシーが自動的に作成され割り当てを変更するこはできません。
この専用ポリシーはOffice 365アプリケーションへの認証以外にもWindows端末のAzure AD Joinを行う際やAzure AD Join済みのWindows端末にユーザーを追加する際などが考えられます。それぞれのユースケースを満たしつつ安全な認証ポリシーを設定する必要があります。
全体を通して以下のように4つのルールを包含するポリシーを組みましたのでそれぞれ解説をします。
ルール1 Allow Web and Modern Auth Rule
条件としてClient isの部分をWeb BrowserおよびModern Authenticationを指定し、認証時にはUser must authenticate withでAny 2 factor typesとしています。
このルールでは通常のブラウザやWordやExcelのようなOffice 365アプリで利用可能な先進認証を行う時にMFAが求められます。
またRe-authentication frequency isでは12時間としています。
ちなみにOffice 365アプリについてはOktaのこの設定とは関係なくデフォルトで有効期限が90日の更新トークンが発行されます。通常の利用であればWordやExcelなどのOffice 365アプリで認証が切れてしまって再度Oktaでの認証が必要となることはありません。
ルール2 Allow AutoPilot Rule
条件としてDevice platform isをWindows、Client isの部分をWindows Autopilotを指定し、認証時にはUser must authenticate withでAny 2 factor typesとしています。
このルールではWindows端末をAzure AD Joinする際にクライアント判定がWindows Autopilotとなるため個別に指定しています。認証時つまりAzure AD Joinする際にはMFAが求められます。
またRe-authentication frequency isでは2時間としていますが、Azure AD Joinを行うタイミングでだけ必要な認証であるためもっと短くしても問題ないかと思います。Every sign-in attemptとしてもよいかもしれませんね。
ルール1とルール2はほぼ同じように見えるため一つにまとめてもよさそうに見えますが、あえて分けています。 今回のユースケースでは触れていませんが認証の条件としてDevice Trustを追加したい場合はルール1には追加することができますが、ルール2については追加することはできません。これはルール2が適用されるAzure AD Joinを行うタイミングではそのデバイスの状態を確認することができないため、Device Trustを条件として追加することは適切ではありません。将来的な設計を考えてあらかじめルールを分けておくほうが混乱が少なくてよいかと思います。
Client isにWindows Autopilotが表示されていない場合について
記事執筆時はEarly Access（早期アクセス機能）として提供されていますのでSettings>FeaturesからWindows Autopilot Enrollment Policyを有効化しておきましょう。
ルール3 Allow Legacy Auth for Add Azure AD User Rule
条件としてUser’s group membership includesで特定のOktaグループを指定し、Device platform isをWindowsを指定、Client isの部分をExchange ActiveSync/Legacy Authを指定しています。認証時にはUser must authenticate withでPasswordとしています。
このルールではAzure AD Join済みのWindows端末にAzure ADユーザーを追加する場合にはMFAが利用できないため、パスワードのみを利用する設定としています。
またRe-authentication frequency isではEvery sign-in attemptとしています。
いわゆるレガシー認証について
MFAが利用できずパスワードしか利用できないレガシー認証は極力利用すべきではありません。 今回のユースケースのようにどうしても利用しなければならない場合以外はルールとして追加すること自体やめておきましょう。今回のユースケースの場合でもOktaグループを指定し、対象ユーザーを絞って実行するのがよいでしょう。もちろんWindows端末に対象ユーザーを追加する作業が終わったら速やかにOktaグループから対象ユーザーを削除することを徹底しましょう。Okta Workflowsを利用して自動化することも十分可能です。
なお、Azure AD Join後のWindows端末へのログイン時にパスワード認証を選択してしまうとレガシー認証となりますので、Windows HelloやPINを利用する運用とし、極力レガシー認証は利用しないようにしましょう。
ルール4 Catch-all Rule
このルールはデフォルトで用意されており、削除をすることができません。
条件となるIFについてはすべての条件を受け入れる設定となっており、編集ができません。そのため、Access isでDeniedとしアクセスを拒否する設定としています。
ルールは上から順番に評価され、条件に合致した場合に下位のルールについては評価されません。そのためルールの順番は大事な要素となります。
Catch-all Ruleは必ず最下位に位置しますので、このルールでアクセスを許可してしまうと上位ルールでの設定が意味がなくなってしまいますので必ずAccess isをDeniedとします。
OktaでAzure ADの効率的なRole管理やLicense管理について
Azure ADの管理といえばロール、ライセンスそれぞれの割り当てについても考える必要があります。いくつかの条件によってOktaで管理するのが適切かどうかが考えられます。それらの条件の組み合わせを鑑みて最終的にどのように管理するかを検討しましょう。
Role管理
Azure ADでPIMが利用できる場合
Azure AD P2ライセンスであればPrivileged Identity Management（PIM）を活用することできます。
PIMでは特権管理の時限的な付与や他者の承認を組み込むことができるため最小権限の原則に従ったより厳密な特権管理が行えます。
PIMの設定については以下のブログ記事やMicrosoft公式をご参照ください。
Azure ADでPIMを利用できない場合
Azure AD P1を利用しており、管理すべきロールがグローバル管理者権限と一般ユーザー権限しかないような場合はOktaのグループアサイメント機能を利用し、Oktaで管理するのがよいでしょう。
この時に注意が必要なのはグループをアサインする際に優先順位があるということです。ロールが異なる複数のグループにユーザーが所属していた場合は、より上位のグループの設定のみが有効となります。所属する複数のグループに紐づくロールが合算されるわけではないので注意しましょう。
詳細については以下のブログをご参照ください。
2023.04.25追記
合算できる方法がありましたので記事にしました。課題になるかもしれない点も記載しています。詳細は以下をご参照ください。
License管理
Azure AD上で利用しているライセンス種別が多い場合
ライセンスが多くユーザーへの割り当てパターンが複数ある場合はOktaでのグループアサインではなく、Azure AD上でセキュリティグループを活用し管理するほうがよいでしょう。
この手法自体はAzure AD単体での運用となりますのでそれほど難しいものではないでしょう。
Azure AD側のセキュリティグループの管理をOktaで行いたい場合はOktaのPush Groups機能を活用することでセキュリティグループのメンバー管理をOkta側に寄せることができます。この際、Push GroupsではAzure AD上の既存のセキュリティグループとOktaグループを紐づけることができずに新たにセキュリティグループが作成される点には注意が必要です。
Azure AD上で利用しているライセンス種別が少ない場合
例えば利用しているライセンスがMicrosoft 365 E5とMicrosoft 365 Apps for Businessのみのような場合は、Oktaのグループアサイメント機能を利用しロールと同様に専用Oktaグループを作成し管理するのがよいでしょう。
ただし、ライセンス種別が少ない場合でもロール管理もグループアサインで行う場合はライセンス種別とロールの組み合わせにより、作成すべきOktaグループも爆発的に増えてしまうことが想定されます。
この場合はAzure AD上のセキュリティグループでの管理を検討するのがよいでしょう。
LicenseやRole管理の結論
シンプルな運用であればOktaのグループアサイン機能を活用できますが、そうでない場合はおすすめできません。また、Oktaグループに対してライセンスやロールをアサインする際の選択肢が多く、あまり直感的とは言えない点もおすすめできない部分です。
具体的にはMicrosoft 365 E5という製品のライセンスを割り当てるには包含するサービス プランである70以上の項目にチェックを入れなければなりません。この製品名とサービス プランの対応表については以下のMicrosoft公式ドキュメントをご参照ください。
最後に
このブログ記事を読めばフェデレーション設定やOktaでのAzure ADの管理手法について一通り網羅できることを目指して書いてみました。
Azure ADとのフェデレーション設定でのハマるポイントや認証ポリシーで考慮するポイント、ロールとライセンス管理手法など非常に多くの要素があり、なかなか一筋縄では行かない印象があります。私も検証で何度も作業してはやり直しを繰り返して理解を深めました。
ただこのブログ記事の読者のほとんどは設定を行う機会は多くて1,2回かと思います。
このブログ記事がみなさんの設定作業の助けになれれば嬉しいです。
ではまた〜?
