こんにちは!たつみんです。今日はOktaとAzure ADのフェデレーション設定について重箱の隅をつつくような内容です。
はじめに
会社の規模が大きくなってくると複数のドメインを取得したり、取得済みのドメインにサブドメインを追加して用途に応じて使い分けるということがあると思います。
Office 365を利用するためにAzure ADにカスタムドメインを追加することもあるでしょう。このような時にOktaとフェデレーション設定をすることで複数のドメインを使い分けてSSOやProvisioningを行うことが可能です。
ただし、ここで注意しなければならないのが複数のドメインを利用し、SSOやProvisioningを行う場合とサブドメインを利用し、SSOやProvisioningを行うを行う場合では設定作業の内容や考慮する点が異なります。
ドメインとサブドメインについて
よくご存知の方も多いかとは思いますが認識を統一する意味でもこのブログ記事においてのドメインとサブドメインについて記載しておきます。
ドメインとは、以下のようなものを指します。
- example.com
- example.net
これらはそれぞれ独立したドメインとして存在します。
サブドメインとは、以下のようなものを指します。
- sub.example.com
これはexample.comにsubを付加した状態です。サブドメインはあるドメインの一部として存在します。つまりsub.example.comとexample.comの2つのドメインは関連性が高いとも言えます。
この関連性が高いという感覚がこれ以降の内容の理解に役立ちます。
複数のドメインを利用する場合
複数のドメイン(例:example.comとexample.net)を利用する場合はあらかじめAzure AD側でカスタムドメインとして追加しておけば、あとはOktaの設定としては以下のブログのSSO設定の手順6.でFetch and Selectを実行し、手順7.で表示される選択肢から利用したいドメインを複数選択します。
実はこれだけで複数のドメインを利用することが可能となります。
ポイントはFetch and Selectで複数のドメインが選択肢として表示される点です。例えば以下のような選択肢が表示され複数選択が可能となることが期待値です。
- example.com
- example.net
ドメインとサブドメインを利用する場合
一方でドメインとサブドメインを利用する場合(例:example.comとsub.example.com)もAzure AD側であらかじめカスタムドメインとして追加しておく点は変わりませんが、Oktaの設定としては大きく異なります。 以下のブログ記事と異なる点について記載します。
まずSSO設定の手順5.で、WS-Federation Configurationはデフォルトで選択されているAutomaticではなく、Manual using PowerShellを選択する必要があります。
具体的な手順は以下です。
- WS-Federation ConfigurationでManual using PowerShellを選択します。
- すでにAutomaticで設定済みの場合は以下のように警告が発生し、一時的にSSO設定が無効になる旨が表示されます。 Manualで設定を続行するには、Continue with Manualをクリックします。
- すでにAutomaticで設定済みの場合は以下のように警告が発生し、一時的にSSO設定が無効になる旨が表示されます。 Manualで設定を続行するには、Continue with Manualをクリックします。
- Office 365 domainに手動で利用したいドメインを入力します。
- この時サブドメインではなく、サブドメインと関連性が高いドメインを入力する必要があります。(ハマりポイントなので注意しましょう。)
- この時サブドメインではなく、サブドメインと関連性が高いドメインを入力する必要があります。(ハマりポイントなので注意しましょう。)
- Saveをクリックします。
- View Setup Instructionsをクリックします。
以下のようにセットアップ手順が表示されます。 - 表示されるView Setup Instructionsの内容に従い、PowerShellにて以下のコマンドを実行し、Azure ADに接続します。
Connect-MsolService
この時、onmicrosoft.comドメインのグローバル管理者アカウントでサインインが求められます。 - 次にView Setup Instructionsに記載のIf your domain is not already federated, enter the followingに記載されているコマンドをPowerShell上にコピー&ペーストして実行します。
この時記載内容の-DomainName
部分は2.で入力したドメインとなっています。サブドメインではなく、関連性が高いドメインが記載されている状態が正しいので間違いがないか念の為、確認しておきましょう。
以上でドメイン(example.com)とサブドメイン(sub.example.com)の両方を同時に利用できる設定となりました。以降のProvisioning設定などは先に紹介したブログと同等となります。
確認のためドメインのパターン(example.com)とサブドメイン(sub.example.com)の両方のパターンでテスト用にOktaユーザーを作成し実際にアサインを行い、ProvisioningされることやSSO可能であることを確認しましょう。
Automaticと比べてManual using PowerShellの場合は以下の点が少々煩わしく感じると思います。
- PowerShellを実行する手間
- 1アプリで設定可能なドメインは1つのみ
- 今回の例ではexample.comとexample.netをひとつのアプリで同時に設定できない
補足
Oktaではサブドメインを直接指定することはできず、サブドメインと関連性の高いドメインを指定する必要があります。これはサブドメインの変わりに代表して関連性の高いドメインにお願いするというイメージを持っていただくと比較的わかりやすいかと思います。
- example.com(sub.example.comも含む)
- example.net
ということはAutomaticで設定を進めたとしても、Fetch and Selectで関連性の高いドメイン(今回の例ではexample.com)を指定すればそれだけでサブドメインも利用できるようになると思うと思います。実際にAutomaticで設定自体は完了することができますが、サブドメインを利用するユーザーでSSOを行うとすると以下のようにAADSTS50107:The requested federation realm object '<サブドメイン>' does not exist.
エラーとなってしまいます。
これは以下のOkta公式ドキュメントでも注意として軽く触れられています。
https://help.okta.com/oie/ja-jp/Content/Topics/Apps/Office365/multiple-domains-support.htm
- 単一のアプリでドメインを複数のサブドメインとフェデレーションすると、サインインエラーが発生します単一のアプリでドメインを複数のサブドメインとフェデレーションすると、サブドメインのメンバーがサインイン時にエラーを受け取ります。これを回避するには、PowerShellを使用してドメインを手動でフェデレーションします。「WS-Federation(手動)方式を使用してシングルサインオンを構成する」を参照してください。
複数のドメインとサブドメインを利用する場合
サブドメインを利用するOktaアプリケーションで設定できるドメインはひとつのため、関連しないドメインを追加することはできません。そのため、別アプリとして設定を行う必要があります。
具体的な例として、サブドメインを追加する前の状態が以下のような構成の場合はアプリケーションからどちらかのドメインを外して新しく作成するアプリケーションで設定を行うという分離作業を行う必要があります。
分離作業前
- アプリケーション
- WS-Federation Configuration:Automatic
- ドメインの指定:example.com,example.net
分離作業後
最終的な構成は以下のようになります。
- アプリケーション1
- WS-Federation Configuration:Manual using PowerShell
- ドメインの指定:example.com(sub.example.comも利用可能となる)
- アプリケーション2
- WS-Federation Configuration:Automatic
- 将来的にサブドメインを追加する可能性があるならManual using PowerShell
- WS-Federation Configuration:Automatic
- ドメインの指定:example.net
この分離作業に伴い一時的にSSOできなくなる瞬間があることやユーザーのアサインを調整する際に意図しないDeprovisioningが発生しないように細心の注意を払う必要があります。
最後に
OktaとAzure ADとのフェデレーション設定は鬼門と呼んでいいほどのたくさんの考慮事項がありますが、サブドメインの扱いもその一つと言えそうです。
このサブドメインの扱いや見え方が直感的でないために、状況を把握するのが難しくどハマりしてしました。また、設定方法をManual using PowerShellへ切り替えなければならなく、PowerShellでAzure ADの操作を行うための準備なども必要だったのでよりとっつきにくい印象がどうしてもありました。
Automaticでうまくサブドメインを扱えないのは辛いので今後改善されるといいなと思っています。
それではまた別の記事でお会いしましょー!