Edge Security Pack (ESP)

1 Introduction

KEMP has built a large and loyal install base across a range of market segments, applications and geographies. These include a large number of customers who have deployed KEMP’s LoadMaster load balancers in conjunction with Microsoft workloads. As a part of the solution for Microsoft workloads, a key component has historically been Microsoft’s Forefront Threat Management Gateway (TMG). One key feature of TMG was that it offered customers a way to publish and protect workload servers such as Exchange Client Access Servers, especially in Internet-facing deployments where a clean separation between critical infrastructure and the public internet is essential.

Since the TMG product is no longer supported, KEMP Technologies has extended the LoadMaster platform with the Edge Security Pack (ESP), to replace and enhance the functionality that was available in TMG. This separately available feature pack builds on the existing core technologies that have enabled successful joint deployments of TMG and LoadMaster in internet-facing Microsoft workloads.

ESP functionality is only available on certain subscriptions. Please contact a KEMP representative if needed.

2 The LoadMaster Edge Security Pack (ESP)

The KEMP LoadMaster along with the Edge Security Pack (ESP) delivers a solution to customers who would have previously deployed TMG to publish their Microsoft applications.

The LoadMaster Edge Security.png

The basic flow for ESP authentication is shown in the diagram above:

Traffic from the client goes to the LoadMaster.

The LoadMaster may present an authentication form asking the user to enter credentials.

The Authentication Provider server then allows or rejects the request.

If successful, the traffic is passed to the Real Servers.

The KEMP ESP offers the following key features:

End point authentication for pre-authentication

Persistent logging and reporting for user logging

Single Sign-On (SSO) across Virtual Services

LDAP Authentication from the LoadMaster to the Active Directory

Basic authentication communication from a client to the LoadMaster

Dual-factor authentication

A reboot is required after upgrading older versions of the LoadMaster to an ESP license.

2.1 End Point Authentication for Pre-Auth

Clients who are trying to access Virtual Services on the LoadMaster will have to provide Authentication information which is used by the ESP to validate the clients’ right to access the service. In the event of success, the client is permitted to access the service, and in the event of failure the client is blocked until valid credentials are provided.

2.1.1 Persistent Logging and Reporting for User Logging

When clients try to access a service, an appropriate message is logged to allow monitoring by the administrator.

2.1.2 Single Sign-On Across Virtual Services

The LoadMaster is designed to handle multiple Virtual Services supporting unique workloads.  Access to these services can be authenticated through a single point of contact, by associating them with the same Single Sign-On (SSO) Domain.

The Virtual Services need to be on the same domain for this to work, for example ecp.example.com and www.example.com.

SSO in ESP will enable clients to only enter the authentication information when accessing the first Virtual Service and then this same information is used to access other services associated with the Single Sign-On Domain. Therefore, a client accessing Exchange will also be able to access SharePoint and other workloads if they are associated with the same Single Sign-On Domain.

2.1.3 LDAP Authentication from the LoadMaster to the Active Directory

Active Directory is the standard Authentication Provider for Microsoft workloads. LoadMaster will support the key connection types between the LoadMaster and the Active Directory.

For instructions on how to set up the server-side configuration, please refer to the relevant vendor’s documentation.

2.1.4 Basic Authentication Communication from a Client to the LoadMaster

LoadMaster with ESP currently supports basic and form-based authentication between the client and the LoadMaster, providing clients with an optimum authentication experience.

Large and small businesses are deploying large numbers of internet-facing applications to support ever expanding business requirements. This rapidly growing number of servers needs to be scalable and highly reliable.  Above all, the access to these servers and services needs to be secure.  With the addition of ESP, the KEMP LoadMaster will continue to deliver on customer security requirements for internet facing applications in a world without Microsoft Forefront TMG, while continuing to address requirements for feature-rich and cost-effective scalability and high reliability.

For instructions on how to set up the server-side configuration, please refer to the relevant vendor’s documentation.

2.1.5 Dual-factor Authentication

Some authentication mechanisms assume a dual-factor approach where both the Active Directory and a secondary mechanism are used in sequence. For these, the form includes the username, password and also a passcode which is checked after the username and password.

3 ESP Web User Interface (WUI) Options

The sections below describe the ESP WUI Options. These sections refer to various different sections of the LoadMaster WUI. To log in to the LoadMaster WUI, navigate to https://<WUIIPAddress> in a web browser and enter credentials.

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

ESP Options.png

The full ESP Options will appear.

The ESP feature can only be enabled if the Virtual Service is an HTTP, HTTPS or SMTP Virtual Service

ESP Options_1.png

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 > ESP Log Files in the main menu of the LoadMaster WUI.

When using SNMP monitoring of ESP-enabled Virtual Services that were created using a template, ensure to monitor each SubVS directly rather than relying on the master service. This is because the Authentication Proxy sub-service will always be marked as up and, as a consequence, so will the master service.

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

Please keep in mind - if UTF-8 encoding is utilized, the maximum number of characters for the username or password which is used to access an ESP-enabled Virtual Service is (in theory) 30 characters each. However, if a combination of 1 and 2 byte characters are used, this limit could be increased. The maximum limit is 63 characters each if the characters are all 1 byte encoded.

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

NTLM: 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

The remaining fields in the ESP Options section will change based on what is selected as the Client Authentication Mode.

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.

Only SSO domains with the Configuration type of Inbound Configuration are shown as options in this SSO Domain field.

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.

This option appears only when more than one domain has been configured and when the Authentication Protocol for the SSO domains are set to LDAP.

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

ESP Options_2.png

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.

ESP Options_3.png

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.

ESP Options_4.png

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.

When logging in to a domain using the ESP form, users should enter the name of the SSO Domain if an alternative domain needs to be accessed. If no domain name is entered in the username, users are, by default, logged on the domain entered in the default SSO Domain 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.

If this text box is left blank, the Virtual Service is blocked.

