Active Directory integration FAQ

For more about Universal Security Groups, click here.

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 come in 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 is not selected.

Okta does not support Domain Local Groups containing members from multiple domains. Universal Security Groups with cross-domain membership are supported if there is a two-way trust established between the domains. Universal Security Groups do not support cross-forest membership.

Sign-in (JIT) scenarios

What happens when a user who is a member of a USG that does not already exist in Okta signs in to Okta?

• If the user and the USG belong to the same domain but the USG does not already 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 does not already exist in Okta, Okta creates or updates the user's profile in Okta but does not bring the USG in to Okta.

What happens when a user who is a member of a USG that already 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 does not 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 already 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 does not 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

Given a USG that resides in Domain B and contains users from Domains A and B:

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

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

If Domain A already exists in Okta, will importing Domain B bring the USG in to 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 Domains B and C users and groups are imported into Okta, the USG memberships from those domains are not synced until users from those domains sign in to Okta for the first time (as indicated by the dotted line in the diagram).

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 are members of a child distribution group. To regularly update distribution group memberships from AD to Okta, schedule an import.

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 are members of a child distribution group. To regularly update distribution group memberships from AD to Okta, schedule an import.

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

Okta treats DGs and USGs the same in this respect:

During imports, Okta does not 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 is 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 is 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 are members of a child distribution group. To regularly update distribution group memberships from AD to Okta, schedule an import.

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

Note: The term out-of-scope Organizational Unit (OU) refers to an OU that does not appear in or is not selected in the relevant OU selector. (Examples of the later type of out-of-scope OU are highlighted in yellow in the figure below.)

Some organizations administer an employee off-boarding process that involves moving users or groups to an out-of-scope OU. As detailed below, 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 is 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 is 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 are not 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 will be removed from Okta only during full imports.

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

During regular imports, Okta does not 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 are not, Okta incorrectly resolves the parent group membership during import.

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

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

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

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

It is best practice 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 , locate the OktaService account. Right-click and reset the password in AD. You will require 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 Properties > Log on tab.
   3. Chance the password to match the one you just 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 dashboard > Tools > Internet 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 will stop working if the OktaService password has not been updated here to match the password you reset in the Active Directory Users and Computers tool and the Services console.

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

• Sign in using that Admin user ID and password. Navigate to the end user account Settings > Change Password section.
• While signed in as a super admin, navigate to Admin > Directory > People > (admin account name) > Reset Password. Then select whether to send a Reset Password Link or set a Temporary password.

The Okta AD agent is outbound only. You do not have to open your firewall for any inbound agent traffic.

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

You cannot schedule a specific time of day for imports. You can schedule the frequency of imports. To schedule import frequency, go to Directory > Directory 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.

Currently there is no means for automating the agent installation.

Logs can be an invaluable resource when troubleshooting an issue, and Okta Support will often request them while working on a case. You can enable verbose logging for troubleshooting purposes.

To avoid continually generating numerous large files, Okta recommends disabling verbose logging when you finish troubleshooting.

1. On the system running the affected AD Agent, navigate 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 the value <add key="VerboseLogging" value="False" /> to <add key="VerboseLogging" value="True" />.

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

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

• AD Agent cannot create a new service account

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

• If you do not want to use the default AWS Managed AD admin account, we recommend creating a service account with granular permissions. See About Okta service account permissions.

• Pushing net new groups works as intended, but pushing AWS managed groups is not supported at this time.