Connecting to Okta using the LDAP Interface Skip to main content
https://support.okta.com/help/oktaarticledetailpage?childcateg=&id=ka00z0000019tffsau&source=documentation&refurl=http%3a%2f%2fsupport.okta.com%2fhelp%2fdocumentation%2fknowledge_article%2fconnecting-to-okta-using-the-ldap-interface-1268627519
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
1
2
3
4
5
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Connecting to Okta using the LDAP Interface
Published: May 15, 2018   -   Updated: Jun 22, 2018

 

 

okta-doc-source

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

Connecting to Okta using the LDAP Interface


The LDAP Interface allows cloud-based LDAP authentication against UD instead of an LDAP server or Active Directory (AD). Because these apps are authenticated against UD, it allows Okta to control access and centralize credentials for applications that support the LDAP authentication protocol.

The LDAP Interface is a cloud proxy that consumes LDAP commands and translates them to Okta API calls, providing a straightforward path to authenticate legacy LDAP apps in the cloud. This also enables you to centralize and manage all your LDAP resources (policies, users, apps) within Okta. You can also add seamless MFA with Okta Verify Push to your LDAP apps, providing an extra layer of security.

With typical LDAP integrations, a physical Okta LDAP agent is required. The LDAP Interface allows you to connect LDAP applications to Okta's Universal Directory without installing and maintaining physical LDAP agents:

LDAP_Interface_Arch

How is this different from Okta's LDAP Agent?

The LDAP agent is meant to synchronize identities to or from an existing LDAP directory. The LDAP interface, on the other hand, allows you to migrate certain apps off of unnecessary LDAP or AD servers and onto Okta.

But in certain cases, you may not be in a position to deprecate your LDAP or AD servers, in which case synchronization may be the more pragmatic solution. Additionally, unlike the LDAP interface which Okta manages in the cloud, the LDAP agent usually has to be deployed inside your firewall.

With the LDAP interface, authentication is done directly against Okta. In addition, the LDAP interface supports other LDAP functions like search.

All the authentication policies for the LDAP interface go through the Okta sign on policy. If you want to require that LDAP apps use MFA you can set up specific network zones for the LDAP apps that will be connecting to Okta and MFA policies for those zones. Then any connections coming from those LDAP apps will be required to use MFA. You can also do the reverse and use policies to prevent MFA from being required when accessing LDAP apps.

Key features
  • Admins are able to configure an application that currently authenticates users against an LDAPv3 directory to authenticate against Okta's LDAP interface instead.
  • Admins are also able to perform basic search functionality via LDAP SEARCH commands.
  • Only READ-only commands are supported. WRITE commands are not supported.
  • Okta must be the source of truth for the apps.
  • Searches are limited to returning 200 users or groups. Simple page results control is supported. If the search to Okta contains more than or equal to 200 entries, the LDAP server returns an error code describing the need for pagination.
  • Support for TLS 1.2 only.
Known Limitations
  • Unix or Linux-based PAM authentication is not supported.
  • Only Okta users and groups are supported. AD Groups are not returned.
  • Ability to search on memberOf results in longer search times.
  • You must use an Okta user ID. If you are using samAccountName as a log in value for your apps, authentication will fail.
  • Complex searches and wild cards are not supported, with the exception of cn=*.
Connecting to Okta using the LDAP Interface

The specific steps to connect to Okta using the LDAP protocol will vary by application. This section provides Okta-specific values you may be prompted for.

KeyValue
Host Name

<org_subdomain>.ldap.<okta or oktapreview or okta-emea>.com

Port

StartTLS on port 389

or

LDAPS on port 636.

Base DN [<ou=users or groups>],<dc=orgname>, dc=oktapreview, dc=com
User ID/Bind DN

uid=<username>,<dc=orgname>,dc=<oktapreview>,dc=com

Note: Must be an admin but can be a Read-only admin.

Password

<password for the admin user>

Note: You must ensure the admin doesn't require MFA.

Additional User DNou=Users
User Object classinetOrgPerson
User Name Attributeuid
User Password AttributeOkta does not expose passwords.
Group Object ClassgroupofUniqueNames
Group Object FilterComplex filters and wild cards are not supported with the exception of cn=*
Group Members AttributeuniqueMember
User Members Attribute

memberOf

Note: memberOf is not an indexed value. Using memberOf will result in significantly slower search times.

Example

Setting up LDAP interface for JIRA on-prem

The series of screen shots below illustrate the values required for setting up Jira on-prem. Use these as a guide for other on-prem applications that may use a similar configuration.

Note: Okta does not expose passwords.

LDAP_Interface_connection

 

LDAP_Interface_schema

LDAP_Interface_user config

LDAP_Interface_groupmembership config

Top