If the Virtual Service IP address is entered in the Allowed Virtual Hosts field, the login process will fail. For testing purposes, please modify your Hosts file if a proper DNS entry cannot be made.

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

Up to 10 groups are supported per Virtual Service. 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

A space-separated list does not work because most groups contain a space in the name, for example IT Users.

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

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. Each group must be separated by a semicolon. After you type the groups, click Set Permitted Group SIDs.

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.

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 on the KEMP Documentation Page.

Steering groups are not available if using Basic Authentication or SAML authentication.

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.

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

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.

Exchange Form

ESP Options_5.png

The Exchange Form contains the KEMP Logo.

Blank Form

ESP Options_6.png

The Blank Form does not contain the KEMP logo.

Dual Factor Authentication

ESP Options_7.png

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

The Dual Factor Authentication image set should only be used with the RADIUS and LDAP authentication protocol.

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

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.

034.png

The SSO Greeting Message text box accepts HTML code, so you can type a reference to an external image if you want. The message can have up to 255 characters. The message can contain almost any character – it is inserted into a HTML form so the message can have any font that is available on the page.

There are several characters that are not supported. These are the grave accent character ( ` ) and the single quote (’).

If a grave accent character is used in the SSO Greeting Message, the character will not display in the output, for example a`b`c becomes abc. If a single quote is used, users will not be able to log in.

Logoff String

This option is only available if Form Based 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.

If the URL to be matched contains sub-directories before the specified string, the logoff string will not be matched. Therefore, the LoadMaster will not log the user off.

Display Public/Private Option

ESP Options_9.png

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.

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 session cookies on public 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.

Permanent cookies should only be used when using single sign on with services that have sessions spanning multiple applications, such as SharePoint.

User Password Change URL

This is relevant when using form-based LDAP authentication. 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 put into the exception list for authentication, if required.

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.

Server Authentication Mode

This field is only updatable when the Client Authentication Mode is set to Form Based.

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, please refer to the Kerberos Constrained Delegation, Feature Description.

Form Based: The Server Authentication Mode can be set to Form Based if the Client Authentication Mode is set to Form Based. If Form Based is selected as the Server Authentication Mode, another field called Form Authentication Path appears. When the Form Authentication Path field is filled out, the Form POST Method field appears.
The username and password from the client-side, form-based authentication gets 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&amp;flags=4&amp;forcedownlevel=0&amp;username=%s&amp;password=%s&amp;passwordText=&amp;isUtf8=1

If the deployment is not Exchange, KEMP recommends that the settings are evaluated based on the required interaction with the Real Server and subsequently set appropriately.

The Client Authentication Mode selected determines the default value for the Server Authentication Mode. For further details, refer to the table below.

Client Authentication Mode

Default Server Authentication Mode

Delegate to Server

None

Basic Authentication

Basic Authentication

Server Side configuration

This option is only visible when the Server Authentication mode value is set to KCD because this only applies if KCD is being used. For further information, please refer to the Kerberos Constrained Delegation, Feature Description.

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

Virtual Service Status

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

ESP Options_10.png

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

ESP Options_11.png

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.

3.1.1 SMTP Virtual Services and ESP

If an SMTP Virtual Service (with 25 as the port) is created, the ESP feature is enabled for the Virtual Service when the Enable ESP checkbox is selected, but with a reduced set of options.

SMTP Virtual Services and.png

Enable ESP

Enable or disable the ESP feature set by selecting or deselecting the Enable ESP check box.

Connection Logging

Logging of connections can be enabled or disabled by selecting or deselecting the Connection Logging check box. The ESP logs can be viewed and downloaded by going to System Configuration > Logging Options > Extended Log Files.

Permitted Domains

All the permitted domains that are allowed to be received by this Virtual Service must be specified here. For example, if the Virtual Service should receive SMTP traffic from john@kemp.com, then the kemp.com domain must be specified in this field. When entering more than one domain, separate them with a space.

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

If this text box is blank, no domains are allowed and all mail is stopped.

3.2 LDAP Configuration

To get to the LDAP Configuration screen, expand Certificates & Security and click LDAP Configuration. This screen provides a management interface for LDAP endpoints. These LDAP endpoints may be used in three different areas:

Health checks

SSO domains

WUI authentication

LDAP Configuration.png

Any existing LDAP Endpoints are listed here, with an option to Modify and Delete. If an LDAP endpoint is in use it cannot be deleted.

There is also an option to add a new LDAP endpoint. Enter a name for the endpoint and click Add. Spaces and special characters are not permitted in the LDAP endpoint name.

LDAP Configuration_1.png

LDAP Server(s)

Specify a space-separated list of LDAP servers to be used. Port numbers can also be specified if required. If you have multiple domains and are using Permitted Groups, sometimes it is necessary to include the Global Catalog port number, otherwise the Permitted Groups will fail. The default port is 3628. For example, 10.110.20.23:3268.

LDAP Protocol

Select the transport protocol to use when communicating with the LDAP server.

Validation Interval

Specify how often the user should be revalidated with the LDAP server.

Referral Count

The LoadMaster offers beta functionality to support LDAP referral replies from Active Directory Domain Controllers. If this is set to 0, referral support is not enabled. Set this field to a value between 1 and 10 to enable referral chasing. The number specified will limit the number of hops (referrals chased).

Multiple hops may increase authentication latency. There is a performance impact that depends on the number and depth of referrals required in your configuration.

You must have intimate knowledge of your Active Directory structure to set the referral limit appropriately. The same credentials are used for all lookups, and so on.

The use of Active Directory Global Catalog (GC) is the preferred configuration as the primary means of resolution instead of enabling LDAP referral chasing. A GC query can be used to query the GC cache instead of relying on LDAP and the referral process. Using Active Directory GC has little or no performance drag on the LoadMaster. For steps on how to add/remove the GC, refer to the following TechNet article: https://technet.microsoft.com/en-us/library/cc755257(v=ws.11).aspx

Admin User

Enter the username of an administrator user.

Admin User Password

Enter the password for the specified administrator user.

3.3 Manage SSO Options

Before using the Edge Security Pack (ESP) the user must first set up a Single Sign-On (SSO) Domain on the LoadMaster. The SSO Domain is a logical grouping of Virtual Services which are authenticated by an LDAP server.

To get to the Manage SSO screen – in the main menu of the LoadMaster WUI, go to Virtual Services > Manage SSO.

The maximum number of SSO domains that are allowed is 128.

Manage SSO Options.png

Click the Manage SSO Domains menu option to open the Manage Single Sign On Options screen.

3.3.1 Single Sign On Domains

Two types of SSO domains can be created – client side and server side.

Client Side configurations allow you to set the Authentication Protocol to LDAP, RADIUS, RSA-SecurID, Certificates, RADIUS and LDAP or RSA-SecurID and LDAP.

Server Side configurations allow you to set the Authentication Protocol exclusively to Kerberos Constrained Delegation (KCD).

To add a new SSO Domain enter the name of the domain in the Name field and click the Add button. The name entered here does not need to relate to the allowed hosts within the Single Sign On Domain.

When using the Permitted Groups field in ESP Options, you need to ensure that the SSO domain set here is the directory for the permitted groups. For example, if the SSO Domain is set to webmail.example and webmail is not the directory for the permitted groups within example.com, it will not work. Instead, the SSO Domain needs to be set to .example.com.

If the Domain/Realm field is not set, the domain Name set when initially adding an SSO domain is used as the Domain/Realm name.

3.3.1.1 Client Side (Inbound) SSO Domains

Single Sign On Domains.png

Authentication Protocol

This dropdown allows you to select the transport protocol used to communicate with the authentication server. The options are:

LDAP

RADIUS

RSA-SecurID

Certificates

RADIUS and LDAP

RSA-SecurID and LDAP

The fields displayed on this screen will change depending on the Authentication protocol selected.

LDAP Endpoint

Select the LDAP endpoint to use. For further information on LDAP endpoints, refer to the LDAP Configuration section.

This option is only available if the Authentication Protocol is set to LDAP, RADIUS and LDAP or RSA-SecurID and LDAP.

RADIUS/RSA-SecurID Server(s)

Type the IP addresses of the server or servers which is used to authenticate the domain into the LDAP server(s) field and click the Set LDAP Server(s) button.

Multiple server addresses can be entered within this text box. Each entry must be separated by a space.

Radius Shared Secret

The shared secret to be used between the RADIUS server and the LoadMaster.

This field will only be available if the Authentication Protocol is set to RADIUS or RADIUS and LDAP.

Check Certificate to User Mapping

This option is only available when the Authentication Protocol is set to Certificates. When this option is enabled - in addition to checking the validity of the client certificate - the client certificate will also be checked against the altSecurityIdentities (ASI) attribute of the user on the Active Directory.

If this option is enabled and the check fails, the login attempt will fail. If this option is not enabled, only a valid client certificate (with the username in the SubjectAltName (SAN)) is required to log in, even if the altSecurityIdentities attribute for the user is not present or not matching.

For more information, refer to the Kerberos Constrained Delegation, Feature Description.

Allow fallback to check Common Name

Enabling this option allows a fallback to check the Common Name (CN) in the certificate when the SAN is not available.

This field only appears when the Authentication Protocol is set to Certificates.

Domain/Realm

The login domain to be used. This is also used with the logon format to construct the normalized username, for example;

Principalname: <username>@<domain>

Username: <domain>\<username>

If the Domain/Realm field is not set, the Domain name set when initially adding an SSO domain is used as the Domain/Realm name.

RSA Authentication Manager Config File

This file needs to be exported from the RSA Authentication Manager.

For more information on the RSA authentication method, including how to configure it, refer to the RSA Two Factor Authentication, Feature Description.

RSA Node Secret File

A node secret must be generated and exported in the RSA Authentication Manager.

It is not possible to upload the RSA node secret file until the RSA Authentication Manager configuration file is uploaded. The node secret file is dependent on the configuration file.

Logon Format

This drop-down list allows you to specify the format of the login information that the client has to enter.

The options available vary depending upon which Authentication Protocol is selected.

Not Specified: The username will have no normalization applied to it - it is taken as it is typed.

Principalname: Selecting this as the Logon format means that the client does not need to enter the domain when logging in, for example name@domain.com. The SSO domain added in the corresponding text box is used as the domain in this case.

When using RADIUS as the Authentication protocol the value in this SSO domain field must exactly match for the login to work. It is case sensitive.

Username: Selecting this as the Logon format means that the client needs to enter the domain and username, for example domain\name@domain.com.

Username Only: Selecting this as the Logon Format means that the text entered is normalized to the username only (the domain is removed).

The Username Only option is only available for the RADIUS and RSA-SecurID protocols.

Logon Format (Phase 2 Real Server)

Specify the logon string format used to authenticate to the Real Server.

The Logon Format (Phase 2 Real Server) field only appears if the Authentication Protocol is set to one of the following options:

RADIUS

RSA-SecurID

Logon Format (Phase 2 LDAP)

Specify the logon string format used to authenticate to LDAP.

The Logon Format (Phase 2 LDAP) field only appears if the Authentication Protocol is set to one of the following options:

RADIUS and LDAP

RSA-SecurID and LDAP

The table below shows the expected normalization results (for LDAP only) from example configurations:

Login Format Setting

Realm

Input Username

Normalized User

Used for BIND

Result

Used for

BIND on Fail

Result

Not Specified

example

test01

test01@EXAMPLE.COM

test01@EXAMPLE.COM

Success

 

 

Not Specified

example

test01@example.com

test01@example.com

test01@example.com

Success

 

 

Not Specified

example

test01@example

test01@example

test01@example

Success

 

 

Not Specified

example

example\test01

example\test01

example\test01

Success

 

 

Not Specified

example

example.com\test01

example.com\test01

example.com\test01

Fail

test01@example

Success

Principal Name

example

test01

test01@example

test01@example

Success

 

 

Principal Name

example

test01@example.com

test01@example.com

test01@example.com

Success

 

 

Principal Name

example

test01@example

test01@example

test01@example

Success

 

 

Principal Name

example

example\test01

example\test01

test01@example

Success

 

 

Principal Name

example

example.com\test01

test01@example.com

test01@example

Success

 

 

Username

example

test01

example\test01

example\test01

Success

 

 

Username

example

test01@example.com

example\test01

example\test02

Success

 

 

Username

example

test01@example

example\test01

example\test01

Success

 

 

Username

example

example\test01

example\test01

example\test01

Success

 

 

Username

example

example.com\test01

example\test01

example\test01

Success

 

 

Not Specified

None

test01

test01@EXAMPLE.COM

test01@EXAMPLE.COM

Success

 

 

Not Specified

None

test01@example.com

test01@example.com

test01@example.com

Success

 

 

Not Specified

None

test01@example

test01@example

test01@example

Success

 

 

Not Specified

None

example\test01

example\test01

example\test01

Success

 

 

Not Specified

None

example.com\test01

example.com\test01

example.com\test01

Fail

test01@EXAMPLE.COM

Success

Principal Name

None

test01

test01@EXAMPLE.COM

test01@EXAMPLE.COM

Success

 

 

Principal Name

None

test01@example.com

test01@example.com

test01@example.com

Success

 

 

Principal Name

None

test01@example

test01@example

test01@example

Success

 

 

Principal Name

None

example\test01

example\test01

example\test01

Success

 

 

Principal Name

None

example.com\test01

test01@EXAMPLE.COM

test01@EXAMPLE.COM

Success

 

 

Username

None

test01

EXAMPLE.COM\test01

EXAMPLE.COM\test01

Fail

test01@EXAMPLE.COM

Success

Username

None

test01@example.com

EXAMPLE.COM\test01

EXAMPLE.COM\test01

Fail

test01@EXAMPLE.COM

Success

Username

None

test01@example

test01@example

test01@example

Success

 

 

Username

None

example\test01

example\test01

example\test01

Success

 

 

Username

None

example.com\test01

EXAMPLE.COM\test01

EXAMPLE.COM\test01

Fail

test01@EXAMPLE.COM

Success

Username Only

None

test01

test01

N/A

Pass

N/A

N/A

Username Only

None

test01@example.com

test01

N/A

Pass

N/A

N/A

Username Only

None

test01@example

test01

N/A

Pass

N/A

N/A

Username Only

None

example\test01

test01

N/A

Pass

N/A

N/A

Username Only

None

example.com\test01

test01

N/A

Pass

N/A

N/A

Logon Transcode

Enable or disable the transcode of logon credentials, from ISO-8859-1 to UTF-8, when required.

If this option is disabled, log in using the format that the client dictates. If this option is enabled, check if the client uses UTF-8. If the client does not use UTF-8, use ISO-8859-1.

Failed Login Attempts

The maximum number of consecutive failed login attempts before the user is locked out. Valid values range from 0 to 99. Setting this to 0 means that users will never be locked out.

When a user is locked out, all existing logins for that user are terminated, along with future logins.

Reset Failed Login Attempt Counter after

When this time (in seconds) has elapsed after a failed authentication attempt (without any new attempts) the failed login attempts counter is reset to 0. Valid values for this text box range from 60 to 86400. This value must be less than the Unblock timeout value.

Unblock timeout

The time (in seconds) before a blocked account is automatically unblocked, that is, unblocked without administrator intervention. Valid values for this text box range from 60 to 86400. This value must be greater than the Reset Failed Login Attempt Counter after value.

Session timeout

The idle time and max duration values can be set here for trusted (private) and untrusted (public) environments. The value that is used is dependent on whether the user selects public or private on their login form. Also, either max duration or idle time can be specified as the value to use.

Idle time: The maximum idle time of the session in seconds, that is, idle timeout.

Max duration: The max duration of the session in seconds, that is, session timeout.

Valid values for these fields range from 60 to 86400.

Use for Session Timeout: A switch to select the session timeout behaviour (max duration or idle time).

The underlying network traffic may render the session active, even if there is no obvious user interaction.

Use LDAP Endpoint for Healthcheck

Select this check box to use the LDAP endpoint administrator username and password for health checking. If this is enabled, the Test User and Test User Password textboxes will not be available.

For more information on LDAP endpoints, refer to the LDAP Configuration section.

This option is only available for the following protocols; LDAP, Certificates, RADIUS and LDAP and RSA-SecurID and LDAP.

Test User and Test User Password

In these two fields, enter credentials of a user account for your SSO Domain. The LoadMaster will use this information in a health check of the Authentication Server. This health check is performed every 20 seconds.

3.3.1.1.1 Client Side (Inbound) SAML SSO Domains

The fields vary when the Authentication Protocol is set to SAML. The SAML-specific fields are described below.

Single Sign On Domains_1.png

Idp Provisioning

The Manual option allows you to manually input details into the IdP fields.

The MetaData File option allows you to upload an IdP MetaData File. This simplifies the configuration of the IdP attributes, including the IdP Entity ID, IdP SSO URL and IdP Logoff URL. The metadata file can be downloaded from the IdP.

IdP Metadata File

This field is only visible if the IdP Provisioning field is set to MetaData File. To upload the file - click Browse, navigate to and select the relevant file and click Import IdP MetaData File.

IdP Entity ID

Specify the IdP entity identifier.

IdP SSO URL

Specify the IdP SSO URL.

IdP Logoff URL

Specify the IdP logoff URL.

IdP Certificate

The IdP Certificate is very important in terms of verification of the assertions that must be contained in the SAML response that is received from the IdP. Without the certificate, verification cannot proceed.

SP Entity ID

This is an identifier that is shared to enable the IdP to understand, accept and have knowledge of the entity when request messages are sent from the LoadMaster. This must correlate to the identifier of the relying party on the AD FS server.

SP Signing Certificate

It is optional to sign requests that are sent in the context of logon. Currently, the LoadMaster does not sign those requests.

In the context of log off requests – it is mandatory and these requests must be signed. This is to avoid any spoofing and to provide extra security in relation to log off functionality. This ensures that users are not being hacked and not being logged off unnecessarily.

In the SP Signing Certificate drop-down list, you can choose to use a self-signed certificate or third party certificate to perform the signing.

Download SP Signing Certificate

If using a self-signed certificate, click Download to download the certificate. This certificate must be installed on the IdP server (for example AD FS) to be added to the relying party signature.

The AD FS server requires this certificate for use of the public key to verify the signatures that the LoadMaster generates.

Session Control

The IdP Session Max Duration option does not appear to be usable when the IdP is AD FS. SAML and the LoadMaster supports it if present in the Authentication Response.

SP Session Idle Duration

Specify the session idle duration (in seconds).

3.3.1.1.2 Sessions

Single Sign On Domains_2.png

Clicking the Sessions button, for a client-side SSO domain, opens a screen listing the current open sessions on that domain.

Single Sign On Domains_3.png

You can filter the list by entering a search term in the Filter users text box.

The following information is provided about each session:

Users: The username/domain of the client.

Source: The client (host) IP address and source port.

Dest IP: The destination IP address of the connection.

Created: The date and time that the connection was created.

Expires: The date and time that the connection expires.

Cookie: The cookie used in the connection.

Clicking the Kill All button kills all open sessions (flushes the SSO cache).

Single Sign On Domains_4.png

Selecting one or more sessions provides some further options:

Kill Selected

Block Selected

Show All

Logs are added to the audit log for every kill session operation. For example:

Kill 'non-cookie' session log:
Nov 9 16:47:31 LM ssomgr: Deleted a session tester@aktest.com:- for domain AKTEST.COM

Kill 'cookie' session log:
Nov 9 16:47:31 LM ssomgr: Deleted a session ldaptest@aktest.com:420cf78373643b3c0171d95c757e7bf3 for domain AKTEST.COM

Kill all domain sessions log:
Nov 9 16:48:46 LM ssomgr: Deleted all domain AKTEST.COM user sessions

Currently Blocked Users

This section displays a list of users who are currently blocked and it also shows the date and time that the block occurred. It is possible to remove the block by clicking the unlock button in the Operation drop-down list.

Different formats of the same username are treated as the same username, for example administrator@kemptech.net, kemptech\administrator and kemptech.net\administrator are all treated as one username.

3.3.1.2 Server Side (Outbound) SSO Domains

Authentication protocol

This dropdown allows you to select the transport protocol used to communicate with the authentication server. The only option available for outbound (server side) configurations is Kerberos Constrained Delegation.

Kerberos Realm

The address of the Kerberos Realm.

Colons, slashes and double quotes are not allowed in this field.

This field only supports one address.

Kerberos Key Distribution Center (KDC)

The host name or IP address of the Kerberos Key Distribution Center. The KDC is a network service that supplies session tickets and temporary session keys to users and computers within an Active Directory domain.

This field only accepts one host name or IP address. Double and single quotes are not allowed in this field.

Kerberos Trusted User Name

Before configuring the LoadMaster, a user must be created and trusted in the Windows domain (Active Directory). This user should also be set to use delegation. This trusted administrator user account is used to get tickets on behalf of users and services when a password is not provided. The user name of this trusted user should be entered in this text box.

Double and single quotes are not allowed in this field.

Kerberos Trusted User Password

The password of the Kerberos trusted user.

3.4  Backup/Restore

SCSABR004.png

 Create Backup File

 Generate a backup that contains the Virtual Service configuration, the local appliance information and statistics data. License information and SSL Certificate information is not contained in the backup.

For ease of identification, the Backup file name includes the LoadMaster’s hostname.

By default, the LoadMaster includes a Netstat output in backups taken. When this is included, backups take longer to complete. You can stop the Netstat output from being included by disabling the Include Netstat in Backups option in the Debug Options screen (System Configuration > Logging Options > System Log Files > Debug Options).

 Restore Backup

When performing a restore (from a remote machine), the user may select what information should be restored:

VS Configuration

LoadMaster Base Configuration

Geo Configuration

ESP SSO Configuration (This restores the SSO domains, LDAP endpoints and SSO custom image sets. This does not restore the Virtual Service settings - use the VS Configuration option to restore those.)

A combination of the options

It is not possible to restore a single machine configuration onto a HA machine or restore a HA configuration onto a single machine.

It is not possible to restore a configuration with ESP-enabled Virtual Services onto a machine which is not enabled for ESP.

 Automated Backups

If the Enable Automated Backups check box is selected, the system may be configured to perform automated backups on a daily or weekly basis.

For ease of identification, the Backup file name includes the LoadMaster’s hostname.

If the automated backups are not being performed at the correct time, ensure the NTP settings are configured correctly. For further information, refer to the Date/Time section.

When to perform backup

Specify the time (24 hour clock) of backup. Also select whether to backup daily or on a specific day of the week. When ready, click the Set Backup Time button.

In some situations, spurious error messages may be displayed in the system logs, such as:

Dec 8 12:27:01 KEMP_1 /usr/sbin/cron[2065]: (system) RELOAD (/etc/crontab)

Dec 8 12:27:01 KEMP_1 /usr/sbin/cron[2065]: (CRON) bad minute (/etc/crontab)

These can be safely ignored and the automated backup will likely still complete successfully.

Backup Method

Select the file transfer method for automated backups:

Ftp (insecure)

scp (secure)

If using scp, the Private Key File must be supplied.

Remote user

Set the username required to access remote host.

Private Key File

If using scp as the backup method, the Private Key File must be provided. This is the SSH private key generated using ssh-keygen on the remote scp server.

Remote password

The Remote password is used when the Backup Method is set to Ftp (insecure). Set the password required to access remote host. This field accepts alphanumeric characters and most non-alphanumeric characters. Disallowed characters are as follows:

Control characters

‘ (apostrophe)

` (grave)

The delete character

Remote host

Set the remote host name.

Remote Pathname

Set the location on the remote host to store the file.

Test Automated Backups

Clicking the Test Backup button performs a test to check if the automated backup configuration is working correctly. The results of the test can be viewed within the System Message File.

3.5 Debug Options

There are a couple of ESP-specific Debug Options in the WUI. These are described below.

To get to the Debug Options screen - in the LoadMaster WUI, go to System Configuration > Logging Options > System Log Files > Debug Options.

3.5.1 Enable SSOMGR Debug Traces

Enabling this option will record any login attempts to the SSO domains configured on the LoadMaster. When this option is enabled, the logs are stored in the SSOMGR Audit Logs in the Extended Log Files screen. For further information on these log files, refer to the Logging Options section.

3.5.2 Flush SSO Authentication Cache

Clicking the Flush SSO Cache button flushes the Single Sign-On cache on the LoadMaster. This has the effect of logging off all clients using Single Sign-On and forces the clients to re-connect to the LoadMaster.

3.5.3 Linear SSO Log Files

By default, older log files are deleted to make room for newer log files, so that the filesystem does not become full. By default, the last 30 days of logs are stored. Selecting the Linear SSO Log Files check box prevents older files from being deleted.

When using Linear SSO Logging, if the log files are not periodically removed and the file system becomes full, access to Virtual Services with ESP enabled is blocked, preventing unlogged access to the Virtual Service. Access to non-ESP enabled Virtual Services are unaffected by the Linear SSO Log File feature.  

3.6 Miscellaneous Options

To get to the Miscellaneous Options section – in the LoadMaster WUI, go to System Configuration > Miscellaneous Options. In this section there are sub-sections for L7 Configuration and Network Options.

3.6.1 L7 Configuration

L7 Configuration.png

L7 Authentication Timeout

When configuring ESP, users can set the L7 Authentication Timeout (secs) option.

This option supports the integration with third party, multi-factor, authentication solutions which may have secondary processes such as SMS or telephone verification. This setting determines how long (in seconds) the SSO form waits for authentication verification to complete before timing out.

L7 Client Token Timeout (secs)

The duration of time (in seconds) to wait for the client token while the process of authentication is ongoing (used for RSA SecurID and RADIUS authentication). The range of valid values is 60 to 300. The default value is 120.

3.6.2 Network Options

When configuring ESP, to generate timeout logs, users can Enable Connection Timeout Diagnostics in the Network Options screen in the WUI.

SCMONO005.png

By default, connection timeout logs are not enabled. This is because they may cause too many unnecessary logs. If you wish to generate logs relating to connection timeouts, select the Enable Connection Timeout Diagnostics check box.

3.7 Logging Options

The Extended Log Files screen provides options for logs relating to the ESP feature.

To get to the Extended Log Files screen – in the LoadMaster WUI, go to System Configuration > Logging Options > Extended Log Files.

These logs are persistent and are available after a LoadMaster reboot. To view all the options, click the Logging Options.png icons.

Logging Options_1.pngLogging Options_2.png

There are a number of log files relating to ESP stored on the LoadMaster:

ESP Connection Log: logs recording each connection

ESP Security Log: logs recording all security alerts

ESP User Log: logs recording all user logins. If the user is known, the URL which is being accessed by the user is recorded in the user log.

SSOMGR Audit Logs: logs relating to SSO authentication attempts. To enable these logs, enable the SSOMGR Debug Traces option in the Debug Options screen.

To view the logs please select the relevant options and click the relevant View button.

Some of the logs can be filtered by a number of methods. To filter log messages by date, select the relevant dates in from and to fields and click the View button. It is possible to view logs for as far back as they have been stored. By default, logs are stored for the last 30 days. One or more archived log files can be viewed by selecting the relevant file(s) from the list of file names and clicking the View button. The logs can be filtered by entering a word(s) or regular expression in the filter field and clicking on the View field.

The SSOMGR log file gets compressed at midnight each day as long as the file is not empty (that is, if SSOMGR Debug Traces is enabled in the Debug Options screen). When a compressed file (.gz) is created, it is named with a datestamp. When the SSOMGR file is compressed, a new SSOMGR file is created and this file then gets written to when the relevant logs are generated. oThe LoadMaster holds up to six compressed SSOMGR log files at any one time. When the compressed file is seven days old it is removed.

Clear Extended Logs

Extended logs can be deleted by selecting a relevant date range and clicking the Clear button.

If a date range is not selected, the ESP logs will not be deleted.

Specific log files can be deleted by filtering on a specific date range, selecting one or more individual log files in the log file list or selecting a specific log type (for example connection, security or user) in the log file list and clicking the Clear button. Click OK on any warning messages.

Save Extended Logs

All extended logs can be saved to a file by clicking the Save button. This will save a file to your machine.

Specific log files can be saved by filtering on a specific date range, selecting one or more individual log files in the log file list or selecting a specific log type (for example connection, security or user) in the log file list and clicking the Save button.

4 Setting up a Virtual Service with ESP

This section details the various steps required to configure ESP on a Virtual Service.

In order to enable ESP functionality on an encrypted service, an SSL certificate must be imported to the LoadMaster. The certificate must contain a private key. This document assumes that the certificate has already been imported correctly.

For further details on how to configure SSL Certificates, please reference the SSL Accelerated Services, Feature Description document.

4.1 Create a Single Sign-On (SSO) Domain

The maximum number of SSO domains that are allowed is 128.

Follow the steps below to create an SSO domain:

1. Log in to the LoadMaster.

2. Select Virtual Services in the main menu and select Manage SSO Domains.

Create a Single Sign On SSO.png

3. Enter the name of the domain and click the Add button.

When using the Permitted Groups field in ESP Options, you need to ensure that the SSO domain set here is the directory for the permitted groups. For example, if the SSO Domain is set to webmail.example and webmail is not the directory for the permitted groups within example.com, it will not work. Instead, the SSO Domain needs to be set to .example.com.

 

Create a Single Sign On SSO_1.png

4. Select LDAP as the Authentication Protocol.

The other configuration types and authentication protocols - LDAP-StartTLS, LDAP-LDAPS, RADIUS, RSA-SecurID, Kerberos Constrained Delegation, Certificates and RADIUS and LDAP - can be selected if the Active Directory environment is configured for it.

For more information on the RSA-SecurID, Kerberos Constrained Delegation or Certificates options, including steps on how to configure them, refer to the relevant documents:

RSA Two Factor Authentication, Feature Description

Kerberos Constrained Delegation, Feature Description

5. Select the relevant LDAP endpoint in the LDAP Endpoint drop-down list. For further information on LDAP endpoints, refer to the LDAP Configuration section.

6. In the Domain/Realm field, enter the login domain to be used.

This is also used with the logon format to construct the normalized username, for example;

Principalname: <username>@<domain>

Username: <domain>\<username>

If the Domain/Realm field is not set, the Domain name set when initially adding an SSO domain is used as the Domain/Realm name.

7. Select the relevant Logon format. The login format comprises of two options, as outlined below:

a) principalname: Selecting this as the Logon format means that the client does not need to enter the domain when logging in, for example name@domain.com. The SSO domain entered in the corresponding text box is used as the domain in this case.

