The KEMP LoadMaster Edge Security Pack (ESP) has the ability of steering client traffic to individual Real Servers in a Virtual Service based on the Active Directory (AD) group membership of users initiating client traffic. An example scenario would be a Virtual Service which has four Real Servers. Two Real Servers could be configured to have a primary association with Active Directory Group 1 and two Real Servers could be configured to have a primary association with AD Group 2. When a user attempts to access the Virtual Service, their group membership will be verified and the information used to steer their request to the appropriate Real Servers. If the Real Servers selected based on group membership are not available, the default behavior is to fall back to the assigned scheduling method for the Virtual Service.
The purpose of this document is to provide information and instructions on how to configure the LoadMaster to steer client traffic based on group membership. For more information on the ESP feature and options in general, refer to the ESP, Feature Description.
This document is intended for network and application administrators that are interested in finding out more about using ESP for steering client traffic based on AD group membership in the KEMP LoadMaster.
Before configuring ESP steering groups in LoadMaster, it is assumed that the following prerequisites have been met:
The relevant configuration has been made in the Active Directory, (i.e. setting up user groups and adding the relevant users to the relevant groups.)
A determination has been made as to which groups will be used to steer traffic to which to which Real Servers.
Permitted groups must be in use on the Virtual Service to support group-based traffic steering.
The relevant Virtual Service(s) and Real Server(s) have been created and configured as needed. For information on how to configure Virtual Services, and the various features available in the KEMP LoadMaster, refer to the KEMP Documentation page: .
An appropriate Client Authentication Mode is being used (steering groups are not available for Basic Authentication or SAML authentication).
Kerberos Constrained Delegation (KCD) is not in use (steering groups do not work with KCD).
A description of how the ESP steering groups work is provided below:
1. The names of the desired Active Directory groups to perform steering on are entered into the Steering Groups text box in the Virtual Service modify screen in the LoadMaster.
2. When steering groups are specified in a Virtual Service and a user logs in, the username is tested to check if it exists in any of the steering groups, starting from the left.
3. If there is a match, the index of the matching group is returned in a cookie to the client. The index of the steering group is determined based on the position of the steering group in the Steering Groups text box, (i.e. the first group in the list has an index of 1, the second has an index of 2 and so on.) If the user is in multiple groups, the index of the first group in which the user is found is returned.
4. Content rules should be created to match each of the steering groups and assigned to the relevant Real Servers. On subsequent logins, the index number is used steer the traffic to the relevant Real Server.
For step-by-step instructions on how to configure this, refer to the Configure ESP Steering Groups in the LoadMaster section.
Follow the steps in the sections below to configure ESP steering groups in the LoadMaster.
To configure ESP steering groups, follow the steps below in the KEMP LoadMaster Web User Interface (WUI). ESP SSO Domain settings must already be configured on the LoadMaster for this to function properly. See the ESP, Feature Description for details on configuring SSO Domains
1. In the main menu, go to Virtual Services > View/Modify Services.
2. Click Modify on the relevant Virtual Service.
3. Expand the ESP Options section and check the Enable ESP check box.
4. Select the appropriate Client Authentication Mode (steering groups are not available when using Basic Authentication or SAML authentication).
5. Enter the Active Directory group names which contain members that are allowed to access the service in the Permitted Groups field and click the Set Permitted Groups button.
6. Enter the Active Directory group names that will be used for steering traffic in the Steering Groups field and click the Set Steering Groups button.
Use a semi-colon to separate multiple group names.
The steering group index number will correspond to the location of the group in this list. In the example above - Group1 has an index of 1 and Group2 has an index of 2.
7. Enable or disable the Include Nested Groups option.
This field relates to the Permitted Groups setting. Enable this option to include nested groups in the authentication attempt. If this option is disabled, only users in the top-level group will be granted access. If this option is enabled, users in both the top-level and first sub-level group will be granted access.
8. Configure any other settings as needed.
Some notes around the permitted groups and steering groups are below:
The Permitted Groups and Steering Groups entered should correspond to groups configured in the Active Directory.
The permitted groups are the groups that are allowed to access this Virtual Service. When set, if a user logs in to an application published by this Virtual Service, the user must be a member of at least one of the groups specified.
The Permitted Group SID(s) (security identifiers) field is the equivalent of the Permitted Groups field. If specifying permitted groups, you can complete either the Permitted Groups field or the Permitted Groups SID(s) field.
In the Permitted Group SID(s) field you can specify the Group SIDs that are allowed to access this Virtual Service. Each group must be separated by a semicolon. After you type the groups, click Set Permitted Group SIDs.
The Steering Groups steer client traffic to subsets of Real Servers in a Virtual Service based on group membership.
Up to 10 permitted groups are supported per Virtual Service.
Up to 5 steering groups are supported per Virtual Service.
Performance may be impacted if a large number of groups are entered on a single Virtual Service.
The steering group(s) entered must also be specified as permitted groups.
If steering groups are specified for a Virtual Service, the group membership is tested for each group in the list - starting from the left. If there is a match - the first matching group is the one that will be used to steer the traffic.
Groups entered are validated using an LDAP query to Active Directory
The group(s) specified must be valid groups in the Active Directory domain that is specified in the SSO domain associated with the Virtual Service. The SSO domain name in the LoadMaster must be set to the Active Directory name as opposed to the DNS name of the service. For example, if the SSO domain in the LoadMaster is set to webmail.example but this is not the actual Active Directory domain FQDN, it will not function. Instead, the SSO domain would need to be set to .example.com.
Multiple groups should be separated by a semi-colon (;). A space will not separate the groups since some group names may contain a space, such as Domain Users.
The following characters are not allowed in permitted group names:
/ : + *
The authentication protocol of the SSO domain must be LDAP when using these groups.
The groups should be specified by name, not by full distinguished name (for example, â€œtestgroupâ€ as opposed to â€œCN=testgroup,CN=Users,DC=kemptech,DC=comâ€)
If the Virtual Service configuration is updated while a user has an open session, the request may not be steered as expected. You could flush the cache as a workaround, but this would clear the cache for all Virtual Service users meaning they are forcibly disconnected.
When a user logs in, the index number of the first matching steering group is used to create a cookie. The index number of the steering groups correspond to the order of the groups in the Steering Groups field in the Virtual Service, (that is, the first group has an index of 1, the second has an index of 2 and so on.)
The cookie is called X-KEMP-STEERING. Content rules should be created and added to the relevant Real Server(s) in order to match the relevant steering group and steer the traffic appropriately. To create a content rule for this purpose, follow the steps below:
1. In the main menu of the LoadMaster WUI, go to Rules & Checking > Content Rules.
2. Click Create New.
3. Enter a recognizable Rule Name.
4. Ensure the Rule Type is set to Content Matching.
5. Ensure the Match Type is set to Regular Expression.
6. Enter Cookie as the Header Field.
7. Enter X-KEMP-STEERING=<IndexOfSteeringGroup>, for example X-KEMP-STEERING=1 to match the first group in the Steering Groups list.
8. Click Create Rule.
9. Repeat these steps for any other steering groups, as needed.
After creating the content rules, the rules need to be assigned to the relevant Real Server(s) in order to steer the traffic to those Real Servers based on the steering group. To assign a content rule to a Real Server, follow the steps below:
1. In the main menu of the LoadMaster WUI, go to Virtual Services > View/Modify Services.
2. Click Modify.
3. Expand the Advanced Properties section.
4. Click Enable in the Content Switching section.
5. Expand the Real Servers section.
6. Click the None button in the Rules column for the relevant Real Server.
7. Select the relevant rule from the Rule drop-down list.
8. Click Add.
9. Repeat these steps to assign the other rules to the relevant Real Servers, as needed.
If a content rule which matches on a steering group with the index 1 has been assigned to a Real Server, users in the first steering group listed in the Steering Groups field will be directed to that Real Server - if it is available. If the Real Server is not available, the traffic distribution will default to the Scheduling Method selected for the Virtual Service.
This document was last updated on 02 January 2018.