Single Sign On

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 Check Point Software Blade on a Security Gateway that provides a Remote Access VPN access for managed and unmanaged clients. Acronym: MAB. 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 An authentication server for Microsoft Windows Active Directory Federation Services (ADFS)..

• Credential forwarding in HTTP headers - Ad hoc solution. Not recommended because of security implications.

• Web form (HTML) based.

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 Legacy Check Point GUI client used to create and manage the security settings in versions R77.30 and lower. In versions R80.X and higher is still used to configure specific legacy settings.. 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 Security Gateway Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources. 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.

To configure the format of credentials required for an application:

1. In SmartConsole Check Point GUI application used to manage a Check Point environment - configure Security Policies, configure devices, monitor products and events, install updates, and so on., open a mobile application.

2. Select Additional Settings > Single Sign-On.

3. In the Credential Formats area, select an option.

4. Install Policy.

Application and Client Support for SSO

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

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

Basic SSO configuration for a web application:

1. In SmartConsole, click Objects > Object Explorer (Ctrl+E).

2. Search for the Mobile Access application.

3. Double-click the application.

4. From the navigation tree click Additional Settings > Single Sign On.

5. Select Turn on Single Sign On for this application.

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

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

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

Procedure:

1. In SmartConsole, click Objects > Object Explorer (Ctrl+E).

2. Search for the Mobile Access application.

3. Double-click the application.

4. Select Endpoint Applications from the navigation tree of the object.

5. 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 Security Gateway sends the username and password of a locally logged-in user to the native application.

6. 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 Security 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 Security Gateways of earlier versions.

Procedure:

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

2. From the navigation tree click Additional Settings > VPN Clients.

3. In Advanced Settings for SSL Network Extender, click Edit.

   The SSL Network Extender - Advanced Settings window opens.

4. In the Deployment options section, make sure that Client upgrade upon connection is configured for Always upgrade or Ask user.

5. Click OK.

6. Click Save

7. Close SmartDashboard.

8. 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 the "Single Sign On" section.

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.

1. Go to the Single Sign On page of the Mobile Access application.

2. For the Advanced options, click Edit.

These are the available single sign on methods.

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.

1. Go the Single Sign On page of the Mobile Access application.

2. In the Login Settings section, click Edit.

   The Login Settings window opens.

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

1. In SmartConsole, click Objects > Object Explorer (Ctrl+E).

2. Search for the Mobile Access application.

3. Double-click the application.

   The Web Application window opens.

4. From the navigation tree, click Additional Settings > Single Sign On.

5. In the Web Form section, click This application uses a Web form to accept credentials from users.

6. Click Edit.

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

8. Click OK and close the Web Application window.

9. Install the policy.

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

1. In the Single Sign On page of the Mobile Access application, in the Web Form section, click Edit.

2. In the Credentials Handling section, click Edit.

3. Select Automatically handle the credentials.

4. 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>]

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

Manual Credential Handling (Configuring HTTP Post Settings)

By default, Mobile Access looks for the user name and password fields at the application URL.

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

1. From the Credentials Handling window, select Manually specify how to handle the credentials.

2. 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 Security 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 Security Gateway automatically updates with the relevant settings from the AD Account Unit and Kerberos enabled.

  You can review the Kerberos settings in the $CVPNDIR/var/krb5.auto.conf file.

  Warning - Do not edit the krb5.auto.conf file manually.

• 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 file:

  1. Edit the $CVPNDIR/var/krb5.auto.conf.template file 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 Security 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 the file 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 Single Sign On.

• If you do not want to use Microsoft Active Directory, manually configure Kerberos for your Single Sign On.

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:

1. In the SmartConsole, go to Objects > Servers > LDAP Account Units.

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

3. Make sure the value of Domain is correct for the AD Domain.

4. Click OK.

5. Publish the SmartConsole session.

To configure Microsoft Active Directory server priorities:

1. Open the object for the Security Gateway with Mobile Access enabled.

   If there is more than one, do these steps for each.

2. Open Other > User Directory.

   By default, the Security Gateways use all Domain Controllers of the AD. If there is a connectivity issues (no or poor connectivity) from a Security Gateway to a Domain Controller, adjust the priorities.

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

4. Select the Microsoft AD server.

   The Servers priorities for selected AU is available.

5. Clear Use default priorities.

6. Select a host of the AD server.

   The Priority field is available.

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

8. Click Set.

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

1. Create the $CVPNDIR/var/krb5.manual.conf file.

2. Populate the krb5.manual.conf file 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> }

To add them, use these cvpnd_settings commands:

1. Test the manual configuration:

   1. Set KRB5_CONFIG as an environment variable in the shell to point to the relevant configuration file:

      • In the Expert mode (Bash shell), run:

        export KRB5_CONFIG=$CVPNDIR/var/krb5.manual.conf

      • In the Tcsh or Csh shell, run:

        setenv KRB5_CONFIG $CVPNDIR/var/krb5.manual.conf

   2. From the Mobile Access Security Gateway command line, run in the Expert mode (Tcsh, or Csh):

      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.

2. Open $CVPNDIR/conf/cvpnd.C for editing.

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

4. Run:

   cvpnrestart

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:

1. On the Mobile Access Security Gateway, run:

   cvpnd_settings $CVPNDIR/conf/cvpnd_internal_settings.C set EnableKCD true

2. Run:

   cvpnrestart

3. 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 Security Gateway is configured to support Kerberos. .

• The date and time on the Security 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 Security 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.

1. Add a new user to the AD server.

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

3. From the Users and Computers tree, right-click the user to open the User Properties of the new user.

4. Click the Delegation tab.

5. Select: Trust this user for delegation to specified services only.

6. Select: Use any authentication protocol.

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

8. Click OK.

Configuring Kerberos Constrained Delegation Support

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

1. In SmartConsole, click Objects > Object Explorer (Ctrl+E).

2. Search for the Mobile Access application.

3. Double-click the application for which you want to configure Kerberos Constrained Delegation.

   The Web Application window opens.

4. From the navigation tree click Additional Settings > Single Sign On.

5. Configure these settings:

   • Select Turn on Single Sign On for this application

   • Select Advanced

6. Click Edit.

7. In the Advanced window, select This application reuses the portal credentials. Users are not prompted.

8. Click OK and close the Web Application window.

9. Install the policy.

Troubleshooting issues with Kerberos Constrained Delegation:

1. Connect to the command line on the Mobile Access Security Gateway.

2. Make sure that the value of EnableKCD in $CVPNDIR/conf/cvpnd_internal_settings.C is true.

3. Run the cvpnrestart command.

4. See if there is a Kerberos Constrained Delegation failure entry in the Mobile Access logs in SmartLog.

5. Make sure that the account unit credentials have delegate privileges.

6. Make sure that the date and time of the Security Gateway and Active Directory server are synchronized.

7. Make sure that the DNS server is configured correctly and the Security Gateway can resolve the web application host name and the Active Directory server.

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.

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

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

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

Example:

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

:EnableCertHeadersForwarding (true)
:CertHeaders (
    : ("X-Cert-IssuerDN : <DN of the Certificate Issuer>"
)