Configure the Okta Active Directory (AD) agent: new user interface

After the AD agent is installed, you are taken to the Provisioning page for the AD appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in. to make initial configuration choices. You can come back to the Provisioning page at any time to update your configuration choices by navigating to Directory > Directory Integration > Active Directory > Provisioning.

To configure import and account settings:

Allow Okta to create users in Active Directory — Used if Okta is the profile master or will be pushing user updates to AD from another app such as Workday.

The Settings > Create User section gives Okta the ability to create users in AD. This allows you, for example, to import users from an HR system, create the users in Okta, and then have Okta create the users in AD. The HR system is the master, with Okta and AD being updated based on changes in the HR master. Or, another use case may include Okta being the source of truth for all user information and pushing those updates into AD.

To implement this functionality, you first need to create a group in Okta and then assign that group to your AD instance. When users are added to the group, they are also created in AD. A common scenario is to use group rules in this kind of flow to add users to the AD provisioning group automatically.

To configure Okta to create users in AD:

1. If you are not on the Settings page, navigate to Directory > Directory Integration > Active Directory > Settings.
2. Scroll to the Provisioning Features > Create Users section.
3. Click Enable.
4. For Activation email recipient, enter the email address of the Okta adminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. who should receive the activation email with the Okta end user's password. The admin is responsible for giving the end user their Okta password.
5. Select the AD username format. This is the format in which AD expects to Okta to create the username in AD. The Custom option allows you to format the AD username using a custom expression language. For details, see Using Expressions (Transformations).
6. AD common name format – Specify a default AD common name format.

7. Exclude AD username update – If you select this option, Okta does not update the user names of existing AD accounts that are Okta mastered when you change the default username format. You can still provision new AD accounts from Okta.

8. Scroll to the bottom of the page and click Save.

You can come back to the Provisioning > To Okta page at any time to update your configuration choices by navigating to Directory > Directory Integration > Active Directory > Provisioning.

This involves making decisions about:

• Import settings — To add users and groupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with groups. from a designated Active Directory domainA domain is an attribute of an Okta organization. Okta uses a fully-qualified domain name, meaning it always includes the top-level domain (.com, .eu, etc.), but does not include the protocol (https). into Okta. This includes which user and group OUs to import from, whether to use Just-in-Time (JIT) provisioning to import users into Okta, how often to schedule imports from AD to Okta, and whether to send activation emails to new end usersIn Okta literature, we generally refer to "end users" as the people who have their own Okta home page (My Applications), using chiclets to authenticate into all of their apps. End users do not have any administrative control. When we refer to "users" we are generally referring to the individual(s) who have administrative control..
  

User name format notes:

• During import Okta presents you with options for the username format. This value is used to associate the user in AD to Okta, therefore it's important to choose the correct value as this affects how your users sign in to Okta. By default Okta uses the Okta user profile username during delegated authentication. For example, if the AD app-user username is samAccountName and the Okta user profile username (login field) is UPN, then Okta will use UPN to log in the user.

You can keep it consistent with device sign-in by standardizing on the format your users use to sign into their devices.

• If you are on AD domain functional level of 2003, your AD usernames must in the domain name format. Users must have a UPN that contains a domain.name format.
• Automatic matching of AD to Okta user accounts — To establish matching criteria (or rules) to specify how an imported user should be mapped to an existing Okta user. Clearly defining rules for matching helps to prevent multiple instances for the same user from being created.

To configure import and account settings:

