Single Sign On

In This Section:

Introduction to Single Sign On

Single Sign On (SSO) eliminates the need for users to re-authenticate to an application when they access it for a second time, during a Mobile Access session, or between sessions. The authentication credentials used to log in to the Mobile Access portal can be re-used automatically to authenticate to multiple applications accessed through Mobile Access. You can also record other credentials for the application, and store them for future use. SSO user credentials are securely stored on Mobile Access and therefore remain valid even if the user logs in from a different client machine.

Supported SSO Authentication Protocol

Mobile Access supports Single Sign On for authentication to internal Web and other application servers. The supported authentication protocols are:

Basic Access - RFC enhancement. Not recommended because of security implications.
Digest Access - RFC enhancement.
Integrated Windows Authentication - RFC enhancement. Supports: NTLMv1, NTLMv2, and Kerberos.
Credential forwarding in HTTP headers - Ad hoc solution. Not recommended because of security implications.
Web form (HTML) based.

Certificate Attribute Forwarding

Certificate attribute forwarding is a Single Sign-on method that transfers details from a user's certificate to internal servers without the need for a username and password. It forwards the certificate attributes as HTTP headers to the internal servers when a user logs in with a certificate. Users can then log in to other applications automatically with Single Sign-on.

Configuring Certificate Attribute Forwarding

Configure Certificate attribute forwarding in the Mobile Access configuration file: $CVPNDIR/conf/cvpnd.C

Important! After every change to cvpnd.C, you must restart the cvpn services: cvpnrestart

To:	Parameter=value in `$CVPNDIR/conf/cvpnd.C`
Enable	`:EnableCertHeadersForwarding (true)`
Disable	`:EnableCertHeadersForwarding (false)`

To configure which attributes of the certificate are forwarded in the HTTP headers:

Add parameters to the CertHeaders section in $CVPNDIR/conf/cvpnd.C.

To forward:	Parameter=value in `$CVPNDIR/conf/cvpnd.C`
Complete certificate, encoded in base 64	`"`<header_name> `: CERT.BASE64"`
Certificate Issuer DN	`"`<header_name> `: CERT.ISSUER.DN"`
Serial number of the certificate	`"`<header_name> `: CERT.SERIAL"`
Subject DN	`"`<header_name> `: CERT.SUBJECT.DN"`
Alternative subject DN	`"`<header_name> `: CERT.ALTERNATIVESUBJECT.DN"`
Valid start date, before which the certificate cannot be used	`"`<header_name> `: CERT.VALIDITY.NOTBEFORE"`
Certificate expiration date	`"`<header_name> `: CERT.VALIDITY.NOTAFTER"`

Example:

To forward the certificate Issuer DN, edit cvpnd.C for this (where X-Cert-IssuerDN is the header name):

:EnableCertHeadersForwarding (true)

:CertHeaders (

: ("X-Cert-IssuerDN : CERT.ISSUER.DN")

)

HTTP Based SSO

For applications that perform authentication at the HTTP level, HTTP-based SSO is available, in which the credentials are forwarded in HTTP headers. This applies to the Basic, Digest, Integrated Windows Authentication, and Credential forwarding in HTTP headers authentication protocols.

When the user attempts to access these sites, a browser-specific form opens:

The user must enter his/her user name and password for that application, and click OK.

HTTP Based SSO Limitation

Single Sign On is not supported if:

The Web server requests authentication for a POST request in either the digest or Integrated Windows Authentication methods,
And the server does not support sending of "100 Continue" responses.

Web Form Based SSO

Most Web applications have their own Web forms for authentication. For these applications, Mobile Access supports Web form (HTML) based SSO.

The advantage of Web form based SSO authentication over HTTP authentication is that users are presented with the login page of the application itself, rather than a more obtrusive browser-specific page.

A typical Web form is shown below, for Outlook Web Access, together with a Mobile Access SSO popup that assists the user.

It is recommended to use the Web form based SSO for every application that is configured to work with Web form authentication. Do not enable Web form SSO for other applications, in order to maintain performance and connectivity.

Application Requirements for Easy Configuration

Web form based SSO in its default configuration can be configured by selecting a single check box in SmartDashboard. In order for the default settings to work, the application must:

