Settings

Zevenet Load Balancer includes an RBAC module (Role-based access control), it is a policy-neutral access-control mechanism defined around users, roles and privileges, this RBAC module is able to connect to different data origin and ask for a certain user, the supported data origins are:

• LDAP: The users are logged against an existing LDAP system, for example, OpenLDAP, Microsoft Active Directory among other LDAP application solutions.
• Local: The users are logged against the local Linux users’ database (/etc/shadow).

Validation System Configuration

As it is shown in the previous screenshot, the validation systems can be enabled or disabled as needed, in case that more than one validation system is enabled the user will be tried to be logged on first through the LDAP, if the user is not found then, locally (/etc/shadow).

The fields in the Validation System table are described below:

• System: Defines the validation module for login users, in this version login against LDAP and locally are supported, in case of LDAP validation, the system needs to be configured as explained in following lines
• Status: Enabled or disabled, shows in green point if this validation system is being used or red point if it is disabled.
• Actions: The supported actions are: Disable/enable: in order to activate or deactivate this validation module usage and configure: it configures the validation module and run some tests to check that the LDAP connector is properly configured.

Configuring LDAP validation connector

The required values for a correct LDAP connector configuration are the following:

• LDAP Server: The host where the LDAP is accessible.
• Port:TCP port where the LDAP service is listening, by default 389 or 636 for LDAPS (SSL)
• Bind DN: The path to the user with search permissions
• Bind Password: The password for the Bind DN user
• Base Search:The path where search from the users
• Filter: Atribute that needs to match in the user to be selected, for example, member of a certain group.

The following search runs an example with the described fields previously, as it can be shown the given user is found in the LDAP with a bind DN user with permissions to do searches.

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

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

# acano, people, zevenet.com
dn: cn=acano,ou=people,dc=zevenet,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:: e0NSWVBUfXVLdFcxNGZaOGfdaFyZW8=

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2

Refer to the attribute uid and password, which are going to be used in the RBAC module authentication.

Once the required attributes are known and checked manually that the ldap search works, the RBAC LDAP module need to be configured as shown below:

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

Considerations

• Host field supports the following formats: Host or URL, use the URL if you want to specify the protocol (ldap://ldap.zevenet.com or ldaps://ldap.zevenet.com).
• Port field doesn’t need to be used in case you configure a URL, the port is inherent then, but if the used LDAP port isn’t the default then specify here the port.
• Scope field can be used to indicate which search level to apply, Sub: The search is done in the configured Base DN and all available sublevels. One: The search is done in the configured Base DN and in the following sublevel. Base: The search is only done in the Base DN, without searching in any sublevel.
• Filter field is used as a condition, if the 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 that the LDAP system uses another attribute for login purpose, then you have to indicate the here the used attribute instead. For example, Active Directory uses the attribute sAMAccountName for login, then modify the filter as indicated: (sAMAccountName=%s).
• Filters can be concatenated so all the conditions need to match, for example: (&(sAMAccountName=%s)(memberOf=CN=sysadmins,OU=yourOU,DC=yourcompany,DC=com)).