🪢

OktaをIdPとしてAzure ADとのフェデレーションを構成する

2021/07/05に公開

Azure AD

Okta

tech

はじめに

OktaをIdPとしてAzure AD(Microsoft 365)とフェデレーションを構成する際、Okta公式のドキュメント通りだとうまくいかない部分があったり書いてないことがあったのでそのメモです。
途中でハマったポイントについても書いています。

なおOktaのドキュメントやアプリケーションテンプレート上だとOffice 365と表記されている（恐らくエンドユーザーが主に触るのはOffice 365なのでそれに合わせている）のですが、実際の接続先はAzure ADなので本記事上では個人的にもしっくり来る Azure AD のほうで表現しています。

前提

今回は下記のシナリオを前提として構成した例になります。

Oktaをメインディレクトリとする
オンプレミスのActive Directoryは無し
Windows PCはAzure AD Join + Intuneにて管理運用している

なおOktaとAzure AD間でフェデレーションを構成するにはAzure ADに追加しているカスタムドメインごとにOkta側のアプリケーション設定をする必要があります。
またOkta側をメインディレクトリとする場合、Azure AD側の {yourtenant}.onmicrosoft.com のドメインについてはフェデレーションの対象外（SSOやプロビジョニングは行われない）となります。
👇イメージ図

Azure AD側の準備

カスタムドメインをAzure ADに追加する

カスタムドメインが無いと紐付ける先が無いので、もしまだAzure ADでカスタムドメインを運用していなければ追加が必要です。

プライマリドメインを `{yourtenant}.onmicrosoft.com` のほうにする

Azure Active Directory > カスタムドメイン名 の画面でドメインの設定を確認します。
フェデレーション対象のカスタムドメインがAzure AD上でプライマリとなっているとフェデレーションを構成できないので、プライマリになっている場合は別のドメインをプライマリに設定します。
今回は {yourtenant}.onmicrosoft.com をプライマリに設定しました。

プロビジョニングに使用するためのグローバル管理者アカウントを作成する

（これはユーザーアカウントやグループをOkta⇔Azure AD間でプロビジョニングしない場合は設定不要です）
フェデレーションするカスタムドメインではなく {yourtenant}.onmicrosoft.com のほうのドメインでユーザーを作成し、グローバル管理者のロールを割り当てておきます。
なお作成したユーザーのMFAが有効になっているとフェデレーションが失敗するのでMFAを無効化しておきます（参考：Office 365 WS-Fed Integration issue）

全体のMFA設定をOFFにするには Azure Active Directory > プロパティ > セキュリティの既定値群の管理 にて セキュリティの既定値群の有効化 を いいえ にします

セキュリティの既定値群を無効化するとどんな影響があるのかが気になる方はこちらを参照してください

またユーザーごとのMFAについては Azure Active Directory > ユーザー > ユーザーごとの MFA にて確認することが可能です。

SSOを設定する

ここからはOktaの管理画面を操作します。
なおOktaにはMicrosoft Office 365を統合するためのアプリケーションテンプレートが用意されているのでこれを使います。

Applications > Browse App Catalog > Microsoft Office 365 > Add を選択します。

`General Settings`

Application label
- 管理用のアプリ名称を設定します
Microsoft Tenant Name
- 例として thdyjp.onmicrosoft.com というAzure ADテナントを使用する場合ここには thdyjp と入力します
Display the following links
- Oktaダッシュボードに表示するアプリアイコンを選択します
Seats（Optional）
- ここに購入済みライセンス数を入れておくと使用率のレポートが出せます
Application Visibility
- ダッシュボードにアイコンを表示するかどうかの設定です
Browser plugin auto-submit
- 有効にするとユーザーがログインページにアクセスすると自動的にログインします
  すべて設定したら Next を選択します

`Sign-On Options・Required`

Sign on methods
- WS-Federation を選択
WS-Federation Configration
- ここは特別な理由がなければ Okta の推奨通り Automatic (recommended) を選択
Office 365 Admin Username
- Azure AD 側で作成した {yourtenant}.onmicrosoft.com のグローバル管理者アカウントを入力
Office 365 Admin Password
- 前述のグローバル管理者アカウントのパスワードを入力
Office 365 Domains
- Fetch and Select を選択するとドメイン選択画面が出るのでフェデレーション対象のカスタムドメインを選択して Select
- Default Relay State
  - ここは空欄でOK
- Credentials Details
  - ここはデフォルト設定のまま