Present the login form as the first form seen by the user.
Redirect (status 301 or 302) on login success.

Web Form Based SSO Limitations

Web form based SSO does not support:

Password remediation forms.
Forms that contain 'old/new/confirm' password fields. These fields are not recognized correctly, and wrong credentials might be recorded or forwarded.
Forms that use Ajax requests instead of the usual 'ACTION' attribute for form submission.

Configuring SSO Name Format

This feature prevents problems with SSO caused by different formats of credentials required by different applications. You configure the credential format for each application, and the Mobile Access gateway sends the credentials to the organizational server in the correct format. This applies to Web, Mobile Mail, and ActiveSync applications and works with Web Form based SSO.

Note - This feature is for LDAP users who connect to the Mobile Access portal. Internal users who connect to web applications though the portal with SSO authentication use a default of $$user.

For example, SSO can apply to both of these applications:

Web application A that uses the format domain\username
ActiveSync application B that uses the format username@domain

This feature is supported in R77.20 and higher. In R80.10 and higher you can configure it in SmartConsole.

To configure the format of credentials required for an application:

In SmartConsole, open a mobile application.
Select Additional Settings > Single Sign-on.
In the Credential Formats area, select an option.
Install Policy.

Application and Client Support for SSO

The following table shows which SSO methods are available for each Mobile Access application:

Mobile Access Application	Supports HTTP Based SSO	Supports Web Form Based SSO
Web applications	Yes	Yes
File shares	Yes	Not relevant
Citrix services	Yes	Yes
Web Mail	Simplified	No
Native applications	No	Not relevant
Mobile Mail	Yes	Not relevant
ActiveSync	Yes	Not relevant

Most Mobile Access Web Applications and Citrix Services support Web Form SSO, with either no configuration, or minimal configuration required. Some applications have been tested and found to require manual configuration (of the HTTP Post details). Some applications do not support Web Form SSO at all.

For a list of common applications that are certified by Check Point to work with Web Form SSO, see SecureKnowledge solution sk35080.

Basic SSO Configuration

To configure a basic SSO for a web application:

In SmartConsole, click Objects > Object Explorer (Ctrl+E).
Search for the Mobile Access application.
Double-click the application.
From the navigation tree click Additional Settings > Single Sign On.
Select Turn on Single Sign On for this application.
Configure the sign on method for the application. These are the default options:
For Web applications, File Shares and Citrix Services:
Prompt the users for their credentials and store them for future use

For Web Mail applications this same option is called:
Prompt user for credentials

With this option, the application credentials are stored and reused. The portal credentials are not used to authenticate to applications.
Install the policy.

Basic Configuration of Web Form SSO

Web form SSO is supported only for Mobile Access Web applications and Citrix services.

In the default settings, Web Form Single Sign On automatically analyzes the sign-in Web page of the application. The default settings assume:

HTTP redirect (301, 302) upon authentication success.
No redirect upon authentication failure.

To configure Web Form SSO with default settings:

In the Single Sign On page of the Mobile Access application, select This application uses a Web form to accept credentials from other users

Note - Only enable Web form SSO for applications that use a Web form to accept user credentials, in order to maintain performance and connectivity.

SSO for Native Applications

Native applications that you access with SSL Network Extender can use Single Sign-On (SSO) functionality. With SSO support, users connect automatically to native applications that require login. The native application gets the Mobile Access portal login username and password parameters from the internal server.

This feature is supported in R77.20 and higher. It requires a SSL Network Extender client upgrade.

Configuring SSO for Native Applications

Use the dynamic parameters $$user and $$password to configure SSO for a native application. These parameters are resolved to the actual username and password of the logged-in user when the gateway sends the parameters to the native application.

These instructions show you how to configure the new $$password parameter in for a Simple native application. You can also use the $$password parameter in the application parameters in Advanced native applications.

Note - When SSO is configured for a native application, it sends the end-user's password back to the client side.

To configure SSO for a native application:

In SmartConsole, click Objects > Object Explorer (Ctrl+E).
Search for the Mobile Access application.
Double-click the application.
Select Endpoint Applications from the navigation tree of the object.
Select Simple (Application is installed on the endpoint machine) and enter information for these fields:
- Path and executable name - Enter the path of the native application.
  For example for Remote Desktop Plus: D:\rdp.exe
