LDAP configuration

Last Updated : Jun 08, 2026 |

If you do not complete LDAP configuration during the initial Avaya Aura® Device Services setup, then you can complete it later using the Avaya Aura® Device Services administration portal. Some administration options, such as configuring multiple LDAP directories, are only available on the administration portal. For more information, see the LDAP server management section in Administering Avaya Aura® Device Services.

Warning:

Changing the LDAP configuration parameters, other than Bind DN and Bind Credential, when they are configured, might invalidate the existing user data. For example, changing how user roles are found can remove one or more roles from the existing user, which will block the user from accessing the Avaya Aura® Device Services system. In addition, do not change the server URL unless you need to switch the configuration to another replicated instance of the current LDAP directory. In all the other cases, you must reinstall the Avaya Aura® Device Services system.

The following image shows the LDAP Configuration screen in the Avaya Aura® Device Services configuration utility:

LDAP parameters configured using the configuration utility.

Item name

Description

Equivalent properties file parameter

Use LDAP for Authentication

Specifies whether this LDAP server is used for authentication.

This check box is only available when OAuth is enabled.

—

Use for Contact Search

Specifies whether this LDAP server is used for the contact search.

The following options are available:

  • Y (yes): To enable the contact search functionality.

  • n (no): To disable the contact search functionality.

If you use the Onboard Open LDAP server, this option is enabled by default.

LDAP_CONTACT_SEARCH

Use DNS

Specifies whether Avaya Aura® Device Services uses DNS SRV records to discover the LDAP server.

  • If the check box is selected, Avaya Aura® Device Services uses the domain name specified in the URL for LDAP server field to discover all LDAP servers associated with this domain name in DNS SRV records.

  • If the check box is not selected, Avaya Aura® Device Services uses the IP address or FQDN specified in the URL for LDAP server field to discover the LDAP server.

Load LDAP properties from file

The Load LDAP properties from file menu contains an item called Path to properties file.

You can create a Java properties file that contains the LDAP properties instead of entering the LDAP configuration settings manually. The Path to properties file option is for configuring the absolute path to this file.

The LDAP properties file must contain the equivalent properties file parameters specified in this table.

The default value for this setting is <install_dir>/config/ldap.properties, where <install_dir> is the Avaya Aura® Device Services installation directory.

pathToLdapPropertiesFile

Import Secure LDAP trusted certificate

The Import Secure LDAP trusted certificate menu contains the following items:

  • Certificate file: The path and filename for the LDAP trusted certificate. The certificate file must be in the .PEM format.

    If you want to configure secure LDAP for onboard Open LDAP, use the nginx certificate located at /etc/openldap/certs/nginx.crt.

You cannot import a certificate if:

  • The certificate contains an unsupported critical extension.

  • The certificate expired.

  • The start date of the certificate is in the future.

Important:

Only configure these settings if you need a Secure LDAP connection.

LDAP_TRUSTSTORE_CERTFILE

LDAP_TRUSTSTORE_PASSWORD

Directory Type

The LDAP directory type of the enterprise.

The supported directory types are the following:

  • Azure Active Directory

  • IBM Domino Server 7.0 and 8.5.3

    Note:

    The Domino server must be patched to support TLS, so Avaya Aura® Device Services can connect to the Domino server through secure LDAP (LDAPS). For a list of supported patch fixes, see https://www-10.lotus.com/ldd/dominowiki.nsf/dx/IBM_Domino_TLS_1.0.

  • Microsoft Active Directory 2012, 2016, and 2019

  • Microsoft Active Directory Lightweight Directory Services (LDS) 2012

  • Novell e-Directory 8.8

  • OpenLDAP 2.4.44 and 2.4.46

  • Oracle Directory Server Enterprise Edition 11g Release 1 (11.1.1.7.0)

For detailed information about supported product releases, see the Avaya Compatibility Matrix.

ldapType

URL for LDAP server

The URL for gaining access to the LDAP server. This is the mandatory setting.

The URL for LDAP server parameter is unavailable if you selected the Use DNS check box.

The URL must have one of the following formats: 
ldap://<LDAP server FQDN or IP address>:<port>
ldaps://<LDAP server FQDN>:<port>
For example: 
ldap://myserver.mycompany.com:3268
ldaps://myserver.mycompany.com:3269

The protocol can be LDAP or LDAPS, depending on the LDAP server type. If you are using LDAPS, you cannot use IP addresses in the URL.

Important:

If FIPS is enabled, use the LDAPS protocol to access the LDAP server.

If the LDAP server uses IPv6, use the server FQDN in the URL.

If you are configuring LDAPS for onboard Open LDAP, use the local domain name as follows: 
ldaps://localhost.localdomain:3269

For Microsoft Active Directory, use the catalog LDAP ports.

The default global catalog LDAP port values are 3268 for LDAP and 3269 for LDAPS.

The default domain LDAP ports values are 389 for LDAP and 636 for LDAPS.

Note:

If an FQDN is used to specify the LDAP server, the enterprise might map the FQDN to multiple, replicated LDAP servers using the DNS round-robin mechanism as an attempt for load-balance and for redundancy purpose. Sporadic authentication failures can occur if one of the LDAP servers is offline and the DNS round-robin mechanism resolves the FQDN to the IP of the LDAP server that is offline.

If this outcome cannot be tolerated, a more reliable load-balancing mechanism, such as a dedicated load-balancer in front of the LDAP servers, will be needed.

