Offloaded authentication and optional SSO configuration

To configure offloaded authentication with optional SSO

1.  Before you configure SSO, create one or more of the following authentication server configurations:

2.  Add one or more server configurations to an authentication server pool (see Adding servers to an authentication server pool).

3.  To use Kerberos authentication delegation, do the following:

4.  If you plan to use HTML form authentication, you can customize the HTML pages that FortiWeb presents to clients during the authentication process. See Customizing error and authentication pages (replacement messages).

5.  Go to Application Delivery > Site Publish > Site Publish Rule.

6.  Click Create New and configure the settings. The settings you select determine which additional settings are displayed:


Setting name Description
Name

Type a unique name that can be referenced in other parts of the configuration, such as cms-publisher1.

Do not use spaces or special characters. The maximum length is 35 characters.

Request Type

Select one of the following options:

  • Simple StringPublished Site contains a literal FQDN (fully qualified domain name).
  • Regular Expression Published Site contains a regular expression designed to match multiple host names or FQDNs.
Published Site

Enter one of the following:

  • The literal Host: name, such as sharepoint.example.com, that the HTTP requests that match the rule contain (if Request Type is Simple String)
  • A regular expression, such as ^*\.example\.edu, that matches all and only the host names that the rule should match (if Request Type is Regular Expression).

The maximum length is 255 characters.

Note: Regular expressions beginning with an exclamation point ( ! ) are not supported. For information on language and regular expression matching, see Regular expression syntax.

Path Enter the URL of the request for the web application, such as /owa. It must begin with a forward slash ( / ).
Exchange ActiveSync

Enable to allow Android clients to access to Microsoft Exchange servers through Exchange ActiveSync protocol.

Note: If Exchange ActiveSync is enabled, single sign-on (see SSO Support), authentication cookie (see Authentication Cookie Timeout) and Kerberos authentication (see Authentication Delegation) will be not available, and HTTP Basic Authentication (see Client Authentication Method) will be the only method to authenticate the clients.

Client Authentication Method

Select one of the following options:

  • HTML Form AuthenticationFortiWeb authenticates clients by presenting an HTML web page with an authentication form.
  • HTML Basic AuthenticationFortiWeb authenticates clients by providing an HTTP AUTH code so that the browser displays its own dialog.
  • Client Certificate AuthenticationFortiWeb validates the HTTP client’s personal certificate using the certificate verifier specified in the associated server policy or server pool configuration.

Used when Authentication Delegation is Kerberos Constrained Delegation or No Delegation.

Note: This option requires you to select a value for Certificate Verification in the server policy or Certificate Verification in the server pool configuration. If Exchange ActiveSync is enabled (see Exchange ActiveSync), only HTML Basic Authentication will be available.

Log Off Path Type

Select one of the following options:

  • Simple String — The optional Published Server Log Off Path setting is a literal URL.
  • Regular Expression — The optional Published Server Log Off Path setting is a regular expression designed to match multiple URLs.
Published Server Log Off Path

Optionally, enter one of the following values:

  • If Log Off Path Type is Simple String, enter the URL of the request that a client sends to log out of the application.
  • If Log Off Path Type is Regular Expression, enter a regular expression that matches the logoff URL.

Ensure that the value is a sub-path of the Path value. For example, if Path is /owa , the following values are valid:

/owa/auth/logoff.aspx

/owa/logoff.owa

When clients log out of the web application, FortiWeb redirects them to its authentication dialog.

Available only when Client Authentication Method is HTML Form Authentication.

Authentication Cookie Timeout

Specify the length of time that passes before the cookie that the site publish rule adds expires and the client must re-authenticate.

Valid values are from 0 to 3600 hours.

To configure the cookie with no expiration, specify 0 (the default). The browser only deletes the cookie when the user closes all browser windows.

Note: This will be not available if Exchange ActiveSync (see Exchange ActiveSync) is enabled.

Authentication Server Pool Select the pool of servers that FortiWeb uses to authenticate clients. See Adding servers to an authentication server pool.

FortiWeb attempts to authenticate the user using each server in the pool, starting with the top-most item in the list and moving downward.