When using RADIUS as the Authentication protocol the value in this SSO domain field must exactly match for the login to work. It is case sensitive.

b) username: Selecting this as the logon format means that the client needs to enter the domain and username, for example domain\name@domain.com.

8. Specify the number of Failed Login Attempts that a user can have before their account is locked out. Click Set Failed Login Attempts.

When a user is locked out, all existing logins for that user are terminated, along with future logins. Users can be unblocked in the Currently Blocked Users section of the Manage Domain screen.

9. Enter the amount of time (in seconds) that you would like to Reset Failed Login Attempt Counter after. Click Set Reset-Failed Timeout.

10. Enter the amount of time (in seconds) after which a blocked user account is unblocked in the Unblock Timeout text box. Click Set Unblock Timeout.

11. Enter the relevant value(s) in the public and private idle time and max duration text box(es) and click the relevant button(s) as appropriate. The timeout value that is applied depends on whether the user selects public or private on the login screen.

12. Select the relevant option for use value (either max duration or idle time).

13. Select whether or not to use the LDAP endpoint for the health check.

14. If you have decided not to use the LDAP endpoint for the health check, in the Test User and Test User Password fields, enter credentials of a user account for the SSO Domain. The LoadMaster will use this information in a health check of the Authentication Server. This health check is performed every 20 seconds. This 20 second health check is hard coded and cannot be modified.

