Active Directory統合に関するよくある質問

Oktaはユニバーサルセキュリティグループをどのように処理しますか？

ユニバーサルセキュリティグループ（USG）の詳細については、「セキュリティグループ」を参照してください。

変数

  • ユーザーとUSGがsame（同じ）ADドメインに存在するか、different（異なる）ADドメインに存在するか。
  • different（異なる）ドメインの場合、両方のドメインがOktaに存在し、信頼関係で接続されているかどうか。
  • ユーザーがサインイン（JIT）またはインポートによってOktaに追加されるかどうか。

前提

  • ［JIT Provisioning（JITプロビジョニング）］オプションと［USG Suppor（USGのサポート）］オプションが［Import（インポート）］および［Account（アカウント）］設定で選択されています。
  • ［Schedule import（インポートのスケジュールを設定）］オプションが選択されている場合、［Do not import new Users（新規ユーザーをインポートしない）］オプションは選択されていません。

Oktaは複数ドメインのメンバーが含まれるドメインローカルグループをサポートしません。ドメイン間で双方向の信頼が確立されている場合、クロスドメインメンバーシップを持つUSGがサポートされます。USGは、フォレスト間のメンバーシップをサポートしません。

サインイン（JIT）のシナリオ

Oktaにまだ存在しないUSGのメンバーであるユーザーがOktaにサインインする

  • ユーザーとUSGがsame（同じ）ドメインに属していても、USGがOktaに存在しない場合、Oktaは、Oktaでユーザーのプロファイルを作成または更新し、USGを取り込み、ユーザーのメンバーシップをUSGに同期します。
  • ユーザーとUSGがdifferent（異なる）ドメインに属し、両方のドメインがOktaに存在するが、USGがOktaに存在しない場合、Oktaは、Oktaでユーザーのプロファイルを作成または更新しますが、USGをOktaに取り込みません。

Oktaに存在するUSGのメンバーであるユーザーがOktaにサインインする

  • ユーザーとUSGがsame（同じ）ドメインに属し、USGがOktaに存在する場合、Oktaは、Oktaでユーザーのプロファイルを作成または更新し、ユーザーのメンバーシップをUSGに同期します。
  • ユーザーとUSGがdifferent（異なる）ドメインに属し、USGがOktaに存在する場合、2つのドメインが信頼関係によって接続されている場合にのみ、Oktaはサインイン時にユーザーのメンバーシップをUSGに同期します。ドメインに信頼関係がない場合、OktaはUSGのユーザーのメンバーシップを認識しません。

インポートのシナリオ

グループやユーザーのインポート中には何が起きますか？

  • ユーザーとUSGがsame（同じ）ドメインのメンバーである場合、Oktaは、Oktaでユーザーのプロファイルを作成または更新し、USGがOktaに存在しない場合は作成し、インポートされるドメイン内のユーザーについてのみUSGにメンバーシップを同期します。ほかのドメインからは何もインポートされません。インポート中、OktaはほかのドメインのUSGのメンバーシップを認識しません。
  • インポートされるドメインのユーザーがdifferent（異なる）ドメインに存在するUSGのメンバーである場合、Oktaはユーザーのみをインポートし、USGのメンバーシップを無視します。USGを含むドメインが後でインポートされた場合、Oktaは、グループメンバーが次回Oktaにサインインするときにメンバーシップを同期します。

例：2つのドメイン間のUSG

ドメインBに存在し、ドメインAおよびドメインBのユーザーを含むUSGがあるとします。

ドメインAがOktaにインポートされた場合、USGのどのメンバーがOktaにインポートされますか？

ドメインAのユーザーのみがOktaにインポートされ、USGのメンバーシップは、後でドメインBがインポートされるまで無視されます。

ドメインAがOktaに存在する場合、ドメインBをインポートするとUSGがOktaに取り込まれ、2つのグループメンバーシップがUSGに同期されますか？

はい。

例：3つのドメイン間のUSG

3つのドメインのフォレスト内にあり、ドメインAに存在し、ドメインA、B、Cのユーザーが含まれているUSGがあるとします。

ドメインAのユーザーおよびグループがOktaにインポートされると、USGがインポートされ、ドメインAのUSGユーザーメンバーシップが同期されます。

ドメインBおよびドメインCのユーザーとグループがOktaにインポートされた場合、それらのドメインのユーザーが初めてOktaにサインインするまで、これらのドメインのUSGメンバーシップは同期されません（図の点線を参照）。