- Parameters - Enter this syntax for the username, password, and target remote host to connect to.
  For example: /u:acme\$$user /p:$$password /v:192.0.2.2 /f
  This setting defines how the gateway sends the username and password of a locally logged-in user to the native application.
Install the policy.

Upgrading the SSL Network Extender Client to use SSO

Users must have an upgraded SSL Network Extender client on their computer to use SSO with native applications. To upgrade users' clients, make sure the Client upgrade setting is set to one of these:

Always upgrade - Clients are upgraded automatically when users connect for the first time after the gateway upgrade.
Ask user - Users are prompted before installation starts. If you use this option, make sure to let users know that they must confirm the upgrade.

Upgraded SSL Network Extender clients can still connect to gateways of earlier versions.

To change the Client upgrade settings:

In SmartConsole, select Security Policies > Shared Policies > Mobile Access and click Open Mobile Access Policy in SmartDashboard.
SmartDashboard opens and shows the Mobile Access tab.
From the navigation tree click Additional Settings > VPN Clients.
In Advanced Settings for SSL Network Extender, click Edit.
The SSL Network Extender - Advanced Settings window opens.
In the Deployment options section, make sure that Client upgrade upon connection is configured for Always upgrade or Ask user.
Click OK.
Click Save and then close SmartDashboard.
From SmartConsole, publish the changes and install the policy.

Advanced Configuration of SSO

The following configuration instructions apply to both HTTP based SSO and to Web form based SSO. The advanced configuration options are supported for Web applications, file shares, and Citrix services.

For configuration options that are specific to Web form SSO, see Advanced Configuration of Web Form SSO.

Configuring Advanced Single Sign On

There are a number of Single Sign On methods. The different options allow you to configure how to handle portal credentials, and how to handle other credentials used to authenticate to the application.

To configure the Single Sign On methods:

Go to the Single Sign On page of the Mobile Access application.
For the Advanced options, click Edit.

These are the available single sign on methods.

SSO Method	Single Sign On is On/Off	Forward portal credentials	Learn other credentials
Turn on Single Sign On for this application - Unchecked	Off Users are always prompted.	No	No
Prompt users for their credentials, and store them for future use	On Default method	No	Yes
This application reuses the portal credentials. Users are not prompted.	On Advanced method.	Yes	No
This application reuses the portal credentials. If authentication fails, Mobile Access prompts users and stores their credentials.	On Advanced method.	Yes	Yes

Configuring Login Settings

Login settings allow you to configure the default Windows domain (if Windows authentication is being used), to notify users that their credentials will be stored, and to specify a hint to help users supply the correct credentials.

To configure the login settings for Single Sign On:

Go the Single Sign On page of the Mobile Access application.
In the Login Settings section, click Edit.
The Login Settings window opens.
Fill in the fields according to the explanations below.

Windows Domain

The user of this application belongs to the following Windows domain:
Specify the Windows domain or workgroup (for example "LOCALDOMAIN") if Windows authentication is used. Integrated Windows authentication requires the domain to be forwarded with the user name and password.

If Accept the portal credentials from the gateway Single Sign On method is used, Mobile Access does not know the domain, because the user does not supply it with the portal credentials. The domain is fetched from the one specified here.

User Notification

Notify the users that their credentials for this application are going to be stored
When users access the application login page for the first time, they see a message that their credentials will be stored for future access.
Allow the users to specify that their credentials for this application will not be stored
When users access the application login page for the first time, they see a message from which they can select not to record their credentials.

Administrator Message

Show the following message together with the credentials prompt
Show a hint to the user about the credentials they must supply. for example, whether or not they should supply the domain name and user name (for example: AD/user) or just the user name (for example: user). After clicking the Help me choose credentials link, the user sees the hint. The message can include ASCII characters only.

Advanced Configuration of Web Form SSO

Use the advanced Single Sign On settings for Web form credentials to configure an application for Web form SSO if there is one of these:

No HTTP redirect (301, 302) upon authentication success
No redirect upon authentication failure.

You can specify different criteria for:

Sign In Success or Failure Detection
Credential Handling

