はじめに
1年半くらい前になりますがそれまでオンプレのActive DirectoryからOkta含む各種サービスにユーザーを同期していたものを、Oktaから同期するように変更しました。
その時どんなことやったかなどを簡単に記載できればと思います。
当時の構成
Windows Server上に構築した Active Directory から図に記載のツールを使用してユーザーを同期していました。
変更後の構成
ADやLDAPにはOktaのエージェントを使用し、SaaSに対してはSCIMでプロビジョニングしています。
移行による一般ユーザーへの影響
基本的には裏側の同期の仕組みの変更になりますが、どうしても1つだけ一般スタッフに対応してもらわないといけないことがありました。
それはOktaでのパスワード設定です。
AD->Oktaへの同期ではAD Agentを利用しており、かつDelegated Authenticationを有効にしていました。
この構成の場合 AD -> Oktaにはパスワードが同期されないため、Oktaではユーザーのパスワードを保持していない状態になっています。
そのため、すべての移行が完了した後、すべての一般ユーザーにはパスワードを再登録してもらう必要がありました。
移行によるシステム担当者への影響
準備と影響の関係でLDAPのプロバイダサーバーを新規で構築しなおしました。
そのため、各LDAPコンシューマを管理しているシステムの担当者にはLDAPの再起動をしてもらう必要がありました。
切り替え当日までの準備
各種切り替えに向けて当日までに以下のようなことをしました。
（検証とかは別でやってます）
- 新規LDAPサーバーの構築及びAgentインストール
- OktaユーザープロファイルにAttributeを追加及び値設定
- OktaがソースとなることでAttributeやグループルールを使っていろいろできそうだったので追加しました。
- ADのOU構成変更
- 変更するならこのタイミングしかない！ということで変えました。
- その他スタッフへの案内など
切り替え当日
- AD -> LDAP 同期の停止
- Azure Active Directory Connect の停止
- Google Cloiud Directory Sync の停止
- AD -> Okta へのインポートの停止
- Delegated Authentication の無効化もこのタイミングでした。
- この時点でOktaにはパスワードが存在しないため、ユーザーは誰もOktaにログインすることができなくなります。
- Okta -> AD へのプロビジョニングの開始
- Okta -> Google Workspace へのプロビジョニング設定
- Okta -> Microsoft Entra ID へのプロビジョニング設定
- Okta -> LDAP へのプロビジョニング開始
- APIを使用してユーザーの初期パスワードを指定＆パスワードを期限切れに設定
- 初期パスワードを期限切れにすることで、ユーザーが翌日ログインした際に必ず自分のパスワードを設定させるようにしています。
- プロビジョニング設定のうちSync passswordを有効化
- LDAPプロバイダのDNS設定変更
- 新規構築しているためコンシューマが参照する先のLDAPプロバイダをDNSで切り替えました。
切り替え翌日
- 一般ユーザーによる初回ログイン＆パスワード設定
- システム管理者によるLDAPの再起動
ディレクトリ同期の切り替えについて
裏側の仕組みのため一般ユーザーからはほぼ見えない部分です。
しかし、同期の切り替えの順番を間違えるとパスワードが正しく同期されなかったり、ユーザーがログインできなくなってしまうなど業務に直結する影響が発生する可能性があります。
そのため、切り替えの計画では、
- どのタイミングでどの切り替えを実施すべきか
- その時、誰がどこにどのパスワードでログインすることができるのか
といったことにとても注意しました。
その甲斐があってか、本番切替では特段想定外の影響もなく完了することができました。
さいごに
今回ざっくりとこんなことをしたという内容を記載しました。
もし機会があればもう少し詳しめに記載できたらなと思います。
また、今回アドベントカレンダーでOktaに関するいろいろなことを記載してきました。
記載する中で改めて、自身の理解が足りていない部分が見つかったり、試したい機能が見つかったりと新しい発見がありました。
数年間のOktaの管理者としての経験を振り返るよい機会だったと思います。
ここまで記事をお読みいただいた皆様ありがとうございました。