Active Directory integration considerations and limits
Keep the following in mind when using Active Directory (AD) integrations:
-
If you're using a custom URL:
- Agents: Use the actual domain (example.okta.com) and not the custom domain (example.customname.com).
- IWA SSO: Modify the web.config file to include the custom url.
<oktaSSOConfigGroup>
<oktaSSOConfig orgOktaAuthenticationURL="https://example.customname.com/login/sso_iwa_auth"
orgBackupOktaAuthenticationURL="https://example.customname.com/login/default"
oktaSSOWebAppVersion="1.11.5.0"> - Agentless DSSO: Make sure that all sign-in flows and browser bookmarks use the correct URL.
- When you add an attribute to an AD domain, restart every Okta AD agent connected to the domain. If an Okta AD agent isn't restarted, an Active Directory restriction causes the AD agents to base-64 encode the new attribute's values.
- When renaming an AD domain, uninstall the Okta AD agent before you start the renaming process. When you complete the renaming process, reinstall the Okta AD agent with the new domain name. A renamed domain appears as a new AD app instance in Okta.
- Sometimes, group membership information for AD-sourced users that is imported into Okta during Just-In-Time (JIT) provisioning isn't removed by full or incremental imports. Subsequent JIT or profile updates are required to update group membership information.
- When the provisioning settings indicate Do nothing when users are deactivated, users remain active in Okta. When a single source provides user profile attributes, deactivated users are disconnected from the source and Okta becomes the source for user profile attributes.
- When Deactivate Users is disabled on the Provisioning tab, users that are deactivated from AD and reactivated in Okta through JIT provisioning don't have Distribution Groups assigned to them. To resolve this, deactivate the user from AD and perform a full import.
Group import limits
Okta limits the total number of bytes that can be sent from an AD agent to the Okta server in a single request to 20,971,520 bytes (20 megabytes). To avoid exceeding Okta size limits during data import, result sets that contain multiple group objects are split into separately sized units. Each unit is sent in a separate request.
A single group that exceeds the defined size limit is still sent to Okta. A standard HTTP 413 (Payload Too Large) error might be returned if the size exceeds 250,000 bytes (0.25 megabyte). The length of the group distinguishedName (dn), the length of the user dn within the group, and the group membership size all contribute to the total bytes sent to Okta.
If you receive an HTTP 413 (Payload Too Large) error, it's recommended that you split direct group membership into nested group membership or subgroups. This helps to avoid the size limit and allows the data to be sent in a single request.