Skip to main content
Skip table of contents

OKTA authentication via LDAP

The following section outlines the configuration of SAFEQ Cloud integrated with OKTA through LDAP.

Add a new LDAP authentication provider in the SAFEQ Cloud authentication settings, and enter the following details:

  • Name – An internal name used for identifying the particular authentication provider configuration.
  • Domains – The domain names of the authenticating users. Add here the domain aliases that the users can use to log in. At least one domain in the list should match the domain part of the fully qualified username. If strict domain validation is disabled, SAFEQ Cloud will attempt to authenticate the user with all domains in the list when the username does not contain any domain, in the order defined in the list. If strict domain validation is enabled or the username contains a domain, SAFEQ Cloud will attempt to authenticate only with the domain in the credentials.

    For example, to allow user john.doe@okta.domain.com to log in via this Authentication provider, enter the okta.domain.com domain here.

  • Priority – A number that determines the order in which authentication providers will be called until one succeeds. Higher-priority providers will be called first.
  • Active – If enabled, the authentication provider will be used for authentication. If disabled, this authentication provider will not be searched.
  • Base DN – The point in the OKTA where searching will begin. Will apply to both user and group searching, if Group Base DN is empty.
  • Server name The address (DNS, hostname or IP) of the OKTA server to which SAFEQ Cloud Authentication Service will connect to search.
  • Port – Port used for the service, 636 must be in this case.
  • Username The username used to connect and search in the OKTA.
  • Password – Password used to connect and search in the OKTA.
  • OUs or groups – Choose how to identify groups, for access control management, default is “Groups”.
  • Bind type – Whether to bind with Plain connection, MD5 digest, or Kerberos
  • Enable SSL – Whether connection to OKTA should use SSL encryption. In this case, it must be enabled.
  • Custom attributes – Expand custom attributes to change the LDAP attributes in which username, card ID’s, ShortID’s and similar are stored. The login name and email must have “uid” value.


  • Service Which Authentication Service will communicate to this OKTA server via LDAP. If no service is already created, it can be added using the Add button.


After saving the new authentication provider, create an access control record for the users who will be authenticating via this provider. See Access Control.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.