- Advanced API Access
  - プロビジョニングを行う場合はここのチェックを入れて Authenticate with Microsoft Office 365 を選択
  - グローバル管理者のクレデンシャルを入力すると認可を求められるので 承諾 を選択
    
    この時Azure AD側のエンタープライズアプリケーションの中にGraph APIを叩いてAzure ADを操作するためのアプリが作成されます。もしOkta側でAzure ADとのフェデレーション設定をすべて削除したいとなった場合はこのOkta Microsoft Graph Clientも忘れずに削除しましょう。
Done を選択

ここまででSSOの設定は完了。
続いてプロビジョニングの設定を進めます。

プロビジョニングを有効化する

プロビジョニングについて理解する

Oktaにて用意されているAzure AD用のプロビジョニングオプションは4種類あり、それぞれできることが違います。
下記表にまとめていますが、右に行くほどOkta側でできることが増えます。

サポートされている操作	Licenses and Roles Management Only	Profile Sync	User Sync	Universal Sync
ユーザーのプロビジョニング
ライセンスとロールの割り当て	◯	◯	◯	◯
ユーザー作成	✕	◯	◯	◯
ユーザーの非アクティブ化	◯	◯	◯	◯
Azure AD側でのユーザー編集	◯	◯	✕	✕
プロファイルの同期
基本的なプロファイル同期	✕	◯	◯	◯
一部の拡張属性の同期	✕	✕	◯	◯
すべての拡張属性の同期	✕	✕	✕	◯
ADグループとリソースの同期
セキュリティグループ	✕	✕	✕	◯
連絡先	✕	✕	✕	◯
配布リスト	✕	✕	✕	◯
リソースメールボックス	✕	✕	✕	◯

そしてこれらのプロビジョニングオプションにおける個人的注意ポイントを紹介します。

一度User SyncおよびUniversal SyncにするとLicenses and Roles Management OnlyやProfile Syncには戻せない
戻したい場合は一度Okta側で作成したアプリを削除してイチから作り直すことになります。
（プロビジョニング設定の変更可否イメージ図）
Azure AD Connectを使用してオンプレミスADとHyblid環境を構成しているなど、既にフェデレーションが行われている場合はUser SyncおよびUniversal Syncを使用できない
なのでHyblid Azure AD Joinを構成している組織では実質Licenses and Roles Management OnlyかProfile Syncしか選べません。
User SyncおよびUniversal SyncにするとAzure AD（Microsoft 365管理センター）側で直接ユーザーを編集できない
普段の運用でAzure AD側からも編集できる必要があるかどうかは事前に考慮して選択しましょう。
Okta側のライセンスやロールの表記はAzure AD側と若干異なる
普段利用するライセンスのグループをOkta側に作成してそこにメンバーを追加する運用にすれば戸惑うのは最初だけで済むかもしれません。

プロビジョニングを設定する

どのプロビジョニングオプションにするか決めたら、実際に設定します。

Provisioning > Integration > Congigure API Integration を選択し、Enable API Integration にチェックを入れて Admin Username と Admin Password にAzure ADのグローバル管理者ロールを持ったアカウントのID/パスワードを入力します。
Import Groups はAzure AD側のグループをOktaにインポートするかどうかの設定でここは任意です。
Test API Credentials を選択してID/パスワードに誤りが無いことを確認できたら Save を選択します。

これでプロビジョニングを行うために必要な権限がOkta側に与えられ、ProvisioningタブにTo App と To Oktaが出現します。

ここからは組織の要件に応じて必要なプロビジョニングの設定をします。
以下は一例として、プロビジョニングオプションに Profile Sync を選択して進めます。

Create Users、Update User Attributes、Deactivate Users すべてチェックをつけます。これでOktaでユーザーを作成したり無効化するとAzure AD側にも自動で反映するようになります。

あとは必要に応じてMappingsで属性の紐付けを行い、Assignmentタブからユーザーをアサインすれば完了です。
実際にプロファイルが同期されているかの確認や、シングルサインオンが行えるかどうかをテストを行ってみましょう。

ハマったことのメモ

いろいろハマったので合わせて書き残しておきます。

OktaのパスワードでWindows PCにサインインできるようにするのにハマった

シングルサインオンを構成しているのになぜパスワード同期を有効にするのかというと、Windows PCのパスワードサインインはいわゆるレガシー認証であり認証をOktaにリダイレクトすることができないためです。
Azure AD JoinしているWindows PCのサインインパスワードをOktaと同じものにすることで、ユーザー体験をシンプルにしたかったという目的がありました。