配布グループはいつOktaに組み込まれますか？

配布グループは、ジャストインタイム（JIT）プロビジョニング中ではなく、増分インポートおよびフルインポート中にOktaに取り込まれます。

ユーザーがサインインしてJITプロビジョニングフローが有効な場合、Oktaはセキュリティグループのメンバーシップをインポートしますが、配布グループはインポートしません。JITプロビジョニングでは、ユーザーアカウントの配布グループのメンバーシップは同期されません。ユーザーが子配布グループのメンバーである場合、親セキュリティグループのメンバーシップを継承しません。配布グループのメンバーシップをADからOktaに定期的に更新するには、インポートをスケジュールします。

Oktaでは配布グループのメンバーシップはいつ同期されますか？

増分インポートおよびフルインポート中、およびインポートされるユーザーとグループが同じドメインに属する場合のみ。

ユーザーがサインインしてジャストインタイム（JIT）プロビジョニングフローが有効な場合、Oktaはセキュリティグループのメンバーシップをインポートしますが、配布グループはインポートしません。JITプロビジョニングでは、ユーザーアカウントの配布グループのメンバーシップは同期されません。ユーザーが子配布グループのメンバーである場合、親セキュリティグループのメンバーシップを継承しません。配布グループのメンバーシップをADからOktaに定期的に更新するには、インポートをスケジュールします。

［To Okta（Oktaへ）］ページのプロビジョニングオプションとして［Skip users during import（インポート中にユーザーをスキップ）］が選択されている場合、配布グループまたはユニバーサルセキュリティグループのグループメンバーシップはインポートされません。「Active Directoryのインポートとアカウントの設定を構成する」を参照してください。

Oktaは配布グループ（DG）とユニバーサル セキュリティ グループ（USG）を同じように扱いますか、それとも異なる方法で扱いますか？

Oktaは、次の点において、DGとUSGをsame（同じように）扱います。

インポート中、Oktaは、インポートされるドメインとは異なるドメインに存在するDGまたはUSGにグループメンバーシップを同期しません。

Oktaは、次の点において、DGとUSGをdifferently（異なる方法で）扱います。

  • ユーザーとそのユーザーがメンバーであるUSGが同じドメインに属している場合、Oktaはジャストインタイム（JIT）プロビジョニングおよびインポート中にユーザーをUSGに同期します
  • ユーザーとそのユーザーがメンバーであるDGが同じドメインに属している場合、Oktaはインポート中のみユーザーをDGに同期し、JIT中は同期しません。

ユーザーがサインインしてJITプロビジョニングフローが有効な場合、Oktaはセキュリティグループのメンバーシップをインポートしますが、配布グループはインポートしません。JITプロビジョニングでは、ユーザーアカウントの配布グループのメンバーシップは同期されません。ユーザーが子配布グループのメンバーである場合、親セキュリティグループのメンバーシップを継承しません。配布グループのメンバーシップをADからOktaに定期的に更新するには、インポートをスケジュールします。

［To Okta（Oktaへ）］ページのプロビジョニングオプションとして［Skip users during import（インポート中にユーザーをスキップ）］が選択されている場合、配布グループまたはユニバーサルセキュリティグループのグループメンバーシップはインポートされません。「Active Directoryのインポートとアカウントの設定を構成する」を参照してください。

スコープ外のOUに移動されたユーザーおよびグループはOktaでどのように処理されますか？

out-of-scope（スコープ外）の組織単位（OU）という用語は、関連するOUセレクターで、表示されないか選択されていないOUを指します。次の画像では、後者の例を黄色で強調表示しています。

一部のOrganizationは、ユーザーまたはグループをスコープ外のOUに移動することを含む、従業員のオフボーディングプロセスを管理しています。Oktaがスコープ外のOUにユーザーやグループをインポートすることはなく、そのようなすべてのユーザーへのサインインを拒否します。

サインイン（JIT）のシナリオ

Oktaは、Active Directoryでの有効化ステータスに関係なく、範囲外のOUのすべてのユーザーへのサインインを拒否します。

  • ADで有効になっているout-of-scope OU（スコープ外のOU）のユーザーがOktaにサインインしようとすると、OktaはユーザーのADステータスを検出し、Oktaでアクティブとして保持しますが、サインインの試行は拒否します。
  • ADで無効になっているout-of-scope OU（スコープ外のOU）のユーザーがOktaにサインインしようとすると、OktaはユーザーのADステータスを検出し、Oktaで非アクティブ化し、サインインの試行を拒否します。

