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

ユニバーサルセキュリティグループの詳細については、こちらをクリックしてください。

変数

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

前提

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

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

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

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にサインインするときにメンバーシップを同期します。

例：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メンバーシップは同期されません（図の点線を参照）。

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

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

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

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

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

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

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

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

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

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

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

注：範囲外の組織単位（OU）という用語は、関連するOUセレクターで、表示されないか選択されていないOUを指します。（後のタイプの範囲外のOUの例は、下の図で黄色で強調表示されています。）

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

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

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サービスアカウントのパスワードを断続的に変更することをお勧めします。

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

1. Active Directoryで、［Active Directory Users and Computers（Active Directoryユーザーとコンピューター）］ツールを使用し、OktaServiceアカウントを探します。右クリックしてADのパスワードをリセットします。このアクションを実行するには、ドメイン管理者権限または十分に昇格した権限が必要になります。
2. エージェントがインストールされているサーバーの［Services（サービス）］コンソールで、以下を実行します。
   1. Okta AD Agentサービスを見つけて停止します。
   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 Users and Computers（Active Directoryユーザーとコンピューター）］ツールと［Services（サービス）］コンソールでリセットしたパスワードと一致するようにOktaサービスのパスワードがここで更新されていなければ、IWAは動作を停止します。

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

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

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

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

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

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

ログは問題のトラブルシューティングにおいて非常に貴重なリソースとなる可能性があり、Oktaサポートは、サポート案件の処理中にログを求めることがよくあります。トラブルシューティングの目的で詳細ログを有効にできます。

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

1. 影響を受けるAD Agentを実行しているシステムで、AD Agentのインストールディレクトリに移動します。デフォルトでは、これは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 Agentサービスを再起動します。

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

• AD Agentは、新しいサービスアカウントを作成できません。

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

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

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