For Active Directory, use the Global Catalog service port instead of the default LDAP/LDAPS ports.

Important:

If you are using the global catalog ports, you must configure attribute replication to the global catalog. For more information, see LDAP attributes replication to the global catalog.

ldapUrl

Bind DN

The Distinguished Name (DN) of the user that has read and search permissions for the LDAP server users and roles. This is the mandatory setting.

The format of the Bind DN depends on the configuration of the LDAP server.

Note:

Even though the parameter name is Bind DN, the format of its value is not limited to the DN format. The format can be any format that the LDAP server can support for LDAP bind.

For example: for Active Directory, you can use domain\user, user@domain, as well as the actual DN of the user object.

bindDN

Bind Credential

Specifies the password of the administrative user.

The maximum password length depends on the LDAP server type that you use in your deployment.

The supported characters are:

  • Lowercase letters: a to z

  • Uppercase letters: A to Z

  • Numerics: 0 to 9

  • Special characters are supported.
Important:

If you configure the LDAP settings using the properties file, you must enter the Bind Credential manually by running the configureAADS.sh script.

UID Attribute ID

The User ID attribute name, as determined by the LDAP server configuration. This is the mandatory setting.

This parameter is used for searching users in the LDAP server.

For example: sAMAccountName

Note:

When the UID attribute is set to mail on onboard Open LDAP, use Apache Directory Studio to set the email value for the Open LDAP administrative user. This enables the administrative user to log in to the Avaya Aura® Device Services web administration portal using their email.

uidAttrID

Base Context DN

The DN of the context used for LDAP authentication.

For example: ou=aadsusers,dc=example,dc=com

baseCtxDN

Administrator Role

The list of LDAP roles that match the Avaya Aura® Device Services Administrator role.

For example:

If the role is configured as AADSAdmin,AADSxyz, any user whose list of roles contains AADSAdmin or AADSxyz is mapped to the Avaya Aura® Device Services Administrator role.

Note:

The values of the roles are case-sensitive when they are mapped to the application roles. So they must match exactly to the roles name found for a user in order for the mapping of the LDAP roles to the Avaya Aura® Device Services application roles to succeed.

Important:

To avoid situations when potential loss of credentials could impact the administration tasks, Avaya recommends creating more than one user account with administrator privileges.

adminRole

Auditor Role

The list of LDAP roles that match the Avaya Aura® Device Services Auditor role.

For example:

If the Auditor role is configured as AADSAuditor,AADSxyz, any user whose list of roles contains the AADSAuditor or AADSxyz role is mapped to the Avaya Aura® Device Services AUDITOR role.

Note:

The values of the roles are case-sensitive when they are mapped to the application roles. So they must match exactly to the roles name found for a user in order for the mapping of the LDAP roles to the Avaya Aura® Device Services application roles to succeed.

auditorRole

User Role

The list of LDAP roles that match the Avaya Aura® Device Services User role.

For example:

If the User role is configured as AADSUser,AADSxyz, any user whose list of roles contains the AADSUser or AADSxyz role is mapped to the Avaya Aura® Device Services USER role.

Note:

The values of the roles are case-sensitive when they are mapped to the application roles. So they must match exactly to the roles name found for a user for the mapping of the LDAP roles to the Avaya Aura® Device Services application roles to succeed.

usersRole

Services Administrator Role

The list of LDAP roles that match the Services Administrator role.

For example:

If the User role is configured as AADSUser,AADSxyz, any user whose list of roles contains the AADSUser or AADSxyz role is mapped to the Avaya Aura® Device Services Services Administrator role.

Note:

The values of the roles are case-sensitive when they are mapped to the application roles. So they must match exactly to the roles name found for a user for the mapping of the LDAP roles to the Avaya Aura® Device Services application roles to succeed.

serviceAdminRole

Services Maintenance and Support Role

The list of LDAP roles that match the Maintenance and Support role.

For example:

If the User role is configured as AADSUser,AADSxyz, any user whose list of roles contains the AADSUser or AADSxyz role is mapped to the Avaya Aura® Device Services Maintenance and Support role.

Note:

The values of the roles are case-sensitive when they are mapped to the application roles. So they must match exactly to the roles name found for a user for the mapping of the LDAP roles to the Avaya Aura® Device Services application roles to succeed.

serviceMaintenanceRole

Security Administrator Role

The list of LDAP roles that match the Avaya Aura® Device Services Security Administrator role.

For example:

If the role is configured as AADSSecurityAdmin,AADSxyz, any user whose list of roles contains AADSSecurityAdmin or AADSxyz is mapped to the Avaya Aura® Device Services Security Administrator role.

Note:

The values of the roles are case-sensitive when they are mapped to the application roles. So they must match exactly to the role name found for a user in order for the mapping of the LDAP roles to the Avaya Aura® Device Services application roles to succeed.

securityAdminRole

Advanced LDAP parameters

The menu that contains advanced LDAP parameters to configure depending on the structure of the LDAP server.

Test User

If you select testUser and select Apply, this option is used to validate the following LDAP settings:

  • Verifies that the user is searchable with a given base DN and search filter.

  • Lists the group to which the user belongs — user, administrator, or auditor.

  • Validates the values for Role Attribute ID and Role Name Attribute.

  • Verifies the Last Updated Time attribute, role filter syntax, and active users search filter syntax.

The configuration is not saved if any of these validations fail.

The testUser parameter is optional. If you do not specify a value, the system skips validation and directly saves the configuration in the database.

testUser