Configuring Sign In Success or Failure Detection

To configure Sign In success or failure criteria:

In SmartConsole, click Objects > Object Explorer (Ctrl+E).
Search for the Mobile Access application.
Double-click the application.
The Web Application window opens.
From the navigation tree, click Additional Settings > Single Sign On.
In the Web Form section, click This application uses a Web form to accept credentials from users.
Click Edit.
Click Specify a criterion for success or failure and then select one of these options:
- Mobile Access regards the authentication as successful, if after signing in, this application creates a cookie with the following name:
  The application places a session cookie upon success. To obtain the exact name of the session cookie, install a sniffer or browser plug-in (such as the Fiddler HTTP debugging proxy)
- Mobile Access regards the authentication as a failure, if after signing in, this application redirects to the following URL:
  The application redirects on failure. To find the target URL, install a sniffer or browser plug-in (such as the Fiddler HTTP debugging proxy). Use this URL format:
  <protocol>://<host>/[<path>][?< query>]
Click OK and close the Web Application window.
Install the policy.

Credential Handling

By default, Mobile Access looks for the user name and password fields at the application URL. If the default settings do not work, you can either configure an automatic credential detection method, or you can manually hard-code the POST details.

To configure automatic credential handling:

In the Single Sign On page of the Mobile Access application, in the Web Form section, click Edit.
In the Credentials Handling section, click Edit.
The Credentials Handling window opens.
Select Automatically handle the credentials.
Under Sign in Web Form Detection Settings, select:
Mobile Access regards the following URL as the sign in Web form:

If the application presents a Web form that requires credentials, before the actual login form, so that Mobile Access is unable to automatically analyze the sign-in Web page, you can specify the URL of the actual login form.

Syntax:
<protocol>://<host>/[<path>][?< query>]
Under Password Validation Settings, select
Mobile Access sends the following password:
Clients need to submit the sign on Web form with a user name and password. However, it is not secure to store the password on the client for future SSO use. Mobile Access therefore generates a dummy password that it sends to the client, and replaces it upon sign on with the real password. Some applications check the dummy password on the client side. If the Mobile Access dummy password is not compatible with the application, you can define a different one.

Note - This password cannot include special characters. Use ASCII characters only.

Manually Defining HTTP Post Details

If automatic Web form SSO does not work, you can define HTTP POST details.

To manually specify how to handle credentials:

From the Credentials Handling window, select Manually specify how to handle the credentials.
Fill in the fields for When the following sign in URL is requested:
- post to the following URL
  In this and the previous field, the URL must be absolute. Use the URL format
  <protocol>://<host>/[<path>][?< query>]
- the following POST data, which must include:
  - $USERNAME resolves to the user name stored on Mobile Access.
  - $PASSWORD resolves to the password stored on Mobile Access.
  - $DETAILS resolves to the Windows domain stored on Mobile Access

When manual credential handling is configured for Web form SSO, the HTTP authentication request window appears, when credentials are requested for the first time.

Kerberos Authentication Support

Kerberos is a network protocol that lets people and computers securely authenticate over a non-secure network. In Windows 2000 and higher, Kerberos is the default authentication protocol.

Kerberos Authentication is supported for Web Applications (HTTP and HTTPS). Mobile Access can authorize against Kerberos servers on behalf of users.
Microsoft IIS and other web servers employ Kerberos using the Negotiate method in HTTP authentication headers.
Kerberos is sensitive to time differences between the Security Gateway and Domain Controller. Make sure clocks on the Mobile Access gateway and on the domain controller(s) are synchronized to within 1 minute. The best way to ensure this is to use an NTP time server.
By default, NTLM authentication is preferred as the authentication method over Kerberos authentication. To prefer Kerberos over NTLM, follow the instructions in sk106848.

To use Kerberos with Mobile Access:

If Microsoft Active Directory is configured, the gateway automatically updates with the relevant settings from the AD Account Unit and Kerberos enabled. You can review the Kerberos settings in $CVPNDIR/var/krb5.auto.conf
Warning: Do not manually edit krb5.auto.conf.
If you must make a change to krb5.auto.conf, do it in the template file, krb5.auto.conf.template. The template is used to create the krb5.auto.conf file.
To edit krb5.auto.conf.template:
1. Open $CVPNDIR/var/krb5.auto.conf.template and add your changes.
  The file contains Kerberos conf file information and place holders for the Account Unit settings - the place holders are in the form of <++PlaceHolderName++>.
  
  Important: Do not change the place holder names.
