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

ユニバーサル・セキュリティー・グループの詳細については、こちらをクリックしてください。
変数
- ユーザーとUSGが同じADドメインに存在するか、異なるADドメインに存在するか。
- 異なるドメインの場合、両方のドメインがOktaに存在し、信頼関係で接続されているかどうか。
- ユーザーがサインイン(JIT)またはインポートを使用してOktaにアクセスするかどうか。
前提
- [JITプロビジョニング]オプションと[USGのサポート]オプションが[インポート設定]および[アカウント設定]で選択されています。
- [インポートのスケジュールを設定]オプションが選択されている場合、[新規ユーザーをインポートしない]オプションは選択されていません。
Oktaは複数ドメインのメンバーを含むドメイン・ローカル・グループをサポートしていません。ドメイン間で双方向の信頼が確立されている場合、クロス・ドメイン・メンバーシップを持つユニバーサル・セキュリティ・グループがサポートされます。ユニバーサル・セキュリティ・グループは、フォレスト間のメンバーシップをサポートしません。

Oktaにまだ存在しないUSGのメンバーであるユーザーがOktaにサインインするとどうなりますか?
- ユーザーとUSGが同じドメインに属していても、USGがOktaにまだ存在しない場合、Oktaは、Oktaでユーザーのプロファイルを作成または更新し、USGを取り込み、ユーザーのメンバーシップをUSGに同期します。
- ユーザーとUSGが異なるドメインに属し、両方のドメインがOktaに存在するが、USGがOktaにまだ存在しない場合、Oktaは、Oktaでユーザーのプロファイルを作成または更新しますが、USGをOktaに取り込みません。
Oktaにすでに存在するUSGのメンバーであるユーザーがOktaにサインインするとどうなりますか?
- ユーザーとUSGが同じドメインに属し、USGがOktaに存在する場合、Oktaは、Oktaでユーザーのプロファイルを作成または更新し、ユーザーのメンバーシップをUSGに同期します。
- ユーザーとUSGが異なるドメインに属し、USGがOktaに存在する場合、2つのドメインが信頼関係によって接続されている場合にのみ、Oktaはサインイン時にユーザーのメンバーシップをUSGに同期します。ドメインに信頼関係がない場合、OktaはUSGのユーザーのメンバーシップを認識しません。

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

ドメインBに存在し、ドメインAおよびドメインBのユーザーを含むUSGがあるとします。
ドメインAがOktaにインポートされた場合、USGのどのメンバーがOktaにインポートされますか?
ドメインAのユーザーのみがOktaにインポートされ、USGのメンバーシップは、後でドメインBがインポートされるまで無視されます。
ドメインAがすでにOktaに存在する場合、ドメインBをインポートするとUSGがOktaに取り込まれ、2つのグループ・メンバーシップがUSGに同期されますか?
はい。

3つのドメインのフォレスト内にあり、ドメインAに存在し、ドメインA、B、Cのユーザーが含まれているUSGがあるとします。
ドメインAのユーザーおよびグループがOktaにインポートされると、USGがインポートされ、ドメインAのUSGユーザー・メンバーシップが同期されます。
ドメインBおよびドメインCのユーザーとグループがOktaにインポートされた場合、それらのドメインのユーザーが初めてOktaにサインインするまで、これらのドメインのUSGメンバーシップは同期されません(図の点線を参照)。

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

増分インポートおよびフル・インポート中、およびインポートされるユーザーとグループが同じドメインに属する場合のみ。
ユーザーがサインインしてジャストインタイム(JIT) プロビジョニング・フローが有効な場合、Oktaはセキュリティー・グループのメンバーシップをインポートしますが、配布グループはインポートしません。JITプロビジョニングでは、ユーザー・アカウントの配布グループのメンバーシップは同期されません。ユーザーが子配布グループのメンバーである場合、親セキュリティー・グループのメンバーシップを継承しません。配布グループのメンバーシップをADからOktaに定期的に更新するには、インポートをスケジュールします。
[Oktaへ]ページのプロビジョニング・オプションとして[インポート中にユーザーをスキップ]チェック・ボックスがオンになっている場合、配布グループまたはユニバーサル・セキュリティー・グループのグループ・メンバーシップはインポートされません。 Active Directoryのインポートとアカウントの設定の構成を参照してください。

