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

ユニバーサル セキュリティー グループの詳細は、こちらからご覧いただけます。

変数

• ユーザーとUSGが同じADドメインにあるか異なるADドメインにあるか
• 異なるドメインの場合、ドメインが両方ともOktaにあるか、信頼関係で結ばれているか
• ユーザーはOktaに サインイン（JIT）するかインポートするか

前提条件

• ［JIT Provisioning（JITプロビジョニング）］ と ［USG Support（USGサポート）］オプションが ［Import and Account Settings（インポートとアカウント設定）］で選択されている。
• ［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のメンバーであればどうなりますか？

• ユーザーとUSGが同じドメインに属し、USGがOktaにある場合、OktaはOkta内のユーザープロファイルを作成または更新して、ユーザーのメンバーシップをUSGに同期します。
• ユーザーとUSGが 異なるドメインに属し、USGがOktaにあれば、2つのドメインが信頼関係で結ばれていれば、OktaはユーザーのメンバーシップをUSGに同期します。ドメインに信頼関係がなければ、OktaはUSG内のユーザーのメンバーシップを認識しません。

インポートシナリオ

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

• ユーザーとUSGが同じドメインに属す場合、OktaはOkta内のユーザープロファイルを作成または更新して、USGがOktaにまだないならUSGを作成し、ユーザーのメンバーシップを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をインポートするとURGがOktaに取り込まれ、グループ2メンバーシップがUSGに同期されますか？

はい。

例：3つのドメインにまたがるUSG

前提：ドメインAにあり、ドメインA、B、Cからのユーザーを含む3ドメインフォレスト内の1つのUSG。

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

ドメインBとCユーザーとグループがOktaにインポートされると、これらのドメインからのUSGメンバーシップは、これらのドメインからのユーザーが最初にOktaにサインインするまで同期されません（図の点線で示される通り）。

ディストリビューショングループは、増分インポートおよびフルインポート時にOktaに取り込まれますが、ジャストインタイム（JIT）プロビジョニングでは取り込まれません。

ユーザーがサインインして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のインポートとアカウントの設定の構成を参照。

注： out-of-scope（スコープ外）組織単位（OU）とは、該当するOUセレクターに表示されないまたは選択されていない OUを指します。（スコープ外OU の後者のタイプの例は、下図に黄色のハイライトで示されています。）

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

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

Oktaは、Active Directory内での有効/無効ステータスにかかわらずスコープ外OU内のユーザーのサインインはすべて拒否します。

• スコープ外 OU内のユーザーでADで有効となっている者がOktaにサインインしようとすると、 Okta はユーザーのADでのステータスを検出してそれをOkta内でアクティブとして保持しますが、サインインの試みは拒否します。
• スコープ外 OU内のユーザーでADで有効となっている者がOktaにサインインしようとすると、 Okta はユーザーのADステータスを検出して、サインインの試みを拒否します。

インポートシナリオ

Oktaは増分インポートとフルインポートを行います。

• 増分インポート時、Oktaはスコープ外のOUのユーザーおよびグループを検出しないため、これらのユーザーまたはグループはインポートされません。

• フルインポートまたは増分インポートでスコープ内OUからインポートされ、後ほどスコープ外OUに移動されたアカウントは、後続の増分インポートではディアクティベートされません。

• フルインポート時、Oktaはスコープ外OU にあるユーザーを欠如として検出し、（ADでの有効/無効ステータスにかかわらず）ディアクティベートし、次回のサインインの試みを却下します。

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

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

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

JITプロビジョニングの機能は「フラット」メンバーシップしか検出しないため、これらのメンバーシップを正しく解決します。

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

はい。インストールプロセスで作成されたものを使うのではなく、自分で作成したい場合は、エージェントインストール用の既存のADサービスアカウントを作成して使用できます。

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

Okta ADエージェントのインストールに使用したOktaサービス アカウントのパスワードは、断続的に変更することがベストプラクティスです。

パスワードを変更するには、次のようにします。

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

Okta IWA SSOエージェントもインストールして、Okta ADエージェントのインストールに使用したのと同じOktaサービスアカウントを使用する場合、IISサーバーマネージャーダッシュボード> ツール> インターネット情報サービス（IIS） マネージャーでのOktaサービスアカウントパスワードも変更する必要があります。 OktaIWA サービスは［Application Pools（アプリケーションプール）］メニュー下でインストールします。 ［Advanced Settings（詳細設定）］の下で、新しいパスワードに一致するようにOktaサービスパスワードを変更できます。キャッシングのため、IWAサービスは即時停止しないことがあります。キャッシュがリセットするとき、OktaServiceパスワードをここで更新して、Active Directoryユーザーおよびコンピュータツールおよびサービスコンソールでリセットしたパスワードに一致させないと、IWAは機能しなくなります。

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

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

Okta ADエージェントは発信のみです。着信エージェントトラフィック用にファイアウォールをペンする必要はありません。

いいえ。すべてのアクティブエージェントがトラフィックを受信します。エージェントがトラフィックを受信するかどうかを制御する唯一の方法はそのエージェントをオフにすることです。失敗時にバックアップデータセンターに移動するようにエージェントトラフィックを特化することはできません。

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

現時点では、エージェントのインストールを自動化する方法はありません。

ログあ問題のトラブルシューティングに欠かせない貴重なリソースで、Oktaサポートは多くの場合ケースの解決にそれをリクエストします。トラブルシューティングの目的で、詳細ログを有効にできます。

莫大な大型ファイルの継続的な生成を避けるために、Oktaではトラブルシューティングを終えるときに詳細ログを無効にすることを推奨しています。

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エージェントサービスを再起動します。