ESP Options

This section refers to the ESP Options section of the Virtual Service modify screen. To get to this section – in the LoadMaster WUI go to Virtual Services > View/Modify Services, click Modify on the relevant Virtual Service and then expand the ESP Options section. The ESP Options are also available for SubVSes.

The ESP feature must be enabled before the options can be configured. To enable the ESP function, please select the Enable ESP checkbox.

The full ESP Options will appear.

Enable ESP

Enable or disable the ESP feature set by selecting or deselecting the Enable ESP checkbox.

ESP Logging

There are three types of logs stored in relation to the ESP feature. Each of these logs can be enabled or disabled by selecting or deselecting the relevant checkbox. The types of log include:

• User Access: logs recording all user logins. These logs include the full URL the client IP has requested, along with the Uniform Resource Identifier (URI).

• Security: logs recording all security alerts

• Connection: logs recording each connection

Logs are persistent and can be accessed after a reboot of the LoadMaster. The ESP logs can be found by navigating to System Configuration > Logging Options > Extended Log Files in the main menu of the LoadMaster WUI.

Client Authentication Mode

Specifies how clients attempting to connect to the LoadMaster are authenticated. The following are the types of methods available:

• Delegate to Server: the authentication is delegated to the server

• Basic Authentication: standard Basic Authentication is used

• Form Based: clients must enter their user details within a form to be authenticated on the LoadMaster

• Client Certificate: clients must present the certificate which is verified against the issuing authority

• NTLM/NTLM-Proxy: NTLM credentials are based on data obtained during the interactive logon process and consist of a domain name, a user name and a one-way hash of the user’s password

• SAML: The LoadMaster supports SAML, playing the role of a SAML service provider. The service provider provides secure, gated access to a resource.

• Pass Post: In LoadMaster firmware version 7.2.53, a new mode called Pass Post was introduced. With this change introduced, users with valid credentials using the Workspace client app can successfully log in (using Single Sign On (SSO)) using POST-based authentication on the client side and Form Based Authentication (FBA) on the server side and access is granted to the VDI workspace.

• OIDC/OAUTH: Open ID Connect (OIDC) is an authentication protocol based on the OAuth2 protocol used to enable Single Sign On of users across multiple applications via a single Identity Provider. OIDC uses the standardized message flows from OAuth2 to provide identity services.

SSO Domain

Select the Single Sign-On (SSO) Domain within which the Virtual Service is included.

Please refer to the Create a Single Sign-On (SSO) Domain section for further information on configuring SSO Domains. An SSO Domain must be configured to correctly configure the ESP feature.

Alternative SSO Domains

Many organizations use extranets to share information with customers and partners. It is likely that extranet portals will have users from two or more Active Directory domains. Rather than authenticating users from individual domains one at a time, assigning Alternative SSO Domains gives the ability to simultaneously authenticate users from two or more domains using one Virtual Service.

Please refer to the Create a Single Sign-On (SSO) Domain section for further information on configuring SSO Domains.

Before configuring the ESP Options to use Alternative SSO Domains ensure that, in the SSL Properties section, the Enabled and Reencrypt tick boxes are selected.

The domain name which appears in the SSO Domain drop-down list is the default domain. This is also the domain which is used if only one is configured.

Previously configured alternative domains appear in the Available Domain(s) list.

To assign alternative SSO Domains:

1. Highlight each of the domains you wish to assign and click the > button. An assigned domain is a domain which can be authenticated using a particular Virtual Service. All domains which appear as available may be assigned to a Virtual Service.
2. Click the Set Alternative SSO Domains button to confirm the updated list of Assigned Domain(s).
3. Choose Basic Authentication from the Server Authentication Mode drop-down list.

To view the status of the Virtual Services, click Virtual Services and View/Modify Services.

A list of the Virtual Services displays showing the current status of each service.

If alternative domains are assigned and there is an issue with a particular domain, the affected domain name is indicated in the Status column.

Allowed Virtual Hosts

The Virtual Service will only be allowed access to specified virtual hosts. Any virtual hosts that are not specified are blocked.

Enter the virtual host name(s) in the Allowed Virtual Hosts field and click the Set Allowed Virtual Hosts button to specify the allowed virtual hosts. Multiple, space-separated host names can be entered here.

