本コンテンツは作成・公開当時（2021年）の情報に基づいており、情報が古くなっている可能性があります。ご利用の際は、必ずご自身の責任で最新の情報をご確認ください。当コンテンツの利用により生じた損害等について、当サイトは一切の責任を負いません。
Active Directoryエージェント
オンプレミスサービスの中でも、アイデンティティ関連のアクティビティを管理するものとして主要になったActive Directory (AD)。クラウドサービスやクラウドアプリへの需要の高まりとともに、ADがクラウド中心の世界や現在のユースケース向けに構築されていないことに気づき始めた組織も出てきました。
将来を見据えているIT組織は、従来のAD環境をOktaやOkta Identity Cloudが提供する最新のシングルサインオン (SSO) と統合することで、従業員が利用するあらゆるサービスやリソースに、簡単で安全に接続するゲートウェイを提供できるようになります。本書では、ADをOktaに統合することによる機能面や運用面での技術的なポイントを紹介します。
本書では、ADをOktaに統合することによる機能面や運用面での技術的なポイントを紹介します。
課題
クラウドサービスやアプリなどのアイデンティティ管理が煩雑化 クラウドサービスやアプリのアイデンティティがADに一元化されていないため、アイデンティティ管理が煩雑化
アプリやサービスのインストールに手間がかかる ADのドメイン権限に制約され、円滑にアプリやサービスをインストールすることができない
アプリやサービスへのアクセスのプロビジョニングにかかる管理コストの増大 サービスに対するアクセスのプロビジョニングを手作業で行っているなど、管理や保守などにかかるコストが増大
メリット
シームレス、簡単、安全なアクセスの提供 ポリシーの一元化や、適応型多要素認証(AMFA)、パスワードレス認証などを用いた、シームレスかつ簡単で安全なアクセスが提供可能
最新のアプリやサービスを柔軟に追加可能 ADエージェントにより、OktaとADインスタンスの間にインターフェースが提供されるため、あらゆるアプリをスムーズにOktaに追加し、利用が可能
ADとOktaの統合による管理コストの大幅削減 一元化されたアイデンティティアクセス管理とシングルログインインターフェースにより、あらゆるアプリやサービスにアクセス可能となり、保守などにかかるコストを大幅に削減可能
Okta Active Directoryエージェント
ADとOktaの統合において、重要な役割を果たすのがOkta ADエージェントです。ADエージェントは、OktaとローカルADインスタンスの間にインターフェースを提供します。
OktaとADエージェントは高い拡張性をもって設計されているため、必要に応じてユーザを追加したり、エージェントを追加したりすることが容易に実現できます。
ADエージェントは安全なアウトバウンド通信を採用しており、ロングポーリング（クライアントとサーバの通信手段の1つで、接続を維持したままサーバのレスポンスを待つ通信手段を指す ）を通じて負荷分散とジョブ管理を行い、長期保存可能な認可リフレッシュトークンを使用します。
ADエージェントは、ADドメインに参加しているローカルメンバーサーバ上にインストールする必要があります。
ドメインコントローラーに悪影響を及ぼすため、ドメインコントローラー上にインストールを行うことは避ける必要があります。
ADエージェントの統合機能
ADエージェントは、主に2つの機能を提供しています。1つ目が認証の委任です。認証を委任することで、オンプレミスのADインスタンスが認証ソースとして機能し続けます。また、認証を委任すると、すべてのパスワードがADに残るため、ユーザがOktaにアクセス可能かどうかをADが判断します。さらに、ユーザが、Oktaを介してリソースにアクセスしようとすると、その認証リクエストをOktaがオンプレミスのADに転送します。ADで認証されるとADがOktaへのアクセスを許可し、ユーザがOktaおよび割り当てられたリソースにアクセスできるようになります。
2つ目は、ADからOktaにユーザとグループに関連する属性のインポートです。インポートの過程では、指定したAD組織ユニット (OU) (*2)に存在するユーザオブジェクトごとに、新たなユーザオブジェクトがOktaに作成されます。その後、OktaはADユーザとOktaユーザを各々リンクさせることで、ADに保存されたユーザオブジェクトに影響を与えることなく、ユニバーサルディレクトリに保存されたオブジェクトのユーザ属性を修正したり、拡張したりすることができます。また、ユーザをOktaに移行することで、Oktaの機能セットを活用できるようになります。これにより、オンプレミス、クラウドにかかわらず、ユーザが必要とするあらゆるリソースに対して一元化されたSSO機能を提供できます。
*2 OU: Organizational Unitの略称。権限や設定ごとのアカウントやリソースの集合を指す。
*3 アクティブ/アクティブ構成:同一のシステムを複数稼働させ、耐障害性を高めるシステム構成。
アクティブ/アクティブ構成とロングポーリング
Oktaでは、アクティブ/アクティブ構成 (*3) でプライマリ、セカンダリの概念なしでADエージェントを配置することができます。したがって、積極的にADエージェントの負荷分散をする必要はありません。 配置されたすべてのエージェントは常にアクティブで、容量が許す限り、ロングポーリングを使用して新しいジョブを探します。 つまり、エージェントからのリクエストを待つという、従来のクライアントとサーバという関係ではなく、絶えずジョブを探し、ADエージェントが可能な限り素早くそれを取り込む仕組みです。ジョブはただちに取り込まれるため、待機時間が削減され、従来のモデルよりも速く処理されます。
ADエージェントの接続
OktaのADエージェントは、証明書のピンニング（特定のWebサイトで有効な証明書を限定し、証明書の誤発行などのリスクを低減すること ）をして、Okta Identity Cloud向けのアウトバウンドのHTTPS接続を作成します。
接続時間は30秒までです。
この接続時間中に、AD認証イベントなど、Oktaサービスからのイベントを待ちます。
イベントが発生した場合、ADエージェントは処理を行い、接続を終了し、ただちに新しい接続を開いて新しいジョブがないかを待ちます。
30秒の接続ウィンドウ中にイベントが発生しない場合、エージェントは一度接続を終了し、新たに30秒のウィンドウで接続を開始してジョブの探索が始まります。
ADエージェントのジョブ管理
認証ジョブは頻繁に発生し、速やかに処理する必要があるのに対し、インポートジョブは、時間を要する大規模なジョブであるため、Oktaはジョブタイプに応じた負荷分散の方法を採用しています。これにより、ジョブごとの特性に合わせた処理が可能になります。例えば、認証ジョブの処理は、利用可能なすべてのADエージェントで処理が可能なため、プールからランダムにADエージェントが選択されます。
一方、インポートジョブには優先エージェントが使用されます。最初のADエージェントの割り当てはランダムですが、Oktaは対応不可または利用不可になるまで、後続のタスクで同一のADエージェントを使い続けます。そして、ADエージェントが利用不可となった時点で、別のADエージェントが割り当てられます。
デフォルトでは、Oktaは各ADエージェントを2つのスレッドで構成しています。ただし、ADエージェントの要求に対処するために、最大10のスレッドでの構成が可能です。例えば、通常は1番目のスレッドが常に利用可能な状態で待機していますが、インポートジョブを受けると、Oktaはそのジョブが完了するまで1番目のエージェントに追加のジョブを送信せず、2番目のスレッドが認証ジョブを受けられる状態を保ちます。
実行中の認証ジョブの例
1）ジョブスレッドは30秒間オープンな状態を保持
2）エージェントはHTTP GETを実行してOktaからジョブを取得
3）エージェントはOktaから認証ジョブを受信
4）エージェントは認証ジョブを実行
実行中のインポートジョブの例
1）ジョブスレッドは30秒間オープンな状態を保持
2）エージェントはHTTP GETを実行してOktaからジョブを取得
3）エージェントはOktaからインポートジョブを受信
4）エージェントはインポートジョブを実行
5）エージェントはインポートジョブの優先エージェントになる
ADとOktaの統合計画
統合・構築する際に重要となるのが、ユーザ認証機能とユーザインポートの違いを理解することです。例えば、これらの2つのジョブタイプの頻度やユーザベースは、ADとOktaとの統合にさまざまな影響を与えます。また、ユーザベースが各ジョブタイプをいつ実行するかを理解することも重要ですし、ユーザベースのサイズを知ることも重要です。以下では、それぞれのジョブタイプの動作の違いなど、統合の計画や構築に必要な各ジョブタイプの詳細を解説します。
ユーザ認証ジョブ
ユーザがOktaユーザインタフェースにクレデンシャル (*6) を入力して認証する際、OktaはADマスターユーザかどうかを判断します。 ADマスターユーザであった場合、Oktaはユーザのディレクトリインスタンスに関連するジョブリストに認証リクエストを追加します。認証ジョブがジョブリストに追加されると、Oktaはポーリングしている利用可能な任意のADエージェントにジョブを割り当て、割り当てられたエージェントはエージェントが実行されているサーバでジョブを開きます。 次にADエージェントは、ユーザプリンシパル名 (UPN)などのAD統合設定で指定されたユーザ名フォーマットを使用して、ユーザルックアップを実施します。ADエージェントがユーザを見つけると、ユーザが入力したクレデンシャルを使用して、ADインスタンスとのBIND (*7) を実行します。以下は、ADエージェントがユーザを探すときに使うUPNクエリの例です。
(&(sAMAccountType=805306368)(userPrincipalName=user@domain.com))
ユーザインポートと比較すると、ユーザ認証ジョブは速やかに実行されます。統合の設定を完了すると、ADエージェントは大量の認証を開始することができます。また、必要に応じて、複数の追加エージェントを配置し、認証用にさらにリソースを割り当てることができます。 認証に追加エージェントを配置するメリットの1つは、季節ごとのニーズに対応できることです。例えば小売業では、夏季や冬季の休暇シーズンには処理の量が急増することが想定されます。
また、グローバル企業では、多くの場合、各国の拠点の近くに追加のADエージェントが配置されます。このとき、ADエージェントをドメインコントローラーまたはドメインコントローラープールの近くのメンバーサーバに配置すれば、認証中の待ち時間を減らすことができます。
前述の通り、ADエージェントはドメインコントローラーではなく専用のメンバーサーバに配置する必要があります。
*6 クレデンシャル：パスワードなど、認証に用いられる情報の総称。
*7 BIND：Berkeley Internet Name Domainの略称で、DNSサーバのプログラム。
ユーザインポートジョブ
ユーザインポートは、スケジュールされたインポート、または手動でのインポートのどちらでも実行可能です。どちらの手法で実行してもOkta内にジョブが作成され、優先エージェントに割り当てられます。認証ジョブと同様に、ADエージェントはOktaに働きかけてジョブを取り出し、それを実行中のローカルサーバで開きます。ADエージェントは、最初にAD構造全体のトポロジーを読み込み、次にユーザとグループを更新しますが、差分インポートの場合は、各オブジェクト向けに読み込んだusnChanged AD属性値に基づいてインポートを実行します。読み込むオブジェクトの範囲は、OktaテナントのAD統合で設定したADエージェントのインポート設定に基づきます。
以下はインポートジョブのクエリの例です。
トポロジー読込:
((objectCategory=organizational Unit) (&(objectCategory=container) (!showinAdvanced View Only TRUE)))
ユーザアカウント読込:
(&(sAMAccountType=805306368) (uSNChanged>=889511) (uSNChanged<=889547))
一度サーバがインポートを実行すると、そのサーバが優先インポートサーバになることに注意が必要です。つまり、後続のインポートジョブが同じサーバに送られることになるため、複数のサーバにADエージェントを配置しても、インポートジョブがそれらすべてのサーバに拡散されることはありません。インポートジョブは現在の優先サーバのみで実行されます。
また、インポートの速度はディレクトリのサイズ、インポート対象、および頻度によって変化します。例えば、前回のインポートから全ユーザで更新がある数百万のユーザが存在する10,000 OUを含むインポート対象は、更新のないユーザを含む5,000 OUのインポートより時間がかかることになります。 ※Microsoft ADのusnChanged属性に関する詳細は、docs.microsoft.com/en-us/windows/win32/adschema/a-usnchanged をご参照ください。
リアルタイム同期ジョブ
ユーザ認証とユーザインポートに加えて、Okta ADエージェントは、ジャストインタイム (JIT) 更新が有効な場合にリアルタイム同期ジョブを実行します。リアルタイム同期ジョブは、ログイン時にユーザ属性、グループメンバーシップを更新し、Oktaに新しいグループを作成します。これを行うため、ADエージェントはランダムに選択したADサーバにBINDを実行します。BINDが正常に終了すると、サーバはカレントユーザ (*8) が属するグループセキュリティID (SID) のリストを含むセキュリティートークンを受信します。ADエージェントはこのトークンからSIDを取り出し、そのSIDを使用してローカルSIDキャッシュから当該グループを探索し、Oktaにそのメンバーシップ情報を送信することで、Oktaがユーザをグループに追加できるようにします。SIDがローカルキャッシュに存在しない場合、エージェントはAD内を探索します。
*8 カレントユーザ: 現在サインインしているユーザのこと。
ADエージェントのインストールとトラブルシューティング
ADとOktaの統合に向けたADエージェントのインストールに関する詳しい要件、手順、およびタスクについては、「help.okta.com/en/prod/Content/Topics/Directory/ad-agent-install.htm」をご参照ください。トラブルシューティングをサポートするため、OktaはADエージェントのログとADエージェントが実行するWindowsイベントビューワーアクションを記録しています。ADエージェントのログは「C:\Program Files (x86)\Okta Okta AD Agent\log」とWindowsのイベントビューワーに格納されています。さらにログ情報を希望される場合は、verboseログを有効化できます。詳細については、「support.okta.com/help/s/question/0D50Z00008G7UppSAF/how-can-i-enabled-verbose-logging-in-my-ad-agent」をご参照ください。 ADエージェントはHTTPSを介してOktaと通信するため、そのトラフィックはFiddlerなどのWebモニタリングツールで確認できます。 Fiddlerの設定に関する詳細は、「support.okta.com/help/s/article/Capturing-A-Fiddler-Trace-For-Okta-Customer-Support」をご参照ください。
統合の効果
ADエージェントを使ってADとOktaを統合することで、モバイルアプリ、SaaSアプリ、およびオンプレミスアプリを含む最新のアプリを十分に活用できるようになります。これらのアプリをOktaに追加すれば、ADユーザのアクセスは自動的に認証可能になります。また、一元管理されたポリシー、適応型多要素認証(AMFA)、およびパスワードレス認証などにより、アプリへの安全なアクセスも可能となります。さらに、Okta RADIUSエージェントとOkta LDAPインターフェースを活用することで、一部のOktaのセキュリティ機能を、Wi-FiルーターやVPNなどのローカルネットワーク機器にも拡張することができます。
一元化されたアイデンティティアクセス管理 (IAM) とシングルログインインターフェースを用いれば、すべてのアプリとサービスにユーザがアクセスできるようになります。これにより、管理費用の大幅削減、アプリのロールアウトの迅速化、シームレスで一貫したアクセスの提供などが可能となり、セキュリティ全体が強化されます。 ADはこれまでのIT環境において必要不可欠な機能であり、今後も価値を発揮し続けることに間違いありません。しかし、最新のIAMとOktaがもたらす多くの利点を活用するにつれて、ADの役割に対する見方が変わるかもしれません。Oktaは、増加するアプリとサービスに簡単かつ安全にアクセスするための扉を開いていきます。ベンダーニュートラルな特性と統合ネットワークを備えたOktaなら、どのようなテクノロジーにも接続でき、ビジネスイノベーションと成功に必要な柔軟性が得られます。 ADをOktaに統合してメリットを得る方法についての詳細は、「www.okta.com/rethinkad」をご参照ください。