そこでProvisioning設定のSync Passwordにチェックを入れ、Sync Okta Passwordを選択しました。

しかし実際にWindows PC側でパスワードでサインインしようとするとパスワードに誤りがあると表示されるのでOktaサポートに確認したところ、「デフォルトでレガシー認証は許可されないようになっているのでWindowsサインインさせたいなら手動で許可してね」と回答がありました。

どこを設定するかと言うとSign onタブの Sign On Policy で Add Rule を選択し、Exchange ActiveSync/Legacy Authのところにチェックを入れる、これだけなんですがドキュメントに書いてなくてハマりました。

Immutable IDが消えた

Immutable IDというのはOktaとAzure ADのユーザーアカウントを紐付けるために必要な属性値で、通常これは自動的に割り当てられるのですが検証等でユーザーをアサインしたりはずしたり設定を色々触っているとなぜか消えることがあるようです。そしてこれが消えるとSSOもうまく動作しません。
この辺りの詳細はkobasoさんがnoteに書かれているので興味のある方は読んでみてください。

https://note.com/kobaso/n/n6ab079fa0d34

で、実際に消えたらどうすれば良いのかというとPowerShellで適当な値を突っ込むしかないようです。

なお既にフェデレーションが有効になっていると上記ヘルプページの手順ではImmutable IDが変更できなかったりします。
自身の環境では下記のように対応しました。

Connect-MsolService

// ユーザーを列挙してImmutable IDが正しくセットされているか確認
Get-MsolUser -DomainName "thdy.jp" | Select-Object UserprincipalName, ImmutableID

// フェデレーション済みだとImmutable IDを変更できないので一旦UPN変更
Set-MsolUserPrincipalName -UserPrincipalName hoge@thdy.jp -NewUserPrincipalName hoge@thdyjp.onmicrosoft.com

// Immutable IDに指定する文字列は何でも良いので適当な値をセット
Set-MsolUser -UserPrincipalName hoge@thdyjp.onmicrosoft.com -immutableid 2/9JCtHr0EmH+yL07o11vB==

// UPNをもとに戻す
Set-MsolUserPrincipalName -UserPrincipalName hoge@thdyjp.onmicrosoft.com -NewUserPrincipalName hoge@thdy.jp

ユーザーをアサインする場合はグループを利用して一括でバシッとアサインするのが良さそうです。
またアサイン後に Get-MsolUser のPowerShellコマンド等でImmutable IDが正しくセットされているか確認しましょう。

Windows Hello for Businessが「追加のセキュリティ確認」の設定を求めてくる

Azure AD JoinなWindows PCをセットアップする際、Windows Hello for Businessを有効していると通常はAzure AD Joinしたタイミングで携帯電話番号やMicrosoft Authenticatorなどの認証の設定を求める「追加のセキュリティ確認」の画面が表示されます。
しかし今回OktaをIdPとしたことでMFAもすべてOkta側で済ませる前提である以上、これを設定したところでエンドユーザーは実際に使用することはありません。
なんとかしてこれを非表示にしたくて調べたところ、「Okta側でMFAを完了した際のクレームをAzure AD側に渡す」というオプション設定がデフォルトでは無効になっていることがわかりました。

この設定は Settings > Features > O365 Pass Claim For MFA にあたるのでこれをオンにすることで、Windows Hello for Businessのバックアップ設定は求められなくなりました。

Oktaのパスワード変更直後にサインインしなおさずにSSOするとサインインループに陥る

これは再現パターンを見つけるのに苦労したのですが、Oktaのエンドユーザーダッシュボードからパスワードを変更して2〜3分するとトークンが期限切れとなるようで、その状態でOktaに再サインインせずにMicrosoft 365へのSSOをするとサインインのアニメーション画面でループする現象が発生します。

Okta側にはSSOが成功したかのようなログしか出ないのですが、Azure AD側にはStatusがFailureで下記のログがたくさん発生します。

The provided grant has expired due to it being revoked, a fresh auth token is needed. The user might have changed or reset their password. The grant was issued on '{authTime}' and the TokensValidFrom date (before which tokens are not valid) for this user is '{validDate}'.

一度Oktaからサインアウトしてサインインし直せば治るのですが、できれば自動的に再サインインを促す画面が出てほしいですね。（そういえばOktaへのリクエストってどこから上げられるんだろう）

さいごに

記載内容に対する指摘や修正提案、不明点がある場合はコメント欄、GitHub、Twitter等へお願いします。

GitHubで編集を提案