System | RBAC | Settings

Role Based Access Control Settings

ZEVENET Load Balancer includes a Role-based access control(RBAC) module. RBAC is a policy-neutral access-control mechanism defined around users, roles, and privileges. The module connects various data origins and asks for certain user credentials.

These are the supported data origins.
LDAP. The users are logged against an existing LDAP system, e.g. OpenLDAP, Microsoft Active Directory and other LDAP application solutions.
Local. The users are logged against the local Linux user database (/etc/shadow).

Validation System Configuration

As shown in the screenshot above, the validation systems may be enabled or disabled as needed. In case more than one validation system is enabled, there will be a trial to log the user out through the LDAP. If the user is not found, then it will attempt through the local data origin (/etc/shadow).

The fields in the Validation System table are described below:
System. Defines the validation module for logged-in users. In this version, logins against LDAP and Local are supported. In the case of LDAP validation, the system must be configured as explained in the later chapters of this section.
Status. The status is either enabled or disabled. Shows a Green indicator if the validation system is active and Red if it is disabled.
Actions. The supported actions are:

  • Start. To activate the usage of the authentication module.
  • Stop. To deactivate the usage of the authentication module.
  • Configure. To set up the validation module and runs some tests to check if the LDAP connector is properly configured.

Configuring LDAP validation connector

You must fill in these parameters for a correct LDAP connector to be configured.

Host/URL. The server where the LDAP is accessible.
Port. The TCP port where the LDAP server is listening. By default, it is 389 or 636 for LDAPS (SSL).
Bind DN. The credentials (username) to use when authenticating in an LDAP server.
Bind Password. The password for the Bind DN user.
Base DN. A point within a directory where the LDAP server starts searching for user authentication.
Scope. This scope indicates how deep the LDAP search should occur.
Version. Specify which LDAP version will access the LDAP server.
Timeout. Determines the LDAP timeout duration in case it doesn’t find the search.
Filter. An attribute that specifies or limits the number of users or groups that can access an application.

The search below is an example that uses the fields described above. You can see that a user is found in the LDAP besides the bind DN user.

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

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

# acano, people,
dn: cn=acano,ou=people,dc=Skudonet,dc=com
cn: acano
givenName: alvaro
gidNumber: 500
homeDirectory: /home/users/acano
sn: cano
loginShell: /bin/sh
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
uidNumber: 1000
uid: acano
userPassword:: e2NSWVBUfXVLdFcxNGZaOGfdaJyZW8=

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2

Note that the attribute uid and password are to be used in the RBAC module authentication.

Once the required attributes confirm and also the LDAP search works, the RBAC LDAP module will be configured as shown below.

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

Actions. Some actions are available after the configuration.

  • 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.


Host field supports the following formats: Host or URL. Use the URL if you want to specify the protocol (ldap:// or ldaps://
Port field doesn’t need to be used in case you configure a URL. The port is inherent, but if the used LDAP port isn’t the default, then specify the port.
Scope field can be used to indicate the search level to apply. Sub: The search is done in the configured Base DN and all the available sub levels. One: The search is done in the configured Base DN and in a sub-level one-step head. Base: The search is only done in the Base DN without searching in any sub-level.
Filter field is used as a condition. If a given uid doesn’t include the attribute indicated here, then the login will be incorrect even if the password is correct. This field is also used to modify the login behavior in case the LDAP system uses another attribute for login purposes. You must indicate here the used attribute. For example, Active Directory uses the attribute sAMAccountName for login. Filters can be concatenated so that all the conditions match, for example: (&(sAMAccountName=%s)(memberOf=CN=sysadmins,OU=yourOU,DC=yourcompany,DC=com)).

Was this article helpful?

Related Articles

Download Skudonet ADC Load Balancer
Community Edition

Source Code

A versatile and installable ADC system designed for diverse vendor hardware.


Installable ISO 

Load Balancing as a Service alongside an ADC orchestration toolkit.

Download Community Edition

Download Community Edition

“We manage the information you provide with the sole aim of assisting with your requests or queries in regards to our products or services; applying the computer and security procedures to ensure its protection. Your data can be rectified or removed upon request but won’t be offered to any third parties, unless we are legally required to do so.” Responsible: SKUDONET SL -