Acticve Directory → Okta WIC ID連携（ID同期）ナレッジ（前編）

はじめに 

本「Okta WICナレッジ」ブログは、弊社テクバンが提供する「Okta導入支援サービス」の担当エンジニアが、実務を通して得たOkta Workforce Identity Cloudについてのナレッジを共有するものになります。 

今回初回の投稿になりますが、今後随時投稿を追加していけたらと考えております。 

今回は、前編と後編に分けて、Active Directory（以降「AD」と記述を省略させて頂きます）からOkta Work Identity Cloud（以降「Okta」と記述を省略させて頂きます）へのID同期（「ディレクトリ統合」）について、これまで実務で実装およびテストを実施して得たナレッジを記載したいと思います。 

AD⇒Oktaの「ディレクトリ統合」 

IDaaS Oktaは、企業で使用するシステム群のIDを統合管理するわけですが、従業員のIDを、Okta上で作成する運用とは別に、企業の既存のActive DirectoryやLDAPサーバーから取り込むことも可能です。 

Oktaでは、このような外部ディレクトリのIDをOktaに取り込む構成とすることを「ディレクトリ統合」（Directory integration）と言います。 

ADとのディレクトリ統合についてのOktaの公式ドキュメントページは以下となります。 

https://help.okta.com/oie/ja-jp/content/topics/directory/ad-agent-main.htm

なお、ADのディレクトリ統合は、以下のようにドメイン参加しているAD AgentサーバーがADとOktaの同期を仲介する構成になります。 

AD Agent サーバーを複数台立てることにより自動的にActive-Activeの冗長構成となります。重要な役割を果たすサーバーであるため、エージェントサーバーは冗長構成にすることが推奨されます。

Oktaの公式ドキュメントには「ホストサーバー（ブログ著者補記：AD Agentサーバーのことだと思います）は、ADドメインのメンバーサーバーまたはドメインコントローラーのどちらでもかまいません。メンバーサーバーの使用を推奨します。」との記述があります。 

また、Oktaの「委任認証」の機能を使用すると、ADから同期されたOktaユーザーの認証をADに委任することができ、ユーザーはADとOktaに同一のAD側パスワードでログインすることが可能 です。

関連ナレッジ 

以降、AD→Oktaディレクトリ統合について、実務を通して得たナレッジのメモとなります。

環境構築関連 

構築手順の公式ドキュメントのリンク 

https://help.okta.com/oie/ja-jp/content/topics/directory/ad-agent-workflow.htm

やるべきことは主に 以下

• ADエージェントサーバーへのエージェントソフトのインストール 
• Okta管理コンソール上でのAD→Oktaのインポート関連設定 

（単純にAD→Oktaのアカウント同期のみが実施したいのみで、逆のOkta→ADのプロビジョニングを実施したいという要件がなければ、Okta→ADのプロビジョニング設定は不要 ）

AD Agentサーバーの通信要件としては、アウトバウンドのHTTPS通信が許可されていれば問題なし。プロキシ経由の通信でもOK（エージェントインストール時にプロキシーサーバーを指定できる）。許可するアウトバウンドのHTTPS通信の通信先を制限したい場合、明示的に許可が必要な通信先については以下情報を参考にできる。 

https://help.okta.com/oie/ja-jp/content/topics/security/ip-address-allow-listing.htm

設計時に重要となる考慮ポイント は、ADから同期するアカウントについて、Okta上のアカウント名の形式をどうするか。必ずしもAD上のユーザー名を Oktaのユーザーアカウント名とする必要はなく、AD上のアカウントの属性値を元にOktaのアカウント名を設定することも可能。例えば、AD上に登録されているユーザーのメールアドレスの値を、Okta上のアカウント名にするなど。

AD上の同期対象とする、ユーザーおよびグループの指定 

AD上のどのユーザー、どのグループをOktaへの同期対象とするかについては、以下の設定画面でOU単位で設定が可能。

ADからOktaへ同期するユーザーの属性の設定 

AD上のユーザーのどの属性情報をOktaへ連携しOkta上のアカウントの属性にどうマッピングするかについて設定が可能。以下が設定画面。

同期タイミング/頻度の設定 

AD→OktaのID同期（インポート）タイミングは、時間毎のサイクル設定とJIT（ジャストインタイム）プロビジョニングがある。

時間毎のサイクル設定は、最も高頻度の設定で1時間サイクル。

JITプロビジョニングは、ユーザーがOktaにログインしたタイミングでOktaがADを照会しAD上に該当ユーザーがあればそのユーザーを同期する動作（Okta上に該当アカウントが存在しない場合はそのタイミングで新規作成される）。JITプロビジョニングを有効にするには、ADへの委任認証の設定が前提。前述時間毎の同期設定と併用化。

プロビジョニングの動作 

AD→Oktaの同期において、AD上のアカウントに対して行った操作がどのようにOktaに同期されるかについては下表。

AD上のユーザー操作	Okta側への同期結果
新規作成	Okta上に該当ユーザーが存在しない場合はユーザー作成（設定によっては、作成に管理者の確定操作を必要とすることも可能、また新規ユーザーのアクティベーションまでを自動的に行うかどうかについても設定で選択可能） Okta上に該当ユーザーが既に存在する場合はADユーザーとの紐づけ
属性変更	同期対象の属性の値が変更された場合は、Okta上のユーザーの属性が変更される
無効化	Okta上のユーザーがの非アクティブ化
削除	同期されない
パスワード変更	同期されない
ロック	Okta上のステータス自体は同期されない（「アクティブ」のまま）が、該当ユーザーでOktaログインは不可となりロック解除の画面に遷移する
グループへの参加/離脱	対象グループがOkta上に同期されている場合はOkta上でも参加/離脱

AD→Oktaの同期において同ユーザーと識別する一意のキーになる属性値を、同期後に変更することは問題ない。例えば、AD上のユーザーのメールアドレスの値をOktaのユーザー名として同期した場合、該当ユーザーのAD→Oktaの同期紐づけが完了した後であれば、AD上でメールアドレスの変更を行ってもユーザーの紐づけが壊れるということはなく、問題なくOkta上のユーザー名が変更がされる形で同期される（AD上でメールアドレスを削除した場合は、Okta上のユーザー名がブランクになるということはないが、エラーになることもない）。

ネストしたグループの同期 

Oktaではグループはネストできない（グループの中にグループを参加させることができない）。AD上ネスト構造のグループは、以下のイメージ図のようにフラットな状態でOktaへ同期される。

配布グループの同期 

AD上の「配布グループ」も通常のセキュリティグループと同様にOktaと同期可能。

AD→Oktaのディレクトリ統合と、Okta→Microsoft 365のプロビジョニングでそれぞれグループの同期を実施したところ、ADからOktaに同期されたセキュリティグループはセキュリティグループとして、配布グループは配布グループとして、それぞれOktaからMicrosoft 365へ同期された。一見したところOktaの管理画面上では区別はつかないのだが、そのグループがセキュリティグループなのか配布グループなのかという情報をちゃんとOkta側で保持しているようである。

後編に続く

ADとOktaのディレクトリ統合ナレッジの前編はいったん以上となります。後編に続きます。