Edge Security Pack (ESP) Options

The ESP feature must be enabled before you can configure these options. To enable the ESP function, please select the Enable ESP check box.

The full ESP Options screen will appear.

Enable ESP

Enable or disable the ESP feature set by selecting or removing the checkmark from 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
• Security: logs recording all security alerts
• Connection: logs recording each connection

Logs are persistent and can be accessed after a reboot of the LoadMaster. For further information on logs please refer to the Extended Log Files section.

Client Authentication Mode

Specifies how clients attempting to connect to the LoadMaster are authenticated. The following types of methods are 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

In LoadMaster firmware version 7.2.53, support was added for Client Certificate authentication with no server side authentication. For further details, refer to the ESP Feature Description.

• NTLM/NTLM-Proxy: NTLM credentials are based on data obtained during the interactive logon process and consist of a domain name and a user name

• 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 Manage SSO Domains 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 Manage SSO Domains section for further information on configuring SSO Domains.

Before enabling ESP, ensure that SSL offloading is configured for the HTTPS Virtual Service.

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.
   Note: An assigned domain is a domain which can be authenticated using a particular Virtual Service.

   Note: 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 in the main menu.

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 domains may be specified within the field allowing many domains to be associated with the Single Sign On Domain.

The use of regular expressions is allowed within this field.

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 field and click the Set Allowed Virtual Directories button to specify the allowed virtual directories.

The use of regular expressions is allowed within this field.

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.

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. Performance may be impacted if a large number of groups are entered. Groups entered in this field are validated using an LDAP query.

Some guidelines about this field are as follows:

• The group(s) specified must be valid groups on the Active Directory in the SSO domain associated with the Virtual Service. The SSO domain in the LoadMaster must be set to the directory for the groups. For example, if the SSO domain in the LoadMaster is set to webmail.example and webmail is not the directory for the groups, it will not work. Instead, the SSO domain may need to be set to .example.com.
• The group(s) listed 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 following characters are not allowed in permitted group names:/ : + *
• The authentication protocol of the SSO domain must be LDAP
• The groups should be specified by name, not by full distinguished name

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

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.

SSO Image Set

This option is only available if Form Based is selected as the Client Authentication Mode. You can choose which form to use to gather the Username and Password. There are three form options, Exchange, Blank and Dual Factor Authentication. There are also options to display the form and error messages in other languages.

• Exchange Form

The Exchange Form contains the Progress Kemp Logo

• Blank Form

The Blank Form does not contain the large Progress Kemp logo.

• Dual Factor Authentication

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

Remote Credentials are credentials that are used to authenticate against remote authentication servers such as RADIUS, before allowing the user to authenticate against Domain Servers such as Active Directory servers.

Internal Credentials are credentials that are used to authenticate against the internal domain servers such as Active Directory Servers.

SSO Greeting Message

This option is only available if Form Based is selected as the Client Authentication Mode. The login forms can be further customized by adding text. Enter the text that you would like to appear on the form within the SSO Greeting Message field and click Set SSO Greeting Message. The message can have up to 255 characters.

The SSO Greeting Message field accepts HTML code, so you can insert an image if required.

Logoff String

This option is only available if Form Based or SAML is selected as the Client Authentication Mode. 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, the modified Logoff String needs to be specified in this text box. Multiple logoff strings can be entered 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 will display a public/private option on the ESP log in page. Based on the option the user selected on the login form, the Session timeout value is set to the value specified for either public or private in the Manage SSO Domain screen. If the user selects the private option their username is stored for that session. Refer to the Manage SSO Domains section for more information about these fields.

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

Captcha Public Key

The key that was provided as the public key when you signed up for the CAPTCHA service.

Captcha Private Key

The key that was provided as the private key when you signed up for the CAPTCHA service.

Captcha Access URL

The URL of the service that provides the CAPTCHA challenge. Usually:

www.google.com/recaptcha/api.js

CAPTCHA Verification URL

The URL of the service that verifies the response to the CAPTCHA challenge. Usually:

www.google.com/recaptcha/api/siteverify

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 users’ 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. This field is only visible if the Client Authentication Mode is set to Form Based and the User Password Change URL is set.

The language of the warning text is based on the SSO Image Set that is selected (English, French, or Portuguese).

Verify Bearer Header

Select this check box to verify if the authentication header contains a bearer record. This is used when doing JSON web token validation.

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.

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. The following types of methods are available:

• None: no client authentication is required
• Basic Authentication: standard Basic Authentication is used
• KCD: KCD authentication is used
• 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.

If Delegate to Server is selected as the Client Authentication Mode, then None is automatically selected as the Server Authentication mode. Similarly, if Basic Authentication is selected as the Client Authentication Mode, then Basic Authentication is automatically selected as the Server Authentication mode.

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