The RELIANOID Load Balancer includes a Role-Based Access Control (RBAC) module. RBAC is a policy-neutral access control mechanism centered around users, roles, and privileges. This module integrates with various data sources and requires specific user credentials.

Supported Data Origins #

LDAP. Users are authenticated against an existing LDAP system, such as OpenLDAP, Microsoft Active Directory, or other LDAP applications.
Local. Users are authenticated against the local Linux user database (/etc/shadow).

Validation System Configuration #

As shown in the screenshot above, you can enable or disable the validation systems as needed. If multiple validation systems are enabled, the system will first attempt to log the user in through LDAP. If the user is not found, it will then try the local data source (/etc/shadow).

Validation System Table Fields #

System. Specifies the validation module for logged-in users. This version supports logins against LDAP and Local. LDAP systems must be configured as detailed in later sections.
Status. Indicates whether the validation system is enabled or disabled. A Green indicator means the system is active, while Red means it is disabled.

Validation System Actions #

Start. Activates the authentication module.
Stop. Deactivates the authentication module.
Configure. Sets up the validation module and runs tests to ensure the LDAP connector is properly configured.

Configuring the LDAP Validation Connector #

To configure the LDAP connector, fill in the following parameters:

Host/URL. The server where LDAP is accessible.
Port. The TCP port where the LDAP server is listening, typically 389 or 636 for LDAPS (SSL).
Bind DN. The credentials (username) used for LDAP authentication.
Bind Password. The password for the Bind DN user.
Base DN. The starting point within the directory for LDAP user authentication searches.
Scope. Specifies the depth of the LDAP search.
Version. Indicates the LDAP version to use.
Timeout. Sets the duration to wait for an LDAP response.
Filter. Limits the number of users or groups that can access the application.

Example LDAP Search #

Below is an example of an LDAP search using the fields described above, showing a user found in LDAP:

root@client:~$ ldapsearch -h ldap.relianoid.com -D cn=admin,dc=relianoid,dc=com -b ou=people,dc=relianoid,dc=com -W
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=people,dc=relianoid,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# people, relianoid.com
dn: ou=people,dc=relianoid,dc=com
objectClass: organizationalUnit
objectClass: top
ou: people

# johndoe, people, relianoid.com
dn: cn=johndoe,ou=people,dc=relianoid,dc=com
cn: johndoe
givenName: John
gidNumber: 500
homeDirectory: /home/users/johndoe
sn: doe
loginShell: /bin/sh
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
uidNumber: 1000
uid: johndoe
userPassword:: e2NSWVBUfXVLdXXXXFcxNGZaOGfdaJyZW8=

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2

Attributes uid and password are used in the RBAC module for authentication.

Once the required attributes are confirmed, and the LDAP search is successful, configure the RBAC LDAP module as follows:

• LDAP Server: ldap.relianoid.com .
• Port: not included in the command, so by default 389.
• Bind DN: cn=admin,dc=relianoid,dc=com .
• Bind DN Password: Secret password.
• Base Search: ou=people,dc=relianoid,dc=com .
• Filter: not used in the example.

LDAP Validation System Actions #

• Apply. Submit and apply the new configuration.
• Test Connectivity. Launch a LDAP connectivity test.
• Revert Changes. Reset the modified form fields with the last applied values.

LDAP and AD Important Considerations #

Host. Supports both Host and URL formats. Use the URL to specify the protocol (e.g., ldap://ldap.relianoid.com or ldaps://ldap.relianoid.com).
Port. Not needed if a URL is configured. The port is inherent but specify it if using a non-default LDAP port.
Scope. Indicates the search level. Options include:

• Sub: Search in the Base DN and all sub-levels.
• One: Search in the Base DN and one step ahead.
• Base: Search only in the Base DN without sub-levels.

Filter: Used as a condition to modify login behavior. For example, Active Directory uses the attribute sAMAccountName for login. Filters can be concatenated to match all conditions (e.g., (&(&(sAMAccountName=%s)(memberOf=CN=sysadmins,OU=yourOU,DC=yourcompany,DC=com))) ).