Multiple domains may be specified within the text box allowing many domains to be associated with the SSO Domain.

The use of regular expressions is allowed within this text box. The LoadMaster supports Shell regular expressions in this field, where * is a wild card and ? is a single character. An example is *.example.com which indicates all sub-domains under example.com.

Allowed Virtual Directories

The Virtual Service will only be allowed access to the specified virtual directories, within the allowed virtual hosts. Any virtual directories that are not specified are blocked.

Enter the virtual directory name(s) in the Allowed Virtual Directories text box and click the Set Allowed Virtual Directories button to specify the allowed virtual directories. Multiple space-separated names can be entered here.

The use of Shell regular expressions is allowed within this text box.

Pre-Authorization Excluded Directories

Any virtual directories specified within this field will not be pre-authorized on this Virtual Service and are passed directly to the relevant Real Servers. Multiple space-separated directories can be entered here.

The use of Shell regular expressions is allowed within this text box.

Permitted Groups

Specify the groups that are allowed to access this Virtual Service. When set, if a user logs in to a service published by this Virtual Service, the user must be a member of at least one of the groups specified.

If a user attempts to log in and they are not a member of a permitted group, a message will appear in the logs, similar to the example below:

Blocked access, user exampleuser primary group qa not in approved groups for VS172.21.42.11

Multiple groups are supported per Virtual Service up to a maximum of 2048 characters in length. Performance may be impacted if a large number of groups are entered. Groups entered in this field are validated using a Lightweight Directory Access Protocol (LDAP) query.

Some guidelines about this field are as follows:

• All groups specified must be valid on the Active Directory behind the SSO domain associated with the Virtual Service
• Multiple groups must be separated by a semi-colon

• Do not use the Domain Users group because it is a default primary group for new users.
• The authentication protocol of the SSO domain must be LDAP
• The groups should be specified by Common Name, not by fully distinguished name, for example Test Group

• When using permitted groups in SubVSs, if you have groups called OWAGroup and ECPGroup, for example, users in each group have access to each other's SubVS. This is due to the single sign on nature of ESP.
• Permitted groups only work when the LDAP Endpoint has a username in the format username@domain.com or just administrator/Admin (as long as it is an administrator account), or if there is no username configured.
• Do not enter the same group name in both the Permitted Groups and Steering Groups fields. This causes a conflict. When you specify a steering group, it is assumed to behave like a permitted group, so you do not need to enter the same group in both the Permitted Groups and Steering Groups fields.

Permitted Groups SID(s)

This 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 (security identifiers).

In the Permitted Group SID(s) field you can specify the Group SIDs that are allowed to access this Virtual Service. After you type the groups, click Set Permitted Group SIDs.

This field allows a list of group SIDs of up to 64 bytes in length (192 characters in the format NN NN NN).

Each group is separated by a semi-colon. Spaces are used to separate bytes in certain group SIDs. Here is an example:

S-1-5-21-3763804817-1170992687-1336323834-1151

SIDs can be found by using the get-adgroup-Identity GroupName command.

Include Nested Groups

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 are granted access. If this option is enabled, users in both the top-level and first sub-level group are granted access. There is a theoretical limit of approximately six nested groups.

Multi Domain Permitted Groups

In LoadMaster firmware version 7.2.52, a new check box was added to the ESP Options section of the Virtual Service modify screen called Multi Domain Permitted Groups. This check box is configurable with the following client authentication modes:

• Basic Authentication

• Form Based

• Client Certificate

• NTLM

When Multi Domain Permitted Groups is enabled, the LoadMaster checks for permitted group membership within all sub-domains under the top-level domain.

If Multi Domain Permitted Groups is disabled, users must be in the same domain or sub-domain that the user profile is defined, or the group check fails.

The Multi Domain Permitted Groups option is disabled by default.

The Include Nested Groups option works with Multi Domain Permitted Groups. For example, if you have group1 in server1 and group2 inside group1 in the same server with different users, those users can be authenticated if both Include Nested Groups and Multi Domain Permitted Groups are enabled.

Steering Groups

Steering groups can be used to steer 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.

For further information, refer to the ESP Steering Groups Technical Note.

Enter the Active Directory group names that will be used for steering traffic in the Steering Groups field and click Set Steering Groups.