インポートのシナリオ

Oktaは、増分インポートおよびフルインポートを実行します。

  • 増分インポート中、Oktaはout-of-scope OUs（スコープ外のOU）のユーザーとグループを検出しないため、これらのユーザーまたはグループはどれもインポートされません。

  • フルインポートまたは増分インポート中に範囲内のOUからインポートされ、後で範囲外のOUに再配置されたアカウントは、後続の増分インポート中に非アクティブ化されません。

  • フルインポート中に、Oktaはout-of-scope OU（スコープ外のOU）のユーザーを欠落として検出し、（ADでの有効化ステータスに関係なく）非アクティブ化し、次のサインインの試行を拒否します。

  • ADで削除されたOktaのADグループは、フルインポートのときにのみOktaから削除されます。

JITプロビジョニングは、OU外およびオブジェクトフィルタースコープ外のネストされたグループをどのように扱いますか？

「通常の」インポートとJITプロビジョニングの間でメンバーシップの不整合が生じる可能性があります。このようなメンバーシップの異常は、ネストされたグループを使用する場合に発生する可能性があります。

通常のインポート中、Oktaは、AD OUまたはLDAPオブジェクトフィルターのスコープ外の子グループを検出しません。親グループがOU/オブジェクトフィルターのスコープ内にあり、その子グループがスコープ内にない場合、Oktaはインポート中に親グループのメンバーシップを誤って解決します。

JITプロビジョニングの関数は「フラットな」メンバーシップのみを検出するため、JITプロビジョニングでは、このようなメンバーシップは親グループに正しく解決されます。

Okta AD Agent管理ユーティリティーにはどのような権限が必要ですか？

デフォルトの権限はドメイン管理者です。「Active Directory統合を開始する」を参照してください。

Oktaサービスアカウントを自分で作成できますか？

はい。インストールプロセスでアカウントを作成しない場合は、エージェントのインストール用に新規に作成するか既存のADサービスアカウントを使用できます。

Oktaサービスアカウントを別のOUに移動できますか？

はい。エージェントのインストール後にアカウントを移動できます。たとえば、サービスアカウント専用に予約されたOUへ移動できます。

Oktaサービスアカウントのパスワードを変更するにはどうすればよいですか？

Okta ADエージェントのインストールに使用したOktaサービスアカウントのパスワードを断続的に変更することをお勧めします。

パスワードを変更するには：

  1. Active Directoryで、［Active Directory Users and Computers（Active Directoryユーザーとコンピューター）］ツールを使用し、OktaServiceアカウントを探します。右クリックしてADのパスワードをリセットします。このアクションを実行するには、ドメイン管理者権限または十分に昇格した権限が必要になります。
  2. エージェントがインストールされているサーバーの［Services（サービス）］コンソールで、以下を実行します。
    1. Okta ADエージェントサービスを見つけて停止します。
    2. サービスを右クリックし、［Properties（プロパティ）］［Log on（ログオン）］タブを選択します。
    3. ADで設定したパスワードと一致するようにパスワードを変更します。
    4. サービスを開始します。

Okta IWA SSOエージェントもインストールし、Okta AD Agentのインストールに使用したものと同じOktaサービスアカウントを使用した場合は、［IIS Server Manager dashboard（IISサーバーマネージャーダッシュボード）］［Tools（ツール）］［Internet Information Services (IIS) Manager（インターネットインフォメーションサービス（IIS）マネージャー）］でOktaサービスアカウントのパスワードも変更する必要があります。Okta IWAサービスは、［Application Pools（アプリケーションプール）］メニューの下にインストールされます。［Advanced Settings（詳細設定）］で、Oktaサービスのパスワードを新しいパスワードに合わせて変更できます。キャッシュが原因で、IWAサービスがすぐに停止しない場合があります。キャッシュがリセットされたときに、［Active Directoryユーザーとコンピューター］ツールと［サービス］コンソールでリセットしたパスワードと一致するようにOktaサービスのパスワードがここで更新されていなければ、IWAは動作を停止します。

Okta管理者アカウントのパスワードを変更するにはどうすればよいですか？

