はじめに
こんにちは！たつみんです！
タイトルそのままなのですが弊社が実際の業務で利用しているOktaをClassic環境からOkta Identity Engine（以下：OIE環境）へお引越ししました。
OIEへのお引越しは利用者に対してFastPassによるパスワードレス認証という利便性の提供を行い、管理者目線では柔軟な認証ポリシーの構築やより実装のしやすいDevice Trustを実現したかったという理由からです。
免責事項
今回ご紹介する方法はOkta社が推奨するアップグレード方法ではありません。弊社が検証を兼ねて実験的に実施した内容です。すべての既存Okta Classic環境において有効な手段であることを保証をするものではありません。この方法が有効であるかは組織規模やOktaと連携しているSPの数やその複雑性によって異なります。
お引越しの流れ
以下に大まかな流れをを記載します。
- OIE環境を別途契約し、テナントを払い出す
- OIE環境の整備
- OIE環境に各ユーザーを作成しアクティベーションを行う
- 現在のClassic環境とOIE環境をOrg2Orgで接続する
- OIE環境にブックマークアプリを作成しClassic環境のアプリへの導線を確保する
- 順次SPをClassic環境からOIE環境へ移行する
今回のポイントは既存の環境をそのままアップグレードするではなくOIE環境のテナントを新たに契約し、2つのテナントをOrg2Orgという機能で結ぶ点です。この方法では時間と手間がかかるという欠点がありますが、弊社の場合はこれまでのSSO設定やプロビジョニング設定の見直しや手順の確認を行うという目的もあり採用しました。
お引越し作業内容
OIE環境の払い出し
Okta購入元へ依頼し、Org2Orgで接続する前提である旨を伝えてOIE環境を契約します。もちろん新規テナントなのでURLのサブドメイン部分について新たに指定を行う必要があります。
コストについて
以下の条件であれば限定的に追加費用はかかりませんでした。
- 最終的に移行後はClassic環境を削除する前提である
- OIE環境に既存のClassic環境のOktaユーザーと同一のユーザーを作成した場合
注意
上記はあくまでも限定的なものであるため、永遠にコストがかからないというわけではありません。どのぐらいの期間が猶予されるかは個別に調整となるようですので契約段階でしっかりと確認をする必要があります。
また、現在Okta社からClassic環境のお客様にアップグレードの連絡を順次しており、それは特に追加費用無しでOIEにアップグレードすることが可能とのことです。
OIE環境のセットアップ
各種設定のカスタマイズ
Okta管理画面のSecurity配下の各項目について設定を行いました。
- General
- サインイン時のオプションやアクティベーションメールの期限の定義
- Authenticators
- 利用する認証要素の定義
- OIE環境ではパスワードもOkta Verify等と同様に認証要素として同じ画面で定義
- ユーザーアクティベーション時に登録を行う認証要素の定義
- 利用する認証要素の定義
- Authentication Policies
- 今後登録するアプリケーション用の認証ポリシーの定義
- Global Session Policy
- Okta自体への認証ポリシーの定義
ユーザーの利便性の向上とDevice Trustを実施するために必要なOkta FastPassについても利用可能な状態に設定を行っておきます。Okta FastPassについては下記のブログもご参照ください。
ユーザーの招待とアクティベーション
OIE環境のセットアップが完了したらユーザーを作成し、アクティベーションを行います。弊社の場合はユーザーに対してアクティベーションメールを送付し各自対応をしてもらいました。
簡単なマニュアルを作成し、アクティベーションメールから初期パスワードからの変更と必須設定に指定したモバイル版Okta Verify Push通知のセットアップという流れをフォローするようにしました。また、FastPassを利用を促すためのデスクトップ版Okta Verifyアプリについてもセットアップするように誘導しました。
FastPassの利便性をすぐに体験してもらいたいという想いと、OIE環境ではDevice TrustやDevice Assuranceといった機能を利用するためにOkta Verifyアプリが非常に重要な役割を持ちます。そのためデスクトップ版Okta Verifyアプリを含めて初期段階で適切に誘導を行うという意図がありました。
Org2Org設定を行う
こちらは考え方や手順の詳細が長くなるため別記事としますが、Org2Orgの設定が完了するとClassic環境のダッシュボードやClassic環境に紐づくSPへのアクセスはOIE環境のOrg2Orgアプリに対して定義したAuthentication Policyが適用されます。
詳細は以下のブログ記事をご参照ください。
『Okta Classic環境の認証をOkta Identity Engineに任せてみた』
Device Trust設定
弊社の場合は会社支給端末がMac端末かWindows端末のため以下のブログを参考にJamf ProおよびIntuneで構成プロファイルを作成しました。
Device Trustを実現するためのAuthentication Policyについて
なお、上記それぞれのブログ記事では状況をわかりやすくするため、Authentication PolicyでDevice Trustでない場合はアクセスを拒否する設定していますが、前述したOrg2Orgアプリに対して同様のAuthentication Policyを作成し適用してしまうと混乱が予想されるため、経過措置としてAuthentication Policy配下のRuleを以下のように設定しました。
- 優先順位1はDevice Trustを有効
- 優先順位2ではDevice Trustであるかは問わない（一時的なバイパスルール）
すべての会社支給端末がDevice Trustの準備が整ったと判断した時にバイパスルールを無効化することでDevice Trustを全体適用するという流れを作りました。
実際に、Jamf Pro/Intuneからのプロファイルの適用状況を定期的に確認しましたがうまく適用できない端末があったり、各端末にプロファイルが適用されただけではDevice Trustの準備としては不十分です。ユーザーがOkta FastPassを利用し、Oktaに対してアクセスを行うことで初めて端末がOkta管理画面ではManaged（Device Trust状態）と判定されます。
Okta管理画面でManaged（Device Trust状態）と判定されたかの確認方法について
Okta管理画面で各ユーザーの画面を開いて紐づく端末がManagedであるかを確認することは手間がかかるためAPIによる情報取得を検討しましたが、APIではDevice単体がManagedかどうかという点は取得できましたが、そのDeviceがどのユーザーに紐づくかは取得できませんでした。そこでOkta WorkflowsでOktaのログからeventTypeを指定し複数のイベントの結果から端末とユーザーを紐付けを行いManagedであることを通知する実装を行いました。
この実装については別ブログとして今後執筆予定となります。
2022.12.20 ブログ公開しました！
ユーザー自身によるDevice Trust状態の確認方法について
また、各ユーザーは自分の端末がDevice Trustの準備が整ったのかを把握する方法がありません。ユーザーから問い合わせが多発することも予想されました。そのためDevice Trust状態を確認するためだけのSPと専用のAuthentication Policyを設定しました。これによりユーザーはDevice Trustが適用された場合に自身の端末からのアクセスがどのような挙動になるかを自分自身で確認することができるようになりました。
この時に確認用に利用したSPは以下のものです。
SPの移行
この部分は通常、新規でSPをSSO設定やプロビジョニング設定する場合とほぼ同じですが、新たな観点や少しハマったポイントがありますので一部ご紹介いたします。
Jamf関連に対する誤ったAuthentication Policyの適用
当初Jamf ProとJamf ConnectについてもDevice Trustのポリシーを適用していましたが、Jamf Proは自動デバイス登録（ADE）時に、Jamf ConnectはOSログイン前にOktaへ認証を行います。いずれの場合もこの段階ではOkta FastPass（デスクトップ版Okta Verify）が利用できずDeviceの状態を確認できないため認証を行うことができませんでした。
対応としてはJamf関連専用のAuthentication Policyを作成し、以下のようなRuleを作成しDeviceの状態を問わないこととしました。このPolicyに対してJamf関連のSPを紐づけました。
Office 365(Azure AD)に対して専用Authentication Policyの作成
Office 365（Azure AD）とフェデレーション設定をすると専用のAuthentication Policyが作成されます。このPolicy内のRuleではClientという条件を指定することができます。Device Trustを行う通常の認証を想定したRuleではClientという条件ではWeb browser, Modern Authenticationのみを指定し、AutopilotやAzure AD Joinを想定したRuleではClientという条件はWindows AutoPilotのみを指定しました。
また、Policy全体を通してClientにExchange ActiveSync/Legacy Authを選択しないことでレガシー認証を排除することが可能となりました。
Office 365（Azure AD）へのPush Groupsの挙動による影響
Classic環境ではOktaからPush Groupsを行いAzure AD側でそのグループに対してIntuneから設定を展開するようにしていました。
OIE環境でも同じ名前のグループを作成しておき同じようにPush Groupsにて設定を行うとAzure AD側の同名の既存グループとリンクされるものとばかり思い込んでいました。
実際に起きた事象はAzure AD上にはまったく同じ名前のグループが作成されていました。オブジェクトIDが異なるためClassic環境に紐づくグループを特定し、そのグループに対して設定されているAzure ADやIntuneのポリシーや構成プロファイルを参考にOIE環境に紐づくグループにも同様の設定としました。その後、Classic環境からPush Groupsの設定を削除するという方法で解消しました。
Chrome Browserの初回サインインが行えない
弊社の場合、Chromeの拡張機能やポリシー管理のためにManaged Chrome Browserを利用しています。また、Google Workspaceに対してDevice TrustのPolicyを有効な状態にもしています。
この状況で新入社員が端末セットアップ時にChrome Browserをまずデフォルトブラウザとして設定し、セットアップを行う手順としていました。しかしこの手順ではまず最初にChromeのプロファイルを作成する必要があり、その過程でGoogle Workspaceログインを行う必要があります。
これまで案内していた手順ではOkta FastPass（デスクトップ版Okta Verify）のセットアップを行う際のブラウザ認証がChrome Browserでは利用できないため、結果としてDeviceの状態が確認できない状態となりました。
この問題については案内する手順の見直しを行い最初にSafariやEdgeなどの別ブラウザでOkta FastPass（デスクトップ版Okta Verify）をセットアップを行いDeviceの状態が確認できる状態となってからChrome Browserのセットアップを行なっていただくように変更することで対応を行いました。
Google Workspaceで意図せずPasswordリセットが発生した
これはSP移行のタイミングではないのですが移行のタイミングでも起こり得る内容です。
移行の計画のために現在の設定を確認していました。その時にプロビジョニングエラーが発生しているユーザーが数名いたためエラーを取り除く作業を実施しました。
エラーの内容と対処方法は下記のブログの内容とまったく一緒でプロビジョニング設定を行う前にアサインしていたユーザーがプロビジョニング対象外であったというエラーでした。
弊社のClassic環境のGoogle Workspaceのプロビジョニングの設定では、Sync PasswordがSync a randomly generated passwordとなっていたことが盲点でした。プロビジョニングエラーを解消したことでそれらのユーザーに対してSync a randomly generated passwordが実行され、新たなにランダムなパスワードが生成されGoogle Workspsace側に反映された結果パスワードリセットと同様の挙動となりました。
今回パスワードリセットされたユーザーの中にはGoogle Workspaceの特権管理者もいたため、他の特権管理者の助けを借りて一時パスワードの発行を行い再設定を行なってもらいました。
これが移行のタイミングでOIE環境でもClassic環境と同じSync Passwordとしていた場合は全てのユーザーに対して同じ挙動になっていたはずです。今回のことを受けてチーム内で話し合いを行いOIE環境ではSync Passwordは行わない方針としました。
まとめ
OIE環境への移行ではDevice Trustの全体適用のためにかなりの神経を使い計画しました。それでもJamfの挙動など想定が足りずに一時的にユーザーに不便を強いることになった点があることは否めません。
今回、全体を通して検証レベルではなく本番運用の難しさと醍醐味をひさびさに感じることができました。もちろん意図しない挙動が起きるたびにドキドキもしましたが、SP単位で見たSSO設定やプロビジョニング設定以上にIdPの載せ替えを経験できたのは良かったと思います。この経験を通してお客様に対してより説得力のある言葉でご案内ができるようになったのではないかと思います。
