Configure the Okta Java LDAP Agent


To integrate Okta with your 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. directory, install and configure the Okta Java LDAP agentA software agent is a lightweight program that runs as a service outside of Okta. It is typically installed behind a firewall and allows Okta to tunnel communication between an on-premises service and Okta's cloud service. Okta employs several agent types: Active Directory, LDAP, RADIUS, RSA, Active Directory Password Sync, and IWA. For example, users can install multiple Active Directory agents to ensure that the integration is robust and highly available across geographic locations.. LDAP integration allows 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. to authenticate to Okta using their LDAP credentials without replicating those credentials into the cloud. In addition, Okta can import user accounts and attributes into the cloud service to improve performance and support complex scenarios. Okta’s LDAP integration helps organizations leverage current identity directory investments when controlling access to Okta-protected resources.

Note: If you find the instructions in this topic do not match what you see in your user interface, refer to Configure the Okta Java LDAP Agent: new user interface instead.

REQUIREMENTS




Configuring your LDAP settings

After you install the LDAP agent, you must continue the configuration through 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. Dashboard as described in the following steps:

LDAP Configuration

Import Settings

Provisioning Features

LDAP Configuration

  1. Return to Directory > Directory Integrations.
  2. Click the LDAP agent from the list of directories. It should be marked Not yet configured.
  3. In Set Up LDAP > Configure Directory Mappings, configure the following settings:
    • LDAP Version — Select your vendor. Vendor-specific configuration templates are provided and pre-populate configuration settings for you. If your LDAP vendor is not on the list, complete the configuration fields manually. Because each LDAP environment is unique, you must confirm the default values using an LDAP browser like Apache Directory Studio. Note that not all configuration settings must have values.
    • Unique Identifier Attribute — Specifies the unique immutable attribute of all LDAP objects that will be imported (users and groups). Only objects possessing this attribute can be imported into your Okta org. Okta populates this field automatically based on your chosen LDAP version. You can change the auto-populated value during initial setup. Note: if your LDAP server implements RFC 4530, make sure to enter entryuuid in this field. For AD LDS, use objectguid.
    • DN Attribute — The attribute on all LDAP objects containing the Distinguished Name value.
  1. In the User section, configure the following settings:
    • User Search Base — The DN of the container for user searches (that is, root of the user subtree). This is the base DN of the container that holds all users that will be imported into your Okta org. For example: cn=Users, dc=example, dc=com.
    • Object Class — The objectClass of a user that Okta uses in its query when importing users. For example, inetorgperson, posixaccount, posixuser.

    • Auxiliary Object Class — You can input a comma-separated list of auxiliary objectClasses. Okta will use these in its query when importing users. For example, auxClass1,auxClass2.
    • User Object Filter — By default, Okta auto-populates this field with the objectClass (objectClass=<entered objectClass name>). This must be a valid LDAP filter.

      Use standard LDAP search filter notation (RFC 2254). For example:

      (&(givenName=Bab*)(|(sn=Jensen)(cn=Babs J*)))

      The same filter capability is also in place for Group Objects.

    • Account Disabled Attribute — The user attribute that indicates whether or not the account is disabled for the user in Okta. If this attribute equals the value specified in the Account Disabled Value field, we deactivate the user account.
    • Account Disabled Value — The value that indicates that the account is locked (for example, TRUE).
    • Password Attribute — The user password attribute.
    • Password Expiration Attribute — Different LDAP directories have different attribute names for password and password expiration. If you select one of the pre-populated directories, Okta will auto-fill the correct default value. If your directory is not in the supported list, refer to your LDAP server documentation or configuration and use that value for password expiry. This attribute is usually a Boolean value, but may vary depending on your LDAP server.
    • Extra Attributes — You can specify up to four additional attributes to be imported from LDAP.
  1. Complete the Group or Role section. Typically, only one of these is used.

    Group

    • Group Search Base — The DN of the container for group searches (that is, root of the group subtree) that holds all groups that will be imported into your Okta org. For example: ou=groups, dc=example, dc=com.
    • Group Object Class — The objectClass of a group that Okta uses in its query when importing groups. For example, groupofnames, groupofuniquenames, posixgroup.
    • Group Object Filter – By default, Okta auto-populates this field with the objectClass of the group (objectClass=<entered objectClass name>).
    • Member Attribute — The attribute containing all the member DNs.
    • User Attribute — Okta uses the member attribute on the group object to determine the user group memberships at runtime. Unless your group object and group filter is explicitly posixGroup and (objectclass=posixGroup), leave the user attribute field empty. If you are using posixGroup, we recommend that you configure the member attribute value to memberUID and the user attribute value to uid.

      Example 1

      ① If the specified group object and group filter is posixGroup  . . . ,

      ② then enter memberUid in the User Attribute field.

      Example 2

      ① If the specified group object and group filter is something other than posixGroup . . . ,

      ② then leave the User Attribute field blank.

    Role

    • Object Class – The objectClass of a role.
    • Membership Attribute – The attribute of the user object that indicates role membership (that is, containing the role DNs).
  1. Validate your configuration settings.
    1. Select an Okta username format.

      When you import users from LDAP, Okta uses these settings to generate the Okta username that your users will use to log in to Okta.

      Note: Okta requires that valid user names be in an email format. Configuring these options correctly ensures that your user names satisfy this requirement.

      Email address option

      Select this option if you want your users' LDAP email address to be their Okta username. Note: Email addresses must be unique in LDAP.

      For example:

      1. If email addresses in LDAP are user.1234@example.com . . . ,
      2. and you select the Email address Okta username format . . . ,
      3. enter user.1234@example.com in the Username field.

       

      User Id (UID) option

      Select this option only if the UID value in the LDAP directory is already formatted as an email address.

      For example:

      1.  If the UID in LDAP is already formatted as an email address like user.1234@example.com . . . ,
      2. and you select the User Id (UID) Okta username format . . . ,
      3. enter user.1234@example.com in the Username field.

       

      User Id (UID) + Configurable Suffix option

      Select this option only if the UID value in LDAP lacks an email suffix and you want end users to log in using a configurable email suffix.

      For example:

      1. If the UID in LDAP is user.1234 . . . ,
      2. and you select the User Id (UID) + Configurable Suffix Okta username format . . . ,
      3. enter yourconfigurablesuffix.com in the Configurable Suffix field . . .
      4. enter user.1234@yourconfigurablesuffix.com in the Username field.

       

      User Id (UID) @ 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). option

      Select this option only if the UID value in LDAP lacks an email suffix and you want Okta user names to include your company's domain name as the email suffix.

      For example:

      1. If the UID in LDAP is user.1234 . . . ,
      2. and your company's domain name is yourdomainname . . . ,
      3. and you select the User Id (UID) @ Domain Okta username format . . . ,
      4. enter user.1234@yourdomainname.com in the Username field.

      Custom option

      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. Expressions allow you to concatenate attributes, manipulate strings, convert data types, and more. Okta supports a subset of the Spring Expression Language (SpEL) functions. Find a comprehensive description of the supported functions under Okta Expression Language.

    1. Enter a Username.

      Enter the username of a user in the specified username format. Since the username that you enter uniquely identifies a single user in your LDAP directory, the query that Okta executes will retrieve only your specified user and the following details about the user. Validate that all returned details are correct.

      • Status
      • UID
      • Unique ID
      • Distinguished Name
      • Full Name
      • Email
      • Groups – All the groups of the specified Group Object Class within the Group Search Base of which this user is a member. If the expected groups are not listed here, group imports might fail later.
    1. Click Test Configuration.

      If your configuration settings are valid, the message Validation successful! displays along with information about the returned user object. If there is a problem with your configuration, or if the user is not found, you are prompted to review your settings.

  1. When your settings are successfully validated, click Next and then Done to complete LDAP configuration.