2. On the gateway, run: cvpnd_admin policy
  Example of the template file, krb5.auto.conf.template:
  
  [libdefaults]
  <++libdefaults++>
  rdns = false
  [realms]
  <++realms++>
  [domain_realm]
  <++domain_realm++>
  
  Example of how it looks in krb5.auto.conf:
  
  [libdefaults]
  default_realm = EXAMPLE.COM
  rdns = false
  [realms]
  EXAMPLE.COM = {
  kdc = 192.168.1.1
  }
  [domain_realm]
If Microsoft Active Directory is not yet configured for Mobile Access, but you want to use it:
1. Use the Mobile Access wizard to configure your AD.
2. Edit the SmartDashboard Network Objects for the AD server and for the gateway.
If you do not want to use Microsoft Active Directory, manually configure Kerberos for your environment.

Configuring Microsoft Active Directory for Mobile Access

These steps assume you defined the Microsoft AD server as a Check Point LDAP Account Unit object. If that object does not exist, create one: Objects > New > More > Server > LDAP Account Unit.

To make sure Microsoft Active Directory is configured for the default settings:

In the SmartConsole, go to Objects > Servers > LDAP Account Units.
Right-click the LDAP AD server and select Edit.
In the General tab of the LDAP Account Unit Properties window, the value of Profile is Microsoft_AD.
Make sure the value of Domain is correct for the AD Domain.
Click OK and publish the changes.

To configure Microsoft Active Directory server priorities:

Open the object for the Security Gateway with Mobile Access enabled.
If there is more than one, do these steps for each.
Open Other > User Directory.
By default, the gateways use all Domain Controllers of the AD. If there is a connectivity issues (no or poor connectivity) from a gateway to a Domain Controller, adjust the priorities.
Make sure that Selected Account Units List is selected.
When this is selected, the Selected AUs list is available. If the list is empty, click Add to add an LDAP Account Unit defined for Microsoft_AD.
Select the Microsoft AD server.
The Servers priorities for selected AU is available.
Clear Use default priorities.
Select a host of the AD server.
The Priority field is available.
Set the priority of the host with connectivity issues to be lower than a different host.
For example: Priority 1 is highest. Priority 5 is lower.
Click Set.
Click OK.

Manual Configuration for Kerberos

If you are working with a directory that is not Microsoft AD, or experiencing problems with automatic configuration, manually configure Kerberos authentication.

To manually configure Kerberos:

Create $CVPNDIR/var/krb5.manual.conf.
Populate krb5.manual.conf with values that specify your domain addresses and domain controllers.
Use this format:

[libdefaults]
default_realm = YOUR.AD.NAME
[realms]
YOUR.AD.NAME = {
admin_server = your.domain.controller.name
default_domain = your.dns.domain
}
[domain_realm]
.your.dns.domain = YOUR.AD.NAME
your.dns.domain = YOUR.AD.NAME

In the file:
- YOUR.AD.NAME is the Windows domain name.
- To configure more than one Windows domain (also known as a “Realm”), add more domains to the [realms] section and to [domain_realm] section.
- If each realm has more than one domain controller, instead of the admin_server statement use several statements of the type:
  [realms]
  
  <DOMAIN_NAME> = {
  
  kdc = <1st domain controller address>
  
  kdc = <2nd domain controller address>
  
  }
Important: If you specify multiple domain addresses (realms) and domain controllers in krb5.manual.conf , you must also add them to the Mobile access configuration in $CVPNDIR/conf/cvpnd.C.

To add them, use these cvpnd_settings commands:

cvpnd_settings $CVPNDIR/conf/cvpnd.C listAdd kerberosRealms YOUR.AD.NAME