15. Click OK.

It is also possible to unlock blocked users from the Manage Domain screen. To do this, simply click the unlock button for the relevant blocked user.

4.2 Create a Content-Matching Rule

Follow the steps below to create a content-matching rule:

In this particular example we will create a Content Rules and a Virtual Service for the owa Exchange 2013 service.

1. In the menu on the left, click Rules & Checking and select Content Rules.

2. Click the Create New … button.

Create a Content Matching.png

3. Enter the Rule Name, for example owa.

4. Ensure the Rule Type is set to Content Matching.

5. Ensure that Match Type is set to Regular Expression.

6. Enter the Pattern in the Match String textbox, for example ^/owa* for the Outlook Web Access (OWA) virtual directory.

7. Tick the Ignore Case checkbox.

8. Click the Create Rule button.

This rule is not doing anything yet. It needs to be added to a Virtual Service. Follow the steps in the next section to create a Virtual Service and add the rule to it.

4.3 Create a Virtual Service

Follow the steps below to create a Virtual Service with ESP. In this example we will configure an owa for Exchange 2013 service.

1. In the menu on the left, click Virtual Services and select Add New.

Create a Virtual Service.png

2. Enter the Virtual Address, for example 10.11.0.157.

This is the Virtual IP address of the Virtual Service. It must be unique and not in use by any other device on the network.