After validating your settings, in the background Okta begins the LDAP schema discoveryAbility to import additional attributes to Okta process.

Import Settings

Click Import Settings under LDAP Settings on the left side of the page and configure the following settings:

Import Matching Rules

If there is an existing Okta account, LDAP allows you to import and confirm users automatically. Select the automatic confirmation option that matches the policies of your organization:

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

Matching rules are used in the import of users from all apps and directories that allow importing. Establishing matching criteria allows you to specify how an imported user should be defined as a new user or mapped to an existing Okta user.

The imported user is an exact match to an Okta user if: the match criteria that establishes whether an imported user exactly matches an existing Okta user. 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. Note that if you choose the third option, the first and second choices are disabled.

Allow partial matches: Partial matching occurs when 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.

Confirm matched users: Select to automate the confirmation or activation of existing users. Unchecked, matches are confirmed manually.

Confirm new users: Select to automate the confirmation or activation of a newly imported user. If this option is selected, you can uncheck it during import confirmation. Note that this feature does not apply for users who already exist in Okta.

Incremental Import Settings

Maximum clock skew  — Incremental import relies on the modifyTimestamp attribute to determine whether an LDAP entry has been imported. However, the system clock on some on-premises LDAP servers could go backward, causing some updates to be missed. To prevent missed updates, set the clock skew to a value that is the maximum potential clock drift of the server.

Note: To improve the performance of incremental import, the modifyTimestamp attribute should be indexed on your LDAP server.

Provisioning Features


What's Next

Now that you have installed the Okta LDAP agent and successfully integrated with LDAP, your next step is to map your LDAP attributes to their corresponding Okta user profile attributes. For information about Profile Attributes and Mappings, see Profile Editor and Profile Mapping.


Top