According to documentation on Active Directory (AD) prerequisites, the Okta AD Agent service account requires read permissions for the entire domain and all children. This permission is granted to the Domain Users group, of which the service account is a member by default.

This permission allows Okta to read the entire AD hierarchy and attribute schema for users and groups. This allows Okta to obtain the necessary information to configure an AD integration, such as choosing Organizational Units (OUs) or Containers (CNs) for import in User OUs connected to Okta and Group OUs connected to Okta.

Under normal circumstances, selecting particular OUs for import is adequate. In large AD environments, however, there may be dozens or hundreds of OUs to select. In deeply nested hierarchies, there may be certain OUs that shall not be imported, and checking each individual OU may be unreasonable.

This article is written for environments with conditions such as the above and describes an alternate method that prevents Okta from reading AD OUs or CNs during import or Just In Time (JIT) provisioning events.

• Active Directory (AD)
• Organizational Unit (OU)
• Import

To prevent Okta from reading an Active Directory OU or CN during import, the Okta AD Agent service account may be granted explicit deny read permissions for the OU/CN. The impact of this change will be as follows:

• Any OU or CN with explicit deny read permissions will not be read by Okta during import or JIT provisioning events.
• Users or Groups contained within these OUs/CNs will not be visible to Okta and will not be imported.
• The OU/CN will not appear in the domain hierarchy of OUs.

To make this change using Active Directory Users and Computers (ADUC):

1. Open ADUC using an account that has the necessary rights to make changes to OUs and CNs in the domain.
2. Click View. If Advanced Features is not checked, click Advanced Features. If it is checked, continue to step 3.
3. Find the OU or CN in the left pane, right-click the OU/CN, then click Properties.

4. In the Properties window, click the Security tab.
5. If the Okta service account appears in the list of Group or user names, skip to step 7. If not, click Add.
6. A Selection window appears. Search for the Okta service account. If using the default, this is OktaService. When the user is found, click OK.
7. With the Okta service account highlighted, check the box for Deny Read.

8. Click Apply (optional), then click OK.
9. A Windows Security window will appear, warning that Deny permissions take precedence over Allow permissions. This warning must be acknowledged. Click Yes.

To verify that the Okta AD Agent service account can no longer read the OU, the AD topology must be refreshed. This is done automatically by the Agent on a set interval. To force this update manually, perform a full import.