Oktaは、次の点において、DGとUSGを同じように扱います。
インポート中、Oktaは、インポートされるドメインとは異なるドメインに存在するDGまたはUSGにグループ・メンバーシップを同期しません。
Oktaは、次の点において、DGとUSGを異なる方法で扱います。
- ユーザーとそのユーザーがメンバーであるUSGが同じドメインに属している場合、Oktaはジャストインタイム(JIT)プロビジョニングおよびインポート中にユーザーをUSGに同期します
- ユーザーとそのユーザーがメンバーであるDGが同じドメインに属している場合、Oktaはインポート中のみユーザーをDGに同期し、JIT中は同期しません。
ユーザーがサインインしてJIT プロビジョニング・フローが有効な場合、Oktaはセキュリティー・グループのメンバーシップをインポートしますが、配布グループはインポートしません。JITプロビジョニングでは、ユーザー・アカウントの配布グループのメンバーシップは同期されません。ユーザーが子配布グループのメンバーである場合、親セキュリティー・グループのメンバーシップを継承しません。配布グループのメンバーシップをADからOktaに定期的に更新するには、インポートをスケジュールします。
[Oktaへ]ページのプロビジョニング・オプションとして[インポート中にユーザーをスキップ]チェック・ボックスがオンになっている場合、配布グループまたはユニバーサル・セキュリティー・グループのグループ・メンバーシップはインポートされません。 Active Directoryのインポートとアカウントの設定の構成を参照してください。

注:範囲外の組織単位(OU)という用語は、関連するOUセレクターで、表示されないか選択されていないOUを指します。(後のタイプの範囲外のOUの例は、下の図で黄色で強調表示されています。)
一部の組織は、ユーザーまたはグループを範囲外のOUに移動することを含む、従業員のオフボーディング・プロセスを管理しています。以下で詳しく説明するように、Oktaが範囲外のOUにユーザーやグループをインポートすることはなく、そのようなすべてのユーザーへのサインインを拒否します。

Oktaは、Active Directoryでの有効化ステータスに関係なく、範囲外のOUのすべてのユーザーへのサインインを拒否します。
- ADで有効になっている範囲外のOUのユーザーがOktaにサインインしようとすると、OktaはユーザーのADステータスを検出し、Oktaでアクティブとして保持しますが、サインインの試行は拒否します。
- ADで無効になっている範囲外のOUのユーザーがOktaにサインインしようとすると、OktaはユーザーのADステータスを検出し、Oktaで非アクティブ化し、サインインの試行を拒否します。

Oktaは、増分インポートおよびフル・インポートを実行します。
- 増分インポート中、Oktaは範囲外のOUのユーザーとグループを検出しないため、これらのユーザーまたはグループはどれもインポートされません。
フル・インポートまたは増分インポート中に範囲内のOUからインポートされ、後で範囲外のOUに再配置されたアカウントは、後続の増分インポート中に非アクティブ化されません。
- フル・インポート中に、Oktaは範囲外のOUのユーザーを欠落として検出し、(ADでの有効化ステータスに関係なく)非アクティブ化し、次のサインインの試行を拒否します。
ADで削除されたOktaのADグループは、フル・インポートのときにのみOktaから削除されます。

「通常の」インポートとJITプロビジョニングの間でメンバーシップの不整合が発生する可能性があります。 このようなメンバーシップの 異常 は、ネストされたグループを使用する場合に発生する可能性があります。
通常のインポート中、Oktaは、AD OUまたはLDAPオブジェクト・フィルターのスコープ外の子グループを検出しません。親グループがOU/オブジェクト・フィルターのスコープ内にあり、その子グループがスコープ内にない場合、Oktaはインポート中に親グループのメンバーシップを誤って解決します。
JITプロビジョニングの関数は「フラットな」メンバーシップのみを検出するため、JITプロビジョニングでは、このようなメンバーシップは親グループに正しく解決されます。

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

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

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

