ADグループのアクセスガバナンス
双方向グループ管理により、アクセスリクエストを使用してADをソースとするグループへのアクセスを要求し、アクセス認定を使用してこれらのグループへのアクセスを検証できます。またAPIを使ってユーザーを追加または削除したり、Workflows Connectorsでイベントトリガーを構成してAPI呼び出しを自動化したりできます。
- アクセスリクエスト
- アクセスリクエスト条件でADグループを使用して、要求者のスコープとアクセスレベルを定義します。つまり、ADをソースとするグループメンバーは、ADをソースとするグループへのアクセスを含み、リソースへのアクセスをEnd-User Dashboardからリクエストできます。ADをソースとするグループへのアクセスのリクエストがOktaで承認されると、要求者はADのそのグループへのアクセス権を取得します。
- アクセス認定
- ADをソースとするグループへのアクセスは、アクセス認定を使って管理できます。ADソースのグループをリソースとするキャンペーンでは、レビュアーがADソースのグループメンバーに対する決定を送信すると、OktaとActive Directoryで直ちに修正が行われます。
前提条件
アクセスリクエストを管理し、ADをソースとするグループを認証するには、次のセットアップが必要です。
-
次のようにセットアップされたActive Directory統合：
-
デプロイされ、使用可能なOkta Active Directoryエージェント
-
プロファイルソースとして設定されたActive Directory
-
ジャストインタイム（JIT）プロビジョニングが有効
-
-
ADエージェントには、グループメンバーシップの更新に必要な権限が必要です。「グループプッシュ」を参照してください。
-
ユーザーに対して後続の操作（ADグループへのユーザーの追加や削除など）を実行する前に、増分インポートまたはフルインポートを実行する必要があります。
-
グループからユーザーを削除できるのは、ユーザーがそのグループの直接メンバーである場合のみです。ユーザーがADグループを継承した場合、ネストされたグループメンバーシップ構造が原因で削除できない場合があります。
ADグループのアクセスリクエストを管理する際の考慮事項
-
アプリの条件の要求者スコープまたはアクセスレベルでADグループを指定できます。アクセスリクエスト条件を作成するを参照してください。
-
承認シーケンスのタスク割り当て先としてリソース所有者を使用するには、ADのグループに対して
managed-byフィールドを定義してください。これはOktaのグループ所有者に相当します。ADのmanaged-byフィールドが入力されていない場合、またはフィールドに指定されたユーザーがOktaユーザーとしてOktaにインポートされていない場合、タスクは未割り当てのままになります。 -
ユーザーがまだADにプッシュ（同期）されていない場合、OktaユーザーをADグループに追加することはできません。
-
ユーザーが子（ネストされた）ADソースグループをリクエストしてアクセスを取得すると、親グループにも追加されます。アクセスは、ネストされた階層の上方向にのみ反映されます。
ADグループへのアクセス認証に関する考慮事項
-
レビューのリソースとしてADグループを使ってアクセス認定キャンペーンをセットアップします。指定のADグループ内のユーザーは、アクセス認定キャンペーンに含まれます。「キャンペーンを作成」を参照してください。
-
レビュアーは、グループ内のユーザーのグループメンバーシップをレビューするための保留中のアクションを確認します。レビュアーがユーザーに取り消しのマークを付けると、そのユーザーはオンプレミスのADグループから削除されます。Oktaは、ユーザーのプロファイルとグループメンバーシップを更新します。
-
指定したADグループから削除されたユーザーについては、アクセス認定キャンペーンの要約で確認します。これは、Admin Consoleのの下のグループメンバーシップで検証することもできます。
-
次の状況では、レビュアーはアクセスを手動で修復しなければならない場合があります。
- ユーザーのグループメンバーシップが、ネストされたグループを通じて付与されている。この場合、レビュアーはネストされた特定のグループからのユーザーのアクセス権を取り消す必要があります。
- Oktaに接続されたエージェントがない。
- ADとの接続がタイムアウトになる。
- ADでのアクセスの取り消しに必要な権限がエージェントにない。
関連項目