Use a semi-colon to separate multiple group names. Multiple groups are supported per Virtual Service up to a maximum of 2048 characters in length.

The steering group index number will correspond to the location of the group in this list.

Do not enter the same group name in both the Permitted Groups and Steering Groups fields. This causes a conflict. When you specify a steering group, it is assumed to behave like a permitted group, so you do not need to enter the same group in both the Permitted Groups and Steering Groups fields.

SSO Image Set

This option is only available if Form Based is selected as the Client Authentication Mode. There is an option for which form to use to gather the user’s Username and Password. There are three default form options; Exchange, Blank and Dual Factor Authentication. English is the default language for the image sets. There are also options to display the form and error messages in other languages – Brazilian Portuguese and French Canadian.

The Exchange Form contains the Progress Kemp Logo.

The Blank Form does not contain the Progress Kemp logo.

The Dual Factor Authentication form contains four fields - two for the remote credentials and two for the internal credentials.

It is possible to upload a custom SSO image set. For more information, refer to the Custom Authentication Form, Technical Note

If CAPTCHA is enabled, the CAPTCHA box appears on the ESP login page.

SSO Greeting Message

The login forms can be further customized by adding text (for example the Authorized Access Only! text in the following screenshot). Enter the text to appear on the form within the SSO Greeting Message text box and click the Set SSO Greeting Message button.

Logoff String

This option is only available if Form Based or SAML is selected as the Client Authentication Mode. Specify the string that the LoadMaster should use to detect a logout event. Normally this field should be left blank. For OWA Virtual Services, the Logoff String should be set to /owa/logoff.owa; or, in customized environments, a modified Logoff String needs to be specified in this text box. Multiple logoff strings can be specified by using a space-separated list. You can enter up to 255 characters in this field.

Additional Authentication Header

This option is only available if SAML or OIDC/OAUTH is selected as the Client Authentication Mode. Specify the name of the HTTP header. This header is added to the HTTP request from the LoadMaster to the Real Server and its value is set to the user ID for the authenticated session. You can enter up to 255 characters in this field.

For example, if the preferred_username is not available then the UPN is used. If the UPN is also not available, then unique_name or email is used for token validation.

Display Public/Private Option

Enabling this check box displays a public/private option on the login page. The session and idle timeout depend on what option the user selects when logging in. If the user selects This is a private computer, then their credentials are saved on the client computer. If the user is on a public or shared computer, they should use the default option, which does not save their credentials locally.

Disable Password Form

Enabling this option removes the password field from the login page. This may be needed when password validation is not required, for example if using RSA SecurID authentication in a singular fashion. By default, this option is disabled.

Enable Captcha

Select this check box to allow CAPTCHA verification on the login page.

Before the CAPTCHA has been correctly answered, the submit button on the login form is disabled.If the user does not submit the form within two minutes of answering the CAPTCHA, the CAPTCHA times out (Google-specified timeout), and the user must verify a new CAPTCHA (the submit button is disabled until the new CAPTCHA has been verified).

Use Session or Permanent Cookies

Three options are available to select for this field:

• Session Cookies Only: This is the default and most secure option
• Permanent Cookies only on Private Computers: Sends permanent cookies only on private computers
• Permanent Cookies Always: Sends permanent cookies in all situations

Specify if the LoadMaster should send session or permanent cookies to the client browser when logging in.

User Password Change URL

This is relevant when using client-side forms-based authentication and LDAP. Specify the URL that users can use to change their password, for example https://mail.kempqakcd.net/owa/auth/expiredpassword.aspx?url=/owa/auth.owa

If a user’s password has expired, or if they must reset their password, this URL and the User Password Change Dialog Message is displayed on the login form.

This URL must be entered in the ESP Pre-Authorization Excluded Directories field - this is required to bypass pre-authentication.

If using this expired password functionality in an Exchange 2010 environment:

• The Pre-Authorization Excluded Directories must be set to /owa/auth.owa /owa/auth* /owa/14.3.123.3**. 14.3.123.3 is the sub-path of the Exchange server that must be added to the excluded directories.
• When changing passwords, users cannot use a User Principal Name (UPN) (for example, joebloggs@example.com) in the Domain\user name field in the Change Password window, unless Exchange 2010 SP1 RU3 or later is deployed on the Client Access servers.