Okta AD Agentのインストールに使用したOktaサービス・アカウントのパスワードを断続的に変更することをお勧めします。
パスワードを変更するには:
- Active Directoryで、[Active Directoryユーザーとコンピューター]ツールを使用し、OktaServiceアカウントを探します。右クリックしてADのパスワードをリセットします。このアクションを実行するには、ドメイン管理者権限または十分に昇格した権限が必要になります。
- エージェントがインストールされているサーバーのサービス・コンソールで、
- Okta AD Agent・サービスを見つけて停止します。
- サービスを右クリックし、[プロパティー] > [ログオン]タブを選択します。
- ADで設定したパスワードと一致するようにパスワードを変更します。
- サービスを開始します。
Okta IWA SSOエージェントもインストールし、Okta AD Agentのインストールに使用したものと同じOktaサービス・アカウントを使用した場合は、IISの[サーバー マネージャー ダッシュボード] > [ツール] > [インターネット インフォメーション サービス(IIS)マネージャー]でOktaサービス・アカウントのパスワードも変更する必要があります。Okta IW Aサービスは、[アプリケーション プール]メニューの下にインストールされます。[詳細設定]で、Oktaサービスのパスワードを新しいパスワードに合わせて変更できます。キャッシュが原因で、IWAサービスがすぐに停止しない場合があります。キャッシュがリセットされたときに、[Active Directoryユーザーとコンピューター]ツールと[サービス]コンソールでリセットしたパスワードと一致するようにOktaサービスのパスワードがここで更新されていなければ、IWAは動作を停止します。

Okta管理者アカウントのパスワードをリセットするには、次の2つのオプションがあります。
- その管理者のユーザーIDとパスワードを使用してサインインします。エンド・ユーザー・アカウントの[設定] > [パスワードを変更]セクションに移動します。
- スーパー管理者としてサインインしているときに、[管理者] > [ディレクトリー] > [ユーザー] > (管理者アカウント名) > [パスワードをリセット]に移動します。次に、パスワード・リセット用リンクを送信するか、一時パスワードを設定するかを選択します。

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

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

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

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

ログは問題のトラブルシューティングにおいて非常に貴重なリソースとなる可能性があり、Oktaサポートは、サポート案件の処理中にログを求めることがよくあります。トラブルシューティングの目的で詳細ログを有効にできます。
多数の大きなファイルが継続的に生成されるのを防ぐため、Oktaではトラブルシューティングが終了したら詳細なログ記録を無効にすることをお勧めします。
- 影響を受けるAD Agentを実行しているシステムで、AD Agentのインストール・ディレクトリーに移動します。デフォルトでは、これはC:\Program Files (x86)\Okta\Okta AD Agentです。
- OktaAgentService.exe.configファイルをテキスト・エディターで開きます。
次の値を変更します。
<add key="VerboseLogging" value="False" />
変更後の値は次のとおりです。
<add key="VerboseLogging" value="True" />
- 変更をファイルに保存します。
- AD Agentサービスを再起動します。

Okta AD Agentがタスク用サーバーをポーリングするのに使用するスレッド数を増やすと、追加のOkta AD Agentをインストールしなくても、既存のOkta AD Agentがより多くの要求を処理できるようになります。
- Windowsサービスを開き、Okta AD Agent・サービスを停止します。
- ターミナルから、各Okta AD Agent・サーバーのOktaAgentService.exe.instances.configファイルを見つけます:
C:\Program Files (x86)\Okta\Okta AD Agent\OktaAgentService.exe.config
テキスト・エディターで「OktaAgentService.exe.config」ファイルを開き、次のエントリーを見つけます:
<add key="PollingThreads" value="2" />
デフォルト値は2で、最大値は10です。
ファイルを保存し、Okta AD Agent・サービスを再起動します。設定が変更されたことを確認するには、起動時にagent.logファイルを開き、ファイルの一番下にある起動情報を確認します:
2017/07/21 06:06:22.167 Debug – TEST-SERVER-1(4) – PollingThreads: <thread number>