1. If you are not on the Provisioning > To Okta page, navigate to Directory > Directory Integration > Active Directory > Provisioning > To Okta.
2. In the General section, click Edit and make selections from the following options:

   1. Schedule Import  — Determine how often you want Okta to import users from AD.

      Select never to leverage scheduled imports to keep user profiles and groups in sync without importing new users from your directory. Use it when you only want to create new users in Okta via JIT, not via imports, yet continue to use imports to sync groups.

      Note: Following a successful import, under specific conditions Okta automatically sends an email to designated administrators. The email details the number of users and groups scanned, added, updated, or removed during the import. Okta only sends the email if the scan detects any new users or groups, or changes to any existing user profile or group membership.

   2. This is an Early Access feature. To enable it, please contact Okta Support.

      Note: Orgs created after October 19th (Preview) or October 25th, 2017 (Production) may see slightly different import and provisioning options in the user interface elements described below. These changes will be rolled out to orgs created before these dates at a later date, which will be announced in the Release Notes. For details about the import and provisioning changes, see AD Updated Profile Mapping options.

      Okta username format— Choose from one of the following options:

      Important: It is critical that the username format selected here be the correct format when you first import users. Changing the value can cause errors for existing users.

      • Email address  — End users will sign in with their email addresses as their Okta username.
      • SAM Account name  — Okta combines the SAM Account Name with the AD domain to generate the Okta username. For example, if the SAM Account Name is jdoe and the AD domain is mycompany.okta.com, then the Okta username is jdoe@mycompany.okta.com.
      • User Principal Name (UPN)  — Use the UPN from AD.
      • Custom  — If you wish to use a custom username to sign in to Okta, use the Custom option and the Okta Expression language to map the Okta username format. You can preview your changes to validate your mapping expression. Enter the name of a user to preview the mapping.Screenshot

      Note: All Okta users can sign in by entering the alias part of their user names as long as it maps to a single user in your organization. For example, jdoe@mycompany.okta.com could sign in using jdoe.
      

   3. JIT Provisioning  — Just In Time (JIT) provisioningusers are created/updated on the fly using the SAML attributes sent as part of the SAML response coming from the Identity Provider. The A user is created during initial login to the Service Provider and updated during subsequent logins. Turning on JIT Provisioning is normally a configuration value in the Service Provider. enables automatic user account creation in Okta the first time a user authenticates with AD Delegated Authentication, as well as updates to existing user profiles.

      The security groups to which the user belongs are also imported if the group belongs to a selected OU. If a user signing in does not belong to a selected OU, the sign in fails. If you enable JIT, Delegated Authentication must also be enabled.This option can be used with or without scheduled imports. For details about JIT and AD domain scenarios, see FAQ: Okta and AD Groups.

      Note: There are membership inconsistencies that can occur between “regular” imports and JIT provisioning. These membership anomalies may occur when using nested groups. During regular imports, a child group that is outside the scopeA scope is an indication by the client that it wants to access some resource. of an AD OU or LDAPLightweight Directory Access Protocol (LDAP) is a lightweight client-server protocol for accessing directory services, specifically X.500-based directory services. LDAP runs over TCP/IP or other connection oriented transfer services. object filter cannot be detected. If a parent group is within an OU/object filter scope but its child groups are not, the parent group membership is incorrectly resolved during import. JIT provisioning would correctly resolve these memberships to the parent group because its function only detects "flat" memberships. 

   4. USG support  — Enable this to ignore domain boundaries when importing group memberships for your end users. This assumes that the relevant domains are connected in Okta. You must also deploy an AD agent for every domain in your forest that contains the USG object that you want to sync with Okta. Each connected domain then imports its groups. When a user’s group memberships match any groups that were imported (from any connected domain in the forest), Okta syncs the memberships for the user to each group.  Only groups from connected domains are imported. This setting requires JIT provisioning.
   5. Do not import users — Select this option to prevent imports from AD from creating, updating or deleting users in Okta. Only groups will be updated during imports.

   6. Activation emails  — Check this option to prevent Okta from sending activation email to new users. Admins can activate users. Activation emails can only be suppressed when a domain is using delegated authentication.

      Tip: We recommend that you select not to send activation emails while you are doing the initial AD integration and configuration in your Preview environment. This prevents end users from receiving activation emails before you are ready for them to begin enrolling in and using Okta.

   7. Max Import Unassignment  — Accept the default 20% or choose a custom per cent. Halts any import which exceeds this number of app unassignments. This action prevents accidental loss of user accounts. This setting affects all apps with imports enabled. For details, see Import safeguard.
   8. Click Save.
3. In the User Creation & Matching section, click Edit and make selections from the following options to select the conditions under which imported users will be identified as matching existing Okta users.

   Matching rules are used in the import of users from all apps and directories that allow importing. If there is an existing Okta account, AD allows you to import and confirm users automatically. Active Directory, OPP, and all provisioning-enabled apps support automatic importation and confirmation of users into Okta.  Establishing matching criteria (or rules) allows you to specify how an imported user should be mapped to an existing Okta user. Clearly defining rules for matching helps to prevent multiple instances for the same user from being created.

   Note: This feature does not apply to CSV-imported user lists.

   1. Imported user is an exact match to an Okta user if:
      • Okta username format matches
      • Email matches
      • The following combination of attributes match — Select from the list of options. Choose any combination from the list of options to establish your criteria. For the new imported user to be considered an exact match, each option that you select must be true.
   2. Allow partial matches  — Partial matching means that the first and last name of an imported user matches that of an existing Okta user, but the user’s username or email address do not. Choosing this option legitimizes this scenario.
   3. Confirm matched users  — Check to automatically confirm exact or partial matches. Leaving them unchecked requires that matches are confirmed manually; once the matching status is established. If manually confirmed, users are activated on the People page (Directory > People)
   4. Confirm new users  — Check to specify that once the matching status indicating a new user is established, they are confirmed or activated automatically. Leaving them unchecked requires that new users are confirmed or activated manually on the People page (Directory > People).
   5. Click Save.