cvpnd_settings $CVPNDIR/conf/cvpnd.C listAdd kerberosRealms YOUR.OTHER.AD.NAME
Test the manual configuration:
1. Set KRB5_CONFIG as an environment variable in the shell to point to the relevant configuration file:
  - In the bash shell, run: export KRB5_CONFIG=$CVPNDIR/var/krb5.manual.conf
  - For tcsh or csh, run: setenv KRB5_CONFIG $CVPNDIR/var/krb5.manual.conf
2. From the Mobile Access gateway command line, run: kinit your-ad-username.
  - If there are several realms, the kinit syntax applies to the default realm.
  - For other realms, use the syntax: kinit your-ad-username@YOUR.OTHER.AD.NAME
  You should get a prompt similar to: Password for your-ad-username@YOUR.DOMAIN:
3. Enter the password.
4. Run: klist
  The Ticket cache list shows one ticket.
5. Delete the list by running: kdestroy.
Open $CVPNDIR/conf/cvpnd.C for editing.
Change the value of the kerberosConfigMode attribute from auto to manual.
Alternatively, run: cvpnd_settings $CVPNDIR/conf/cvpnd.C set kerberosConfigMode manual

Note: If you assign the value none to kerberosConfigMode, it disables Kerberos SSO.
Run: cvpnrestart.

Important: In a cluster environment, repeat steps 1 to 6 on each cluster member.

Kerberos Constrained Delegation

Kerberos constrained delegation is a Single Sign-on method that uses Kerberos authentication for users to access internal resources without the need to enter a password. It is supported for the Mobile Access portal and Capsule Workspace.

To enable Kerberos constrained delegation:

On the Mobile Access gateway, run:
cvpnd_settings $CVPNDIR/conf/cvpnd_internal_settings.C set EnableKCD true
Run cvpnrestart on the gateway.
In a cluster environment, repeat the steps on all cluster members.

Configuring Kerberos Constrained Delegation

Before you begin, make sure:

That your site supports Kerberos authentication.
The Mobile Access-enabled gateway is configured to support Kerberos.
The date and time on the gateway and Active Directory server are the same.
You must use FQDN and not an IP address with your internal server name. Make sure that the FQDN resolves both on the Security Gateway and on the Kerberos server.

The configuration includes:

Configuring a Delegate User on the AD Server.
Configuring Kerberos Constrained Delegation support on the Mobile Access gateway.

Configuring a Delegate User on the AD Server

A delegate user can have specified permissions without being part of a higher privileged group. For Kerberos Constrained Delegation, the delegate user can allow access to other users for specified services.

To configure a delegate user on the Active Directory (AD) server:

Add a new user to the AD server.
Open the command prompt on the AD server and run the command:
setspn –A HTTP/<user name> <domain name>\<user name>

<user name> - The user name for the user that was created.

<domain name> - The domain name that the created user belongs to.
From the Users and Computers tree, right-click the user to open the User Properties of the new user.
Click the Delegation tab.
Select: Trust this user for delegation to specified services only.
Select: Use any authentication protocol.
In the Services to which this account can present delegated credentials table, click Add to add http on the server that the user is allowed to access.
Click OK.

Configuring Kerberos Constrained Delegation Support

Kerberos Constrained Delegation is supported with Web Applications and Mobile Mail applications.

To configure Kerberos Constrained Delegation in SmartDashboard:

In SmartConsole, click Objects > Object Explorer (Ctrl+E).
Search for the Mobile Access application.
Double-click the application for which you want to configure Kerberos Constrained Delegation.
The Web Application window opens.
From the navigation tree click Additional Settings > Single Sign On.
Configure these settings:
- Select Turn on Single Sign On for this application
- Select Advanced
Click Edit.
In the Advanced window, select This application reuses the portal credentials. Users are not prompted.
Click OK and close the Web Application window.
Install the policy.

Troubleshooting

If you have issues with Kerberos Constrained Delegation:

Make sure that the value of EnableKCD in $CVPNDIR/conf/cvpnd_internal_settings.c is true.
Run: cvpnrestart on the gateway through SSH and see if there is a Kerberos Constrained Delegation failure entry in the Mobile Access logs in SmartLog.
Make sure that the account unit credentials have delegate privileges.
Make sure that the date and time of the gateway and Active Directory server are synchronized.
Make sure that the DNS server is configured correctly and the gateway can resolve the web application host name and the Active Directory server.