Okta管理者アカウントのパスワードをリセットするには、次の2つのオプションがあります。

  • その管理者のユーザーIDとパスワードを使用してサインインします。エンドユーザーアカウントの［Settings（設定）］［Change Password（パスワード変更）］セクションに移動します。
  • スーパー管理者としてサインインしているときに、［Admin（管理者）］［Directory（ディレクトリ）］［People（ユーザー）］admin account name（管理者アカウント名）［Reset Password（パスワードをリセット）］に移動します。次に、パスワードリセット用メールを送信するか、一時パスワードを作成するかを選択します。

エージェントのファイアウォールを開く必要がありますか？

Okta AD Agentはアウトバウンドのみです。インバウンドエージェントのトラフィックに対してファイアーウォールを設定する必要はありません。

どのエージェントがトラフィックを受信するかを制御できますか？

いいえ。すべてのアクティブなエージェントがトラフィックを受信します。エージェントがトラフィックを受信するかどうかを制御する唯一の方法は、エージェントをオフにすることです。障害が発生した場合にのみバックアップデータセンターに送られるようにエージェントのトラフィックを調整することはできません。

インポートのタイミングをスケジュールできますか？

インポートの特定の時刻をスケジュールすることはできません。インポートの頻度はスケジュールできます。インポートの頻度をスケジュールするには、［Directory（ディレクトリ）］［Directory Integrations（ディレクトリ統合）］に移動してAD統合を選択します。［Settings（設定）］タブで、［Import and Provisioning（インポートとプロビジョニング）］までスクロールし、［Schedule Import（インポートのスケジュールを設定）］オプションでインポート間隔を選択します。手動でインポートする場合は、［Import（インポート）］タブを選択し、［Import Now（今すぐインポート）］をクリックします

エージェントのインストールを自動化する方法はありますか？

エージェントのインストールを自動化する手段はありません。

エージェントのより詳細なデバッグをオンにするにはどうすればよいですか？

ログは、問題をトラブルシューティングするときに非常に重要なリソースになることがあります。トラブルシューティングの目的で詳細ログを有効にできます。

多数の大きなファイルが継続的に生成されるのを防ぐため、トラブルシューティングが終了したら詳細なログ記録を無効にすることをお勧めします。

  1. 影響を受けるADエージェントを実行しているシステムで、ADエージェントのインストールディレクトリに移動します。デフォルトでは、これはC:\Program Files (x86)\Okta\Okta AD Agentです。
  2. OktaAgentService.exe.configファイルをテキストエディターで開きます。

    <add key="VerboseLogging" value="False" />を<add key="VerboseLogging" value="True" />に変更します。

  3. 変更をファイルに保存します。
  4. ADエージェントサービスを再起動します。

エージェントではどのレベルのパフォーマンス調整を実行できますか？

多くのリクエストを処理するために追加のADエージェントをインストールする必要はありません。ポーリングに使用されるスレッドの数を増やすと、既存のOkta AD Agentがより多くのリクエストを処理できるようになります。

  1. Windowsサービスを開き、Okta AD Agentサービスを停止します。
  2. ターミナルを使用して、各Okta AD AgentサーバーのOktaAgentService.exe.configファイルを見つけます。

    C:\Program Files (x86)\Okta\Okta AD Agent\OktaAgentService.exe.config

  3. OktaAgentService.exe.configをテキストエディターで開きます。PollingThreadsエントリを見つけます： <add key="PollingThreads" value="2" />

    デフォルト値は2、最大値は10です。

  4. ファイルを保存し、Okta AD Agentサービスを再起動します。設定が変更されたことを確認するには、起動時にagent.logファイルを開いて、ファイルの下部に表示される次の起動情報を確認します： 2017/07/21 06:06:22.167 Debug – TEST-SERVER-1(4) – PollingThreads:<thread number>

OktaはAWS Managed Active Directoryと統合できますか？

はい。OktaはAWS Managed Active Directoryと統合できますが、次の注意事項があります。

  • ADエージェントはサービスアカウントを作成できません。

  • ADエージェントはサービスアカウントに既存のアカウントを使用できます。

  • デフォルトのAWS Managed AD管理者アカウントを使用したくない場合は、詳細な権限を持つサービスアカウントを作成してください。「Oktaサービスアカウントの権限」を参照してください。

  • 新しいグループのプッシュは意図したとおりに機能しますが、AWS管理グループのプッシュはサポートされません。