UC_LDAP_EXAMPLE - LDAP Connection Variable

This variable contains the specifications for the LDAP connection. It is supplied in Client 0 and its settings apply globally for the whole AE system. It contains all specifications for the connection to the Active Directory or Oracle Directory Server. You can also synchronize LDAP data over TLS/SSL.

The DIV_VARIABLES folder contains the UC_LDAP_EXAMPLE variable which you can duplicate and use as a template. There are two different ways of configuring the connection to your LDAP server, depending on the directory you use (Active Directory or Oracle Directory Server):

For Active Directory

Name the copy UC_LDAP_Domain. For example, if the domain name is SMITH, the variable should be called UC_LDAP_SMITH.
For Oracle Directory Server

User object names are composed of name and department. The copy of the variable can be renamed to UC_LDAP_department. Each department requires a separate variable. Using this method requires the domain to be specified in the DOMAIN_ALIAS key.

You would use this configuration when the domain name (or fully qualified domain name) does not meet the object naming conventions. For domain alias, we recommend using the fully qualified domain name.

Note: German umlauts cannot be used in domain names.

By default, the domain indicated in the name of the variable is used. You can also specify the alias in the DOMAIN_ALIAS key which is then used instead of the domain name.

This variable includes the following keys:

AUTHENTICATION_METHOD

Depending on the LDAP Server configuration, authentication requires realm data or the domain name.

Allowed values: 0, 1 and 2
- 0 - Authentication first uses the realm data of the LDAP Server . A second attempt to log on is made with the domain name if the first attempt fails. The LDAP connection remembers the successful login method and uses this one first for future logins. Each attempt to authenticate is regarded as a login attempt. Whether an attempt to log on failed because of incorrect user data or due to a wrong login type is irrelevant. Thus, entering an incorrect password several times has the effect that a user is locked earlier.
- 1 - The response to the LDAP Server is sent with the realm data of the LDAP Server. This is the default method which should be accepted by every LDAP Server.
- 2 - The domain name is used to respond to the LDAP Server.
Default value: 1

Restart required: No
DOMAIN_ALIAS

Domain alias or domain name if the department has been specified in the name of the variable.

Restart required: No
SERVER

Name and port number of the LDAP Server

Format: Server name:Port number

Separate several LDAP Servers with a semicolon. The Automation Engine then attempts to establish a connection to the first LDAP Server. If it fails, a second attempt is made with the second LDAP Server.

Restart required: No
SYNC_LOGIN

This key specifies the name of the Login object that contains the user credentials the Automation Engine uses when communicating with the LDAP server.

You can only use the Synchronize button in the General page of a User object to establish the LDAP connection when you use a Login object that has been created specially for this purpose and contains the necessary credentials. For more information, see Synchronizing LDAP using Technical User Credentials.

Restart required: No
USE_DISTINGUISHED_NAME

Access via DN (distinguished name)

Note: The password remains unencrypted when using DN.

Allowed values: Y and N
- Y - The connection to the LDAP system is established via DN.
- N - DN is not used.
Default value: N

This function depends on the setting of the VERSION key (see below). If it is set to 1, the password remains unencrypted. If it is set to 2, the connection and the password are encrypted, since LDAP over TLS/SSL is used.

Important! In the Automic Automation Kubernetes Edition, you can only use the Java work process (JWP) to enable LDAP. This means the VERSION key is set to 2.

The LDAP connection uses the domain name when a user logs on for the first time. By doing so, it retrieves the corresponding Distinguished Name (DN). For all subsequent login attempts it uses the DN because this method is the quicker one. If it fails, the LDAP connection automatically continues using the domain name.

(Oracle Directory servers) The DN (distinguished name) is always used.

Restart required: No
USR_EMAIL1

LDAP attribute from which the email address should be read. For example, "mail" in the Microsoft Active Directory.

Restart required: No
USR_FIRSTNAME

LDAP attribute from which the first name should be read. For example, "givenName" in the Microsoft Active Directory.

(Oracle Directory servers) This setting is irrelevant, as attributes there are always "givenName" and "sn".

Restart required: No
USR_LASTNAME

LDAP attribute from which the last name should be read. For example, "sn" in the Microsoft Active Directory.

(Oracle Directory servers) This setting is irrelevant, as attributes there are always "givenName" and "sn".

Restart required: No

Note: The keys that start with USR define the LDAP attributes from which the LDAP connection should read the email address, as well as the first and last name when synchronizing user data. All three information types are stored in the User object.
VERSION

Defines if an existing C-Modul or the Java work process (JWP) is used to enable LDAP.

Allowed values: 1 and 2
- 1 - uses the C-based LDAP connection, TLS/SSL is not possible
- 2 - uses JWP, LDAP over TLS/SSL is possible
Default value: 1

Important! In the Automic Automation Kubernetes Edition, you can only use the Java work process (JWP) to enable LDAP. This means the VERSION key is set to 2.

Restart required: No
TLS

Note: This key is used only if the VERSION key is set to 2.

Allowed values: Y[es] and N[o]
- Y - The JWP creates a connection to the LDAP server over TLS
- N - The JWP creates a connection to the LDAP server without TLS
Restart required: No