Active Directory integration FAQ

How does Okta handle Universal Security Groups?

For more about Universal Security Groups (USGs), see Security Groups.

Variables

  • Whether users and USGs reside in the same or different AD domains.
  • If different domains, whether both domains exist in Okta and are connected by a trust relationship.
  • Whether users are added to Okta through sign-in (JIT) or import.

Assumptions

  • JIT Provisioning and USG Support options are selected in Import and Account Settings.
  • If the option Schedule import is selected, the option Do not import new Users isn't selected.

Okta doesn't support Domain Local Groups containing members from multiple domains. USGs with cross-domain membership are supported if there's a two-way trust established between the domains. USGs don't support cross-forest membership.

Sign-in (JIT) scenarios

A user who's a member of a USG that doesn't exist in Okta signs in to Okta

  • If the user and the USG belong to the same domain but the USG doesn't exist in Okta, Okta creates or updates the user's profile in Okta, brings in the USG, and syncs the user's membership to the USG.
  • If the user and the USG belong to different domains and both domains exist in Okta but the USG doesn't exist in Okta, Okta creates or updates the user's profile in Okta but doesn't bring the USG into Okta.

A user who's a member of a USG that exists in Okta signs in to Okta

  • If the user and the USG belong to the same domain and the USG exists in Okta, Okta creates or updates the user's profile in Okta and syncs the user's membership to the USG.
  • If the user and the USG belong to different domains and the USG exists in Okta, Okta syncs the user's membership to the USG at sign-in only if the two domains are connected by a trust relationship. If the domains have no trust relationship, Okta doesn't recognize the user's membership in the USG.

Import scenarios

What happens during an import of groups and users?

  • If the users and the USG are members of the same domain, Okta creates or updates the users' profile in Okta, creates the USG if it doesn't exist in Okta, and syncs memberships to the USG only for users in the domain being imported. Nothing is imported from other domains. During import, Okta doesn't recognize memberships to USGs in other domains.
  • If the users in the domain being imported are members of a USG that resides in a different domain, Okta only imports the users and ignores their membership in the USG. If the domain containing the USG is imported later, Okta syncs memberships the next time group members sign in to Okta.

Example: USG across 2-Domains

Suppose there's a USG that resides in Domain B and contains users from Domains A and B:

If Domain A is imported into Okta, which members of the USG are imported into Okta?

Only users from Domain A are imported into Okta and their membership in the USG is ignored until Domain B is later imported.

If Domain A exists in Okta, does importing Domain B bring the USG into Okta and sync Group 2 memberships to the USG?

Yes.

Example: USG across 3-Domains

Given a USG in a 3-domain forest that resides in Domain A and contains users from Domains A, B, and C.

When Domain A users and groups are imported into Okta, the USG is imported and Domain A USG user memberships are synced.

If the users and groups from Domain B and Domain C are imported into Okta, the USG memberships from those domains aren't synced until users from those domains sign in to Okta for the first time (as indicated by the dotted line in the diagram).

When are Distribution Groups brought in to Okta?

Distribution Groups are brought into Okta during incremental and full imports and not during Just-in-Time (JIT) provisioning.

When users sign in and the JIT provisioning flow is enabled, Okta imports security group memberships but not distribution groups. JIT provisioning doesn't synchronize distribution group membership for user accounts. Users don't inherit membership in any parent security group when they're members of a child distribution group. To regularly update distribution group memberships from AD to Okta, schedule an import.

When are Distribution Group memberships synced in Okta?

Only during incremental and full imports, and only if the users and groups being imported belong to the same domain.

When users sign in and the Just-in-Time (JIT) provisioning flow is enabled, Okta imports security group memberships but not distribution groups. JIT provisioning doesn't synchronize distribution group membership for user accounts. Users don't inherit membership in any parent security group when they're members of a child distribution group. To regularly update distribution group memberships from AD to Okta, schedule an import.

When Skip users during import is selected as a provisioning option on the To Okta page, group memberships aren't imported for Distribution or Universal Security Groups. See Configure Active Directory import and account settings.

Does Okta treat Distribution Groups (DGs) and Universal Security Groups (USGs) the same or differently?

Okta treats DGs and USGs the same in this respect:

During imports, Okta doesn't sync group memberships to DGs or USGs that reside in a different domain than the domain being imported.

Okta treats DGs and USGs differently in this respect:

  • If a user and a USG of which it's a member belong to the same domain, Okta syncs the user to the USG during Just-in-Time (JIT) provisioning and imports
  • If a user and a DG of which it's a member belong to the same domain, Okta syncs the user to the DG only during imports, not during JIT.

When users sign in and the JIT provisioning flow is enabled, Okta imports security group memberships but not distribution groups. JIT provisioning doesn't synchronize distribution group membership for user accounts. Users don't inherit membership in any parent security group when they're members of a child distribution group. To regularly update distribution group memberships from AD to Okta, schedule an import.

When Skip users during import is selected as a provisioning option on the To Okta page, group memberships aren't imported for Distribution or Universal Security Groups. See Configure Active Directory import and account settings.

How does Okta handle users and groups that are moved to an out-of-scope OU?

The term out-of-scope Organizational Unit (OU) refers to an OU that doesn't appear in or isn't selected in the relevant OU selector. The following image highlights examples of the latter in yellow.

Some organizations administer an employee off-boarding process that involves moving users or groups to an out-of-scope OU. Okta never imports users and groups in out-of-scope OUs, and denies sign-in to all such users.

Sign-in (JIT) scenarios

