Groups have a variety of uses in the Okta org and can be imported and managed from multiple sources. When imported from an external source, such as Active Directory (AD), groups are stored in Okta as AppGroup objects associated with that specific integration source.

As there currently is no single out-of-the-box report that combines all possible group configurations, this article provides an overview of some of the Okta Admin Management APIs that are available to identify groups, and uses AD as the example source.

This is intended as an overview for getting started, not as a complete solution. If assistance is required with custom solutions, architectural reviews, or migrations, please reach out to the Okta account representative to review options, including Okta's expert Professional Services.

• User Lifecycle Management
• Profile Sources
• App Groups
• Application Programming Interface (API)
• Okta Classic Engine
• Okta Identity Engine (OIE)

Identify Active Directory App Groups

Groups imported from AD are noted in the groups' profiles in Okta as APP_GROUP objects associated with the given AD integration. 

The first step is to identify the AD app instance or instances in the org:

1. Use the List applications operation with:
2. GET /api/v1/apps?filter=name eq "active_directory"
3. From the responses, collect the id of each Active Directory app instance. Those IDs can then be used to locate the groups sourced from each integration.
4. Next, use the List groups operation to find groups whose source.id matches one of the AD app instance IDs:
5. GET /api/v1/groups?search=source.id eq "{appId}"

This produces the set of externally sourced groups for that AD instance, along with the metadata needed for later correlation.

Find Application Assignments That Use Those Groups

1. To determine where AD groups are directly assigned, first retrieve the list of applications using the List applications endpoint:
2. GET /api/v1/apps
3. Paginate through the results until the full application inventory is collected. Then, for each application, retrieve its group assignments using List application group assignments:
4. GET /api/v1/apps/{appId}/groups
5. Compare the group IDs returned by each application against the AD group inventory built in the previous step. Any match indicates that the application is using an AD-sourced group for assignment or access control.
   
   

Review Group Rules for Group-Based Conditions

Okta Group Rules can reference AD groups, even if those groups are not explicitly named in the destination of the rule. Retrieve the rules with the Group Rules API:

GET /api/v1/groups/rules

The primary field to inspect is conditions.expression.value. Search those expressions for any reference to the AD groups, whether by ID or by name. Expressions such as isMemberOfGroup("00g...") are especially important to capture.
NOTE: since AppGroups are managed externally, the field actions.assignUserToGroups cannot contain an AD group id because the target of the Group Rules must be an Okta group.

Check Whether AD Groups Grant Admin Privileges

Confirm if AD groups are used to assign Okta administrative roles. For each AD group identified earlier, call the Group Role Assignments API:

GET /api/v1/groups/{groupId}/roles

If the response is successful and contains one or more role assignments, that group is being used to delegate administrative capabilities within Okta. Otherwise, an empty response [] is returned to indicate that no role is associated.

Review Group Push Mappings

If Group Push is enabled for downstream provisioning, group usage may also appear in application-level push mappings. For each application that supports Group Push, use the Group Push Mappings API to list its mappings:

GET /api/v1/apps/{appId}/group-push/mappings

The main field to validate is the sourceGroupId which is the id of the source group for the group push mapping.

Review SAML Attribute Statements and Expression Language References

Custom SAML applications often include group logic in attribute statements. This can appear either as direct group filters or as Okta Expression Language expressions.

1. Review the application definitions obtained earlier using List applications:
2. GET /api/v1/apps
3. For SAML 2.0 applications, inspect the settings.signOn.attributeStatements collection.
   • Statements of type GROUP may include filters such as REGEX or EQUALS, and their values should be checked for references to AD group names.
   • Statements of type EXPRESSION should be reviewed for functions such as isMemberOfGroup(), isMemberOfGroupName(), or Groups.startsWith().

By design and by the nature of the evaluation by name and not id, there is no single source to query for this, as the statements evaluate live during the sign-on event and are dynamic. This means searching expressions and statement values for any occurrence of the id or names from any and all of the AD groups.

Check Policy Rules for Included or Excluded Groups

Review each relevant policy type and all rules under each policy.

1. Begin with the Policies API to list policies by type:
2. GET /api/v1/policies?type={type}

• • Typical policy types to review include OKTA_SIGN_ON, PASSWORD, MFA_ENROLL, ACCESS_POLICY, and IDP_DISCOVERY.

2. Retrieve the rules for each policy using the same policy documentation:
3. GET /api/v1/policies/{policyId}/rules
4. Within each rule, inspect the group conditions under conditions.people.groups.include and conditions.people.groups.exclude.
   • Those arrays should be cross-referenced with the AD group IDs to determine whether any AD groups are explicitly included in or excluded from the policy logic.

For completeness, also check any OIDC group claims if using Authorization Servers.

1. Use Authorization Servers API to list authorization servers.
2. Use the Authorization Server Claims API to retrieve its claims.

NOTE: To request enhancements, please see How to Submit a Feature or Enhancement Request using Okta Ideas.