Available only when Client Authentication Method is HTML Form Authentication or HTML Basic Authentication.

Authentication Delegation

Select one of the following options:

  • HTTP BasicFortiWeb uses HTTP Authorization: headers with Base64 encoding to forward the client’s credentials to the web application.

    Typically, you select this option when the web application supports HTTP protocol-based authentication.

    Available only when Client Authentication Method is HTML Form Authentication or HTML Basic Authentication

  • Kerberos — After it authenticates the client via the HTTP form or HTTP basic method, FortiWeb obtains a Kerberos service ticket for the specified web application on behalf of the client. It adds the ticket to the HTTP Authorization: header of the client request with Base64 encoding.

    Available only when Client Authentication Method is HTML Form Authentication or HTML Basic Authentication

  • Kerberos Constrained Authentication — After it authenticates the client’s certificate, FortiWeb obtains a Kerberos service ticket for the specified web application on behalf of the client. It adds the ticket to the HTTP Authorization: header of the client request with Base64 encoding.

    Available only when Client Authentication Method is Client Certificate Authentication.

  • No DelegationFortiWeb does not send the client’s credentials to the web application.

    Select this option when the web application has no authentication of its own or uses HTML form-based authentication.

    Note: If the web application uses HTML form-based authentication, the client is required to authenticate twice: once with FortiWeb and once with the web application’s form. Kerberos and Kerberos Constrained Authentication will be not available if Exchange ActiveSync (see Exchange ActiveSync) is enabled.

To work with the Kerberos options, web applications require a specific Windows authentication configuration. See Configuring Windows Authentication for Kerberos authentication delegation.

If FortiWeb uses a RADUIS server configuration in the authorization server pool to autheticate the client and RSA SecurID is selected for that server configuration, any authentication delegation settings in this rule are ignored.

Username Location in Certificate

Use one of the following options to specify how FortiWeb determines the client username:

  • SAN - UPN — Using the certificate’s subjectAltName (Subject Alternative Name or SAN) and User Principal Name (UPN) values. These values that contain the username in certificates issued in a Windows environment. For example:

    username@domain

  • SAN - Email — Using the certificate’s subjectAltName (Subject Alternative Name or SAN) and the email address value in the certificate’s Subject information.
  • Subject - Email — Using the email address value in the certificate’s Subject information.

Note: Because the email value can be an alias rather than the real DC (domain controller) domain, the most reliable method for determining the username is SAN - UPN.

Available only when Authentication Delegation is Kerberos Constrained Delegation.

Delegated HTTP Service Principal Name

Specify the Service Principal Name (SPN) for the web application that clients access using this site publish rule.

A service principal name uses the following format:

<service_type >/<instance_name>:<port_number>/<service_name>

For example, for an Exchange server that belongs to the domain dc1.com and has the hostname USER-U3LOJFPLH1, the SPN is http/USER-U3LOJFPLH1.dc1.com@DC1.COM.

For a FortiWeb site publishing configuration, a valid SPN requires the suffix @<domain> (for example, @DC1.COM).

Available only when Authentication Delegation is Kerberos or Kerberos Constrained Delegation.

Keytab File

Select the keytab file configuration for the AD user that FortiWeb uses to obtain Kerberos service tickets for clients.

To add a keytab configuration, go to Application Delivery > Site Publish > Keytab File.

For instructions on how to generate the keytab file, see To create an Active Directory (AD) user for FortiWeb.

Available only when Authentication Delegation is Kerberos Constrained Delegation.

Service Principal Name for Keytab File

Specify the Service Principal Name (SPN) of the AD user that is a delegator. It is the SPN that you used to generate the keytab specified by Keytab File. (See To create an Active Directory (AD) user for FortiWeb.)

For example, host/forti-delegator.dc1.com@DC1.COM.

For a FortiWeb site publishing configuration, a valid SPN requires the suffix @<domain> (for example, @DC1.COM).

Available only when Authentication Delegation is Kerberos Constrained Delegation.

Default Domain Prefix Support