3. Enter 443 as the Port number as all workloads are accessing Exchange 2013 using HTTPS.

Creating Virtual Services for other protocols is outside the scope of this document.

4. Enter the desired Service Name, for example Exchange 2013 owa.

5. Ensure that tcp is selected as the Protocol.

6. Click the Add this Virtual Service button.

7. Expand the Real Servers section.

8. Enter /OWA/healthcheck.htm as the URL.

9. Click the Set URL button.

10. Select GET from the HTTP Method drop-down list.

11. Click the Add New… button.

Create a Virtual Service_1.png

12. Enter the relevant Real Server Address.

13. Enter 80 as the port.

14. Click Add This Real Server.

15. Expand the SSL Properties section.

Create a Virtual Service_2.png

16. Select the Enabled checkbox.

17. Select the Reencrypt checkbox.

18. Click the Manage Certificates button.

19. Click Import Certificate.

Create a Virtual Service_3.png

20. Click the first Choose File button.

21. Browse to and select the relevant certificate.

22. Click the second Choose File button.

23. If needed, browse to and select the relevant Key File.

24. Enter the Pass Phrase.

25. Enter a name for the certificate in the Certificate Identifier text box.

26. Click Save.

27. Click OK.

28. Select View/Modify Services in the main menu.

29. Click Modify on the relevant Virtual Service.