Okta denies sign-in to all users in out-of-scope OUs, regardless of their enablement status in Active Directory.

  • When a user in an out-of-scope OU who's enabled in AD tries to sign in to Okta, Okta detects the user's AD status, preserves them as active in Okta, but denies their sign-in attempt.
  • When a user in an out-of-scope OU who's disabled in AD tries to sign in Okta, Okta detects their AD status, deactivates them in Okta, and denies their sign-in attempt.

Import scenarios

Okta performs incremental and full imports.

  • During an incremental import, Okta doesn't detect users and groups in out-of-scope OUs, so none of these users or groups are imported.
  • Accounts imported from an in-scope OU during a full or incremental import and then later relocated to an out-of-scope OU aren't deactivated during a subsequent incremental import.

  • During a full import, Okta detects users in out-of-scope OUs as missing, deactivates them (regardless of their enablement status in AD), and denies their next sign-in attempt.
  • AD groups in Okta that have been deleted in AD are only removed from Okta during full imports.

How does JIT provisioning treat nested groups outside of OU and object filter scopes?

Membership inconsistencies can occur between "regular" imports and JIT provisioning. These membership anomalies may occur when using nested groups.

During regular imports, Okta doesn't detect a child group that is outside the scope of an AD OU or LDAP object filter. If a parent group is within an OU/object filter scope but its child groups aren't, Okta incorrectly resolves the parent group membership during import.

JIT provisioning correctly resolves these memberships to the parent group because its function detects only "flat" memberships.

What permissions does the Okta AD Agent Management Utility require?

The default permission is domain administrator. See Get started with Active Directory integration.

Can I create the Okta service account myself?

Yes, you can create or use an existing AD service account for the agent install if you don't want the install process to create one for you.

Can I move the Okta service account to a different OU?

Yes. You can move the account after installing the agent. For example, to an OU reserved just for service accounts.

How do I change the Okta service account password?

A best practice is to intermittently change the password for the Okta Service Account that was used to install the Okta AD agent.

To change the password:

  1. In Active Directory, use the Active Directory Users and Computers tool to locate the OktaService account. Right-click and reset the password in AD. You need domain admin or sufficiently elevated privileges to perform this action.
  2. On the server on which the agent is installed, on the Services console:
    1. Locate the Okta AD agent service and stop it.
    2. Right-click the service and select the PropertiesLog on tab.
    3. Change the password to match the one that you set in AD.
    4. Start the service.

If you have also installed the Okta IWA SSO agent and used the same Okta Service account that was used to install the Okta AD agent, then you must also change the Okta Service account password in the IIS Server Manager dashboardToolsInternet Information Services (IIS) Manager. The OktaIWA service is installed under the Application Pools menu. Under Advanced Settings you can change the Okta Service password to match the new password. Due to caching, the IWA service may not stop immediately. When the cache does reset, IWA stops working if the OktaService password hasn't been updated here to match the password that you reset in the Active Directory Users and Computers tool and the Services console.

How do I change the Okta admin account password?

There are two options for resetting an Okta admin account password:

  • Sign in using that Admin user ID and password. Go to the end user account SettingsChange Password section.
  • While signed in as a super admin, go to AdminDirectoryPeople(admin account name)Reset Password. Then select whether to send a reset password email or create a temporary password.

Do I have to open my firewall for the agent?

The Okta AD agent is outbound only. You don't have to open your firewall for any inbound agent traffic.

Can I control which agents receive traffic?

No. All active agents receive traffic. The only way to control whether an agent receives traffic or not is to turn an agent off. It's not possible to tailor agent traffic so that it only goes to a backup data center in the event of a failure.

Can I schedule when imports occur?

You can't schedule a specific time of day for imports. You can schedule the frequency of imports. To schedule import frequency, go to DirectoryDirectory Integrations and select the AD integration. On the Settings tab, scroll to Import and Provisioning and the Schedule Import option to select the import interval. To perform a manual import, select the Import tab and click Import Now.

Is there a way to automate the agent install?

There's no means to automate the agent installation.

How do I turn on more verbose debugging for the agent?

Logs can be an invaluable resource when troubleshooting an issue. You can enable verbose logging for troubleshooting purposes.

To avoid continually generating numerous large files, it's recommended that you disable verbose logging when you finish troubleshooting.

  1. On the system running the affected AD Agent, go to the AD Agent install directory. By default, this is C:\Program Files (x86)\Okta\Okta AD Agent.
  2. Open the OktaAgentService.exe.config file with a text editor.

    Change <add key="VerboseLogging" value="False" /> to <add key="VerboseLogging" value="True" />.

  3. Save your changes to the file.
  4. Restart the AD Agent Service.

What level of performance tuning can I do on the agent?

You don't need to install more AD agents for large requests. Increasing the number of threads used to poll allows the existing Okta AD agent to process more requests.

  1. Open Windows Services and stop the Okta AD agent service.
  2. From the terminal, locate the OktaAgentService.exe.instances.config file for each Okta AD agent server:

    C:\Program Files (x86)\Okta\Okta AD Agent\OktaAgentService.exe.config

  3. Open OktaAgentService.exe.config in a text editor. Find the PollingThreads entry:

    <add key="PollingThreads" value="2" />

    The default value is 2 and the maximum value is 10.

  4. Save the file and then restart the Okta AD agent service. To verify that the setting has changed, open the agent.log file at startup and observe the startup information at the bottom of the file:

    2017/07/21 06:06:22.167 Debug – TEST-SERVER-1(4) – PollingThreads: <thread number>

Can Okta integrate with AWS Managed Active Directory?

Yes, Okta can integrate with AWS Managed Active Directory with the following caveats:

  • AD Agent can't create a service account

  • AD Agent can use an existing account for a service account

  • If you don't want to use the default AWS Managed AD admin account, create a service account with granular permissions. See Okta service account permissions.

  • Pushing net new groups works as intended, but pushing AWS-managed groups isn't supported.