Select to allow users in environments that require users to log in using both a domain and username to log in with just a username. Also specify Default Domain Prefix.

In some environments, the domain controller requires users to log in with the username format domain\username. For example, if the domain is example.com and the username is user1, the user enters EXAMPLE\user1.

Alternatively, enable this option and enter EXAMPLE for Default Domain Prefix. The user enters user1 for the username value and FortiWeb automatically adds EXAMPLE\ to the HTTP Authorization: header before it forwards it to the web application.

Available only when Authentication Delegation is HTTP Basic or Kerberos.

Default Domain Prefix

Enter a domain name that FortiWeb adds to the HTTP Authorization: header before it forwards it to the web application.

Available only when Default Domain Prefix Support is enabled.

When Authentication Delegation is Kerberos, ensure that the prefix you enter is the full domain name (for example, example.com).

SSO Support

Enable for single sign-on support.

For example, the web site for this rule is www1.example.com and SSO Domain is .example.com. After FortiWeb authenticates the client for www1.example.com, the client can access www2.example.com without authenticating a second time.

Site publishing SSO sessions exist on FortiWeb only; they are not synchronized to the authentication or accounting server. Therefore, SSO is not shared with non-web applications. For SSO with other protocols, see the documentation for your FortiGate or other firewall.

Note: This will be not available if Exchange ActiveSync (see Exchange ActiveSync) is enabled.

SSO Domain Type the domain suffix of Host: names that can share this rule’s authentication sessions, such as .example.com. Include the period ( . ) that precedes the host’s name.
Alert Type

Select whether to log authentication failures, successes, or both:

  • NoneDo not generate an alert email or log message.
  • Failed OnlyOnly authentication failures generate alert email and log messages.
  • Successful Only — Only successful authentication generates alert email or log messages.
  • AllAll HTTP authentication attempts, regardless of success or failure, generate alert email, log messages, or both.

Event log messages contain the user name, authentication type, success or failure, and source address (for example, User jdoe [Site Publish] login successful from 172.0.2.5) when an end-user successfully authenticates. A similar message is recorded if the authentication fails (for example, User hackers [Site Publish] login failed from 172.0.2.5).

7.  Click OK.

8.  Go to Application Delivery > Site Publish > Site Publish Policy.

9.  Click Create New.

10.  In Name, type a unique name that can be referenced in other parts of the configuration. Do not use spaces or special characters. The maximum length is 35 characters.

11.  If you want to prevent users from making further attempts to log in after a specified number of failed login attempts, for Account Lockout, select On, and then complete the following settings:

Setting name Description
Max Login Failures

Enter the number of times that a user can attempt to log in before FortiWeb prevents the user from attempting to log in again.

FortiWeb determines whether the user exceeded this threshold based on the number of login attempts that happen within the time period specified by Within.

If the user exceeds the threshold and attempts to log in again during the time period configured by Account Block Period, FortiWeb returns an "Account blocked!" message to the user.

You can customize the web page that FortiWeb returns to the blocked user. See Customizing error and authentication pages (replacement messages).

Within Enter the length of time, in minutes, which FortiWeb uses to determine if the user has exceeded the maximum number of login attempts specified by Max Login Failures.

Take the configuration that maximum of 3 attempts within 5 minutes is allowed for a example, if a user fails the login for 3 times within the 5 minutes, FortiWeb will lock the user out for a specified period (Account Block Period). However, if the user fails login for 2 times within the 5 minutes, FortiWeb will not lock out the user for the third failure happens within next 5 minutes.
Account Block Period

Enter the length of time FortiWeb prevents a user from attempting to log in again after the user has exceeded the number of login attempts specified by Max Login Failures.

12.  Click Create New and in Rule, select the name of a site publishing rule.

13.  Repeat the previous step for each web application that is part of the SSO domain.

14.  Click OK.

15.  Select the site publishing policy in an inline web protection profile (see Configuring a protection profile for inline topologies). The profile must be used in the policy applying your domain’s virtual servers.

16.  To verify the configuration, log in to one of the web applications, then log in to another web application in the same domain that should be part of the SSO domain.

See also