30. Expand the Standard Options section.

Create a Virtual Service_4.png

31. Ensure that None is selected as the Persistence Options Mode.

32. Ensure that round robin is selected as the Scheduling Method.

33. In the parent VS modify screen, expand the Advanced Properties section.

VSVSAP033.png

34. Click the Enable button for Content Switching.

35. Click the Show Selection Rules button to open the Match Rules page.

36. Select the rule that we previously created and click the Add button.

37. Click the Back button.

38. Expand the ESP Options section.

Create a Virtual Service_6.png

39. Select the Enable ESP check box.

40. Select the relevant option in the Client Authentication Mode drop-down list.

41. Select the relevant Domain that was created within the SSO Domain drop-down list.

42. Enter the relevant hosts in the Allowed Virtual Hosts text box, for example mail.example.com.

More than one host can be provided by using a space-separated list. Wildcards can also be used, for example *kempdemo.com.

The Allowed Virtual Hosts text box should contain host names, not IP addresses.

43. Enter any directories that can be accessed by the Virtual Services, for example /owa* in the Allowed Virtual Directories text box.

44. Click the Set Allowed Directories button.

If a SubVS needs to allow more than one virtual directory, use a space-separated list. Optionally, a wildcard character can be used, for example /* to allow all virtual directories.

45. Enter all the virtual directories that will not be pre-authorized by this Virtual Service, for example, /owa/guid* in the Pre-Authorization Excluded Directories field.

46. Click the Set Excluded Directories button.

The Globally Unique Identifier (GUID) is unique to each organization. To find the correct GUID, run the following command on the Exchange Server:

Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like “OrganizationCapabilityClientExtensions”} | f1 exchangeGUID, primarysmtpaddress

47. Enter any groups that are allowed to access this Virtual Service in the Permitted Groups text box.

Multiple groups can be entered but the group names must be separated by a semi-colon.

The following characters are not allowed in permitted group names:
/ : + *
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.

48. Click Set Permitted Groups.

49. 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 are granted access. If this option is enabled, users in both the top-level and first sub-level group are granted access.

50. Select an SSO Image Set, if required.

Custom SSO image sets can be created and uploaded to the LoadMaster. For more information, refer to the Custom Authentication Form, Technical Note.

51. Enter a message in the SSO Greeting Message field, if required.

The SSO Greeting Message can have up to 255 characters. The field accepts HTML code, so the users can insert their own an image can be entered if desired. The grave accent character ( ` ) is not supported. If this character is entered in the SSO Greeting Message, the character will not display in the output, for example a`b`c becomes abc.

52. Enter /owa/logoff.owa in the Logoff String text box.

In a customized environment, if the OWA logoff string has been changed, the modified logoff string must be entered here.

53. If required, select the Display Public/Private Option which will show a public/private option on the login screen. When this option is enabled, the timeout value is determined based on which option the user selects. The timeout values are set in the manage SSO domain screen. For more information on the timeout fields, refer to the Create a Single Sign-On (SSO) Domain section. When the user selects Private their username is stored for that session.

54. If needed, enable the Disable Password Form check box. This may be needed when password validation is not required, for example if using RSA SecurID authentication in a singular fashion.

55. Select the relevant option in the Use Session or Permanent Cookies field.

Permanent cookies should only be used when using single sign on with SharePoint or similar services.

56. Specify the User Password Change URL and User Password Change Dialog Message, if needed.

57. Select Basic Authentication in the Server Authentication Mode drop-down menu.

You can check the status of the Virtual Service by selecting Virtual Services > View/Modify Services in the main menu.

4.4 Configure a Simple Mail Transfer Protocol (SMTP) ESP Service

In an SMTP Virtual Service (with 25 as the Port), the ESP feature is available when the Enable ESP check box is selected, but there is a reduced set of options. To configure an SMTP ESP Service, follow the steps below:

1. In the menu on the left, click Virtual Services and select View/Modify Services.

2. Click the Add New button.

Configure a Simple Mail Transfer.png

3. Enter the Virtual IP Address for the Virtual Service in the Virtual Address text box.

This is the Virtual IP address of the Virtual Service. It must be unique and not in use by any other device on the network.

4. Enter 25 in the Port text box.

5. Enter a recognizable Service Name, for example SMTP ESP.

6. Click the Add this Virtual Service button.

7. Expand the ESP Options section.

Configure a Simple Mail Transfer_1.png

8. Select Enable ESP.

9. Ensure the Connection Logging check box is selected.

10. Specify the domains permitted by this virtual service in the Permitted Domains field. For example, if the Virtual Service should receive SMTP traffic from john@kemp.com, then kemp.com must be specified in this field.

11. Click the Set Permitted Domains button.

12. Add any Real Servers, as needed, in the Real Servers section.

To check the status of the Virtual Service, select Virtual Services > View/Modify Virtual Services.

5 Troubleshooting

When users connect to a Virtual Service using both ActiveSync and OWA from the same client IP address and using the same username, it will cause the OWA session to log out. This can be prevented by separating and distinguishing these two logins.

To do this, create two separate SSO domains - one for OWA and one for ActiveSync. Both SSO domains can have the same details except for the Logon Format - this needs to be set to Principalname in one SSO domain and Username in the other.

This should result in the two connections being separated and using different logon formats, that is, user@domain.com and domain\user, and therefore ActiveSync will not cause OWA to log out when using the same IP address.

References

Unless otherwise specified, the following documents can be found at http://kemptechnologies.com/documentation.

Web User Interface (WUI), Configuration Guide

Kerberos Constrained Delegation, Feature Description

RSA Two Factor Authentication, Feature Description

Custom Authentication Form, Technical Note

SSL Accelerated Services, Feature Description

Last Updated Date

This document was last updated on 13 October 2017.

Was this article helpful?

0 out of 0 found this helpful

Comments