Access governance for AD groups
With Bidirectional Group Management, you can request access to AD-sourced groups using Access Requests and verify access to these groups using Access Certifications. You can also use the API to add or remove users, and configure an event trigger with Workflows Connectors to automate the API calls.
- Access Requests
- Use AD groups in access request conditions to define requester scopes and access levels. This means that AD-sourced group members can request access to resources, including access to AD-sourced groups, from their End-User Dashboard. When a request to access an AD-sourced group is approved in Okta, the requester gets access to that group in AD.
- Access Certifications
- You can govern access to AD-sourced groups using Access Certifications. For a campaign with AD-sourced groups as a resource, when reviewers submit a decision for an AD-sourced group member, the remediation happens immediately in Okta and Active Directory.
- To use Bidirectional Group Management with Active Directory (AD), set up an Access Certifications campaign with an AD group for review. Reviewers can assess the group membership and select users for revocation. You can then check the campaign summary to view the list of users removed from the specified AD group.
Prerequisites
You must have the following setup to manage access requests and certify AD-sourced groups:
-
Active Directory integration with the following setup:
-
Deployed and operational Okta Active Directory agents
-
Active Directory set as the profile source
-
Just-In-Time (JIT) provisioning enabled
-
-
Your AD agent needs the required permissions to update group memberships. See Group push or Bidirectional Group Management.
-
You must run an incremental or full import before performing subsequent operations on a user, such as adding or removing them from an AD group.
-
You can remove users from a group only if they're a direct member of that group. If a user inherits an AD group due to a nested group membership structure, removing them may not be possible.
Considerations for managing access requests for AD groups
-
You can specify an AD group in the requester scope or access level of a condition for an app. See Create an access request condition.
-
To use resource owner as a task assignee in an approval sequence, ensure that you define the managed-by field for the group in AD. This is the equivalent of a group owner in Okta. If the managed-by field isn't populated in AD or the user specified in the field hasn't been imported into Okta as an Okta user, the task remains unassigned.
-
You can't add an Okta user to an AD group if that user hasn't yet been pushed (synced) to AD
-
If a user requests and gains access to a child (nested) AD-sourced group, they also get added to the parent group. Access only propagates upward in the nesting hierarchy.
Considerations for certifying access to AD groups
-
Set up an Access Certifications campaign with an AD group as a resource for review. Users in the specified AD group are included in the Access Certifications campaign. See Create resource campaigns.
-
Reviewers see pending actions to review group membership for users in the group. If the reviewer marks a user for revocation, the user is removed from that on-premises AD group. Okta refreshes the users' profile and updates their group membership.
-
Check the Access Certifications campaign summary for users who are removed from the specified AD group. You can also verify this through the group memberships in the Admin Console under .
-
Reviewers may still need to remediate access manually in the following situations:
- When the user's group membership was granted through a nested group. In this case, the reviewer must revoke the user's access from the specific nested group.
- When there are no agents connected to Okta.
- When the connection to AD times out.
- When the agent doesn't have the required permissions to revoke access in AD.