4. In the Profile & Lifecycle Mastering section:
   1. Click Edit.
   2. Allow Active Directory to master Okta users  — Enable this option to allow AD to control the profiles of assigned users. User profiles will be read only in Okta. Profiles are managed based on Profile MasterA profile master is an application (usually a directory service such as Active Directory, or human capital management system such as Workday) that acts as a source of truth for user profile attributes. A user can only be mastered by a single application or directory at any one time. For more details, see the Profile Master page. When users are mastered by attribute, we call this attribute-level mastery (ALM). ALM delivers finer grain control over how profiles are mastered by allowing admins to specify different profile masters for individual attributes. Profile mastering only applies to Okta user profiles, not app user profiles. For more details, see Attribute Level Mastering. priority.
   3. Click Save.

5. The final section allows you map your Okta attributes and set their values based on values stored in Active Directory. The attributes listed in the table are your Okta attributes.

   You will see a list of AD attributes that Okta has discovered and attempted to map to the default Okta user profile attributes. You can edit these mappings by clicking on the pencil icon.

   Define your Okta Attribute Mappings For details, see Map profile attributess.

To configure integration settings:

1. If you are not on the Provisioning > To Okta page, navigate to Directory > Directory Integration > Active Directory > Provisioning > Integration.
2. In the Import Settings section:
   1. User OUs connected to Okta  — The agent can only access the OUs you select to import end users. If you need to modify the OU selection made during the agent install, make the changes here.

   2. This is an Early Access feature. To enable it, please contact Okta Support.

      Optional  — Define user filters to perform granular imports from Active Directory. Create syntax queries to selectively import users matching the criteria that you specify.

      Caution: Changing the default filter queries can result in deprovisioning users. To avoid unintended results, Okta strongly recommends that you test these filters in your directory environment to make sure that the results match your expectations.

      Default queries:

      • User filter – sAMAccountType=805306368
      • Group filter – objectCategory=group

      Note: Back-linked attributes, such as memberOf are computed attributes and are not actually stored in your Active Directory database. As a result, Okta will not see changes to the user object and perform an import operation when these changes occur. It is recommended not to use computed attributes as mapped attributes into Okta, especially if you require changes in downstream systems as a result of a change in the attribute. This may lead to inconsistent data between your on-premises Active Directory and Universal DirectoryUniversal Directory enables you to store an unlimited amount of users and attributes from applications and sources like AD or HR systems. Any type of attributes are supported including linked-objects, sensitive attributes, and pre-defines lists. All of it accessible by all apps in our OIN catalog, over LDAP or via API.. More information is available from https://msdn.microsoft.com/en-us/library/cc223384.aspx

   3. Group OUs connected to Okta  — The agent can only access the OUs you select to import groups. If you need to modify the OU selection made during the agent install, make the changes here.

   4. This is an Early Access feature. To enable it, please contact Okta Support.

      Optional  — Define group filters to perform granular imports from Active Directory. Create syntax queries to selectively import users matching the criteria that you specify.

      Caution: Changing the default filter queries can result in deprovisioning users. To avoid unintended results, Okta strongly recommends that you test these filters in your directory environment to make sure that the results match your expectations.

      Default queries:

      • User filter – sAMAccountType=805306368
      • Group filter – objectCategory=group

      Note: Back-linked attributes, such as memberOf are computed attributes and are not actually stored in your Active Directory database. As a result, Okta will not see changes to the user object and perform an import operation when these changes occur. It is recommended not to use computed attributes as mapped attributes into Okta, especially if you require changes in downstream systems as a result of a change in the attribute. This may lead to inconsistent data between your on-premises Active Directory and Universal Directory. More information is available from https://msdn.microsoft.com/en-us/library/cc223384.aspx

3. Click Save.

4. In the Delegated Authentication section:

   1. Enable delegated authentication if you want Active Directory to authenticate your users when they sign in to Okta. A user's Okta credentials are the same as their Active Directory credentials when delegated authentication is on.

      Instance-level Del Auth is optimized for use in environments with multiple AD instances. It allows admins to delegate authentication on a per AD-instance level to support more granular authentication scenarios such as the following:

      • Configure Okta to be the authentication master for users in some AD instances.
      • Configure AD to be the authentication master for users in the remaining AD instances (meaning users sign-in using their Windows credentials).
      • Continue to rely on Okta to provision to all AD instances

   2. Click Save Settings.