For further information, refer to the following Microsoft TechNet article: https://technet.microsoft.com/en-us/library/bb684904(v=exchg.141).aspx

User Password Change Dialog Message

This text box is only visible if something is set for the User Password Change URL text box. Specify the text to be displayed on the login form when the user must reset their password. Special characters are not permitted in this field.

User Password Expiry Warning

By default, SSO users are notified about the number of days before they must change their password. If you disable this option, the password expiry notification will not appear on the login forms.

You can specify the number of days to show the warning before the password is expired. The default value for this field is 15 days. The range is 1 to 30 days. This field is only visible if the Client Authentication Mode is set to Form Based and the User Password Change URL is set.

The user is notified when the password has expired. The language of the warning text is based on the SSO Image Set that is selected (English, French, or Portuguese).

Verify Bearer Header

Enable this check box to verify the authenticity of a JSON Web Token (JWT) included in the Authorizations header of incoming client requests. If the Authorization header field is present in the client request, it is passed back to the Real Server.

There is an additional capability that verifies if the token is valid. This is done by comparing the text provided in the Bearer Header Validation Text field to the contents of the "aud" field of the token included in the Auth header. If this text is present and the match fails - there is no connection made. Another capability is to also check the signature on the token. To do this, you must upload and select a certificate in the Bearer Header Validation Certificate drop-down list. If a certificate is selected and the validation fails - there is no connection made.

Bearer Header Validation Certificate

This option is only visible if the Verify Bearer Header check box is selected.

Specify the name of the relevant certificate from the Bearer Header Validation Certificate drop-down list (this must be first uploaded to the LoadMaster by going to Certificates & Security > SSL Certificates > Import Certificate) containing a Public Key used to validate the authenticity of the JSON Web Token Signature. This is used when doing JSON web token validation.

Bearer Header Validation Text

This option is only visible if the Verify Bearer Header check box is selected.

You can optionally enter up to 5 comma-separated strings to match against the Audience Claim Field (aud) in the token. If provided, at least one string must match the Audience Claim Field's content or the token is rejected.

Server Authentication Mode

Specifies how the LoadMaster is authenticated by the Real Servers. There are three types of methods available:

• None: no client authentication is required
• Basic Authentication: standard Basic Authentication is used
• KCD: Kerberos Constrained Delegation (KCD) is used. For further information, refer to the Kerberos Constrained Delegation, Feature Description.
• Server Token: On reception and verification of the SAML response, the LoadMaster requests a long-lived token. The LoadMaster then builds a redirection URL with the token specified.

• Form Based: When Form Based authentication is selected, the Form Authentication Path field appears.

• When you enter a value in the Form Authentication Path field and click the Set Path button, the Form POST Format and Post Format Username Only fields appear. The username and password from the client-side, form-based authentication is injected into the form POST format to build the POST body.
• This feature is predominantly used in Microsoft Exchange deployments and has only been tested with Exchange 2013 and 2016. Therefore, the following strings do not need to be explicitly configured for Exchange 2013/2016. They are used by default in the implementation:
  • Form Authentication Path: /owa/auth.owa
  • Form POST Format:

    destination=%s#authRedirect=true&flags=4&forcedownlevel=0&username=%s&password=%s&passwordText=&isUtf8=1

POST Format Username Only

Enable this option to send the username only (without the domain part) in the server-side form based authentication POST request.

When choosing a specific Client Authentication Mode protocol, it is important to understand what Server Authentication Mode protocols are compatible:

Server Side configuration

Select the SSO domain for the server side configuration. Only SSO domains which have the Configuration type set to Outbound Configuration are shown here.

Token Server FQDN

Set the FQDN for the token server. When set, LoadMaster contacts the token server at the given FQDN during sign-on and obtains a permanent access token from that token server. If this parameter is unset, then LoadMaster obtains the token from the Real Server (as in previous releases).

Virtual Service Status

When View/Modify Services is clicked in the main menu, the Virtual Service status is displayed.

When the health check status is OK, the Status on the Virtual Services screen is set to Up.

When ESP is enabled, a new status is available; Security Down.

The LoadMaster will check the health status of the authentication server every 20 seconds. If the authentication server cannot be reached, then the Virtual Service goes into a Security Down state where no new users are allowed to access the Virtual Service. Existing connections will not be affected until their individual connection timeouts expire.