User Authentication Using LDAP

A NuoDB database user can either be authenticated using a password created for that user within NuoDB, or it can be authenticated externally using an LDAP server.

A NuoDB database user that is authenticated locally:

CREATE USER username PASSWORD 'password';

A NuoDB database user that is authenticated via an LDAP server:

CREATE USER username EXTERNAL;

Using authentication via an LDAP server allows the DBA to minimize administrative duties, since your users will be able to reuse their existing account to access their NuoDB database. LDAP can also provide management features such as password expiry (and other password definition policies) not available for internal users.

You cannot have more than one user with the same username (regardless of how that user is defined).

See CREATE USER for more information.

Users authenticated by NuoDB rely on tables inside the database (see the USERS and PASSWORDS System tables.) If you restore a database from a backup, you will also be restoring usernames, passwords, roles and grants as they were when the backup was taken. Another advantage of using LDAP is that usernames and passwords are independent of NuoDB.

Network Encryption Prerequisites

To use LDAP, NuoDB clients must be configured to use TLS.

The connection between the Transaction Engine (TE) and the LDAP server can either be encrypted or not. Depending on your security requirements, you can either choose LDAP or LDAPS. See Connect to a database Using TLS and LDAP.

Configuring the Transaction Engine (TE) for LDAP Authentication

Authentication is performed by the TE, so the LDAP configuration properties (see below) are engine properties that TEs recognize.

NuoDB supports only LDAP authentication, it does not support authorization. In other words, all user rights (grants) need to be configured in NuoDB. Only the password checking is handled by an LDAP server.

  • As noted above, restoring a NuoDB backup will restore roles and grants as they were when the backup was taken.

If, in your database, you have some TEs with LDAP authentication configured and some without, you will see different behavior depending on with which TE a client is connected to.

  • The database itself will have only one entry per user and that entry will be marked as either external or not (see FLAGS column in PASSWORDS System Table Description).

  • If the user is external and the client tries to connect to a TE without LDAP authentication, then the user will not authenticate.

  • If the user was not created with CREATE USER username EXTERNAL, the TE will not attempt to authenticate the user via LDAP regardless of whether or not the TE to which the client is connected supports LDAP authentication.

It is recommended that all TEs are configured with the same LDAP configuration.

Mandatory Options

There are five required database options that must be specified for any TE that supports LDAP authentication. They are:

Option Name Option Argument Description

ldap-dn

ldapDN

Required for LDAP authentication. Use the Distinguished Name ldapDN to bind to the LDAP directory.

Example: ldap-dn 'cn=Manager,ou=people,dc=example,dc=com'

ldap-pass

ldapPassword

Required for LDAP authentication. LDAP password for simple authentication.

ldap-base

ldapBase

Required for LDAP authentication. Starting point for the LDAP search instead of the default

Example: 'ou=people,dc=example,dc=com'

ldap-type

unix | windows

Required for LDAP authentication. LDAP server type. Only unix or windows is allowed.

ldap-uri

ldapURI

Required for LDAP authentication. Specify URI referring to the LDAP server(s)

Example: 'ldap://localhost:389'


Additional Options

Option Name Option Argument Description

ldap-conf

ldapConf

Optional. LDAP path to ldap.conf file to use (see man ldap.conf - Linux only)

ldap-ca

ldapCA

Optional. LDAP CA certificate to validate server certificate for ldaps(Linux only)

ldap-lib

ldapLib

Optional. LDAP openldap library name (Linux only)

ldap-user-filter

Enables the user to choose their own filter to find the appropriate data in the LDAP directory.

This is appropriate for users with Active Directory instances where the userPrincipalName attribute is not available.

The %s in the filter string is replaced by the database username which is trying to authenticate.

Example:

'(&(objectClass=user) (sAMAccountname=%s))'

Using ldap-user-filter

By default:

  • For 'ldap-type windows', the default filter applied is:

    '(&(objectCategory=person)(objectClass=user)(userPrincipalName=%s@*))'

  • For ’ldap-type unix', the default is:

    '(&(objectClass=inetOrgPerson)(uid=%s))'

If you have an older Active Directory instance, then the use of sAMAccountName may apply (see https://docs.microsoft.com/en-us/windows/win32/ad/naming-properties#samaccountname):

  • The sAMAccountName attribute is a logon name used to support clients and servers from previous version of Windows, such as Windows NT 4.0, Windows 95, Windows 98, and LAN Manager.

  • The logon name must be 20 or fewer characters and be unique among all security principal objects within the domain.

In that case, you should use ldap-user-filter to specify a filter like:

  • '(&(objectClass=user)(sAMAccountname=%s))'

The use of the ldap-user-filter option takes precedence over the ldap-type option.