Sign-In Policies

29 min

About Sign-In Policies

Sign-in policies define the URLs that users and administrators use to access the device and the sign-in pages that they see. The system has two types of sign-in policies-one for users and one for administrators. When configuring sign-in policies, you associate realms, sign-in pages, and URLs.

For example, in order to allow all users to sign in to the device, you must add all user authentication realms to the user sign-in policy. You may also choose to modify the standard URL that the end-users use to access the system and the sign-in page that they see. Or, if you have the proper license, you can create multiple user sign-in policies, enabling different users to sign into different URLs and pages.

You can create multiple sign-in policies, associating different sign-in pages with different URLs. When configuring a sign-in policy, you must associate it with a realm or realms. Then, only members of the specified authentication realm(s) may sign in using the URL defined in the policy. Within the sign-in policy, you may also define different sign-in pages to associate with different URLs.

For example, you can create sign-in policies that specify:

Members of the "Partners" realm can sign in to the device using the URLs: partner1.yourcompany.com and partner2.yourcompany.com. Users who sign into the first URL see the "partners1" sign-in page; users who sign into the second URL see the "partners2" sign-in page.

Members of the "Local" and "Remote" realms can sign into the device using the URL: employees.yourcompany.com. When they do, they see the "Employees" sign-in page.

Members of the "Admin Users" realm can sign into the device using the URL: access.yourcompany.com/super. When they do, they see the "Administrators" sign-in page.

When defining sign-in policies, you may use different hostnames (such as partners.yourcompany.com and employees.yourcompany.com) or different paths (such as yourcompany.com/partners and yourcompany.com/employees) to differentiate between URLs.

If a user attempts to sign in while there is another active user session with the same sign-in credentials, the system displays a warning page showing the IP address of the existing session and two buttons: Continue and Cancel. By clicking the Cancel button, the user terminates the current sign-in process and redirects the user back to the Sign-in page. By clicking the Continue button, the system creates the new user session and terminates the existing session.

When enabling multiple sign-in URLs, note that in some cases the system must use cookies on the user's machine to determine which sign-in URL and corresponding sign-in page to display to the user. The system creates these cookies when the user signs into the device. (When a user signs into the device, the system responds with a cookie that includes the sign-in domain of the URL. The system then attaches this cookie to every system request the user makes.) Generally, these cookies ensure that the system displays the correct sign-in URL and page to the user. For example, if a user signs into the device using the URL http://yourcompany.net/employees and then her session times out, the system uses the cookie to determine that it must display the http://yourcompany.net/employees sign-in URL and corresponding page to the user when she requests another system resource.

However, in isolated cases, the cookie on the user's machine may not match the resource she is trying to access. The user may sign into one URL and then try to access a resource that is protected by a different URL. In this case, the system displays the sign-in URL and corresponding sign-in page that the user signed into most recently. For example, a user may sign into the device using the sign-in URL http://yourcompany.net/employees. Then she may try to access the system resource using a link on an external server, such as https://yourcompany.net/partners/dana/term/winlaunchterm.cgi?host=<termsrvIP>. Or, she may try to open a bookmark that she created during a different session, such as https://yourcompany.net/partners/,DanaInfo=.awxyBmszGr3xt1r5O3v.,SSO=U+. In these cases, the system would display the http://yourcompany.net/employees sign-in URL and page to the user, rather than the sign-in URL or page that is associated with the external link or saved bookmark that she is trying to access.

Sign-in policies and pages are an integral part of the access management framework, and therefore are available in all Ivanti Connect Secure products.

Task Summary: Configuring Sign In Pages

To configure sign-in policies, you must:

Create an authentication realm through the Administrators > Admin Realms or the Users > User Realms page of the admin console.

(Optional) Modify an existing sign-in page or create a new one using options in the Authentication > Signing In > Sign-in Pages page of the admin console.

Specify a sign-in policy that associates a realm, sign-in URL, and sign-in page using settings in the Authentication > Signing In > Sign-in Policies page of the admin console.

If you differentiate between URLs using hostnames, you must associate each hostname with its own certificate or upload a wildcard certificate into the system using options in the System > Configuration > Certificates > Device Certificates page.

About Configuring Sign In Policies

User sign-in policies also determine the realm(s) that users and administrators can access.

Depending on whether a sign-in policy is for endpoints (users) or administrators, the configuration options are different. For users, different authentication protocol sets can be configured, and realm selection is based on the authentication method that is associated with the realm.

Configuring User Sign In Policies

To create or configure user sign-in policies:

In the admin console, select Authentication > Signing In > Sign-in Policies.

To create a new sign-in policy, click New URL. Or, to edit an existing policy, click a URL in the Administrator URLs or User URLs column.

Select Users or Administrators to specify which type of user can sign in using the access policy.

In the Sign-in URL field, enter the URL that you want to associate with the policy. Use the format <host>/<path> where <host> is the hostname of the device, and <path> is any string you want users to enter. For example: partner1.yourcompany.com/outside. To specify multiple hosts, use the * wildcard character.

To specify that all administrator URLs should use the sign-in page, enter */admin.

You may only use wildcard characters (*) in the beginning of the hostname portion of the URL. The system does not recognize wildcards in the URL path.

SAML authentication does not support sign-in URLs that contain multiple realms. Instead, map each sign-in URL to a single realm.

(optional) Enter a Description for the policy.

From the Sign-in Page list, select the sign-in page that you want to associate with the policy. You may select the default page that comes with the system, a variation of the standard sign-in page, or a custom page that you create using the customizable UI feature.

Under Authentication realm, specify which realm(s) map to the policy, and how users and administrators should pick from amongst realms. If you select:

User types the realm name-The system maps the sign-in policy to all authentication realms, but does not provide a list of realms from which the user or administrator can choose. Instead, the user or administrator must manually enter his realm name into the sign-in page.

User picks from a list of authentication realms-The system only maps the sign-in policy to the authentication realms that you choose. The system presents this list of realms to the user or administrator when he signs-in to a device and allows him to choose a realm from the list. (Note that the system does not display a drop-down list of authentication realms if the URL is only mapped to one realm. Instead, it automatically uses the realm you specify.)

If you allow the user to pick from multiple realms and one of those realms uses an anonymous authentication server, the system does not display that realm in the drop-down realm list. To effectively map your sign-in policy to an anonymous realm, you must add only that realm to the Authentication realm list.

Click Save Changes.

To enable and disable sign-in policies:

In the admin console, choose Authentication > Signing In > Sign-in Policies.

To enable or disable:

An individual policy-Select the check box next to the policy that you want to change, and then click Enable or Disable.

All user policies-Select or deselect the Restrict access to administrators only check box at the top of the page.

If you select this option, all user sessions are immediately terminated. If this device is part of a cluster, all user sessions across all nodes in the cluster are immediately terminated.

Click Save Changes.

The system evaluates sign-in policies in the same order that you list them on the Sign-in Policies page. When it finds a URL that matches exactly, it stops evaluating and presents the appropriate sign-in page to the administrator or user. For example, you may define two administrator sign-in policies with two different URLs:

The first policy uses the URL */admin and maps to the default administrator sign-in page.

The second policy uses the URL yourcompany.com/admin and maps to a custom administrator sign-in page.

If you list the policies in this order on the Sign-in Policies page, the system never evaluates or uses the second policy because the first URL encompasses the second. Even if an administrator signs in using the yourcompany.com/admin URL, the system displays the default administrator sign-in page. If you list the policies in the opposite order, however, the system displays the custom administrator sign-in page to those administrators who access the system using the yourcompany.com/admin URL.

Note that the system only accepts wildcard characters in the hostname section of the URL and matches URLs based on the exact path. For example, you may define two administrator sign-in policies with two different URL paths:

The first policy uses the URL */marketing and maps to a custom sign-in page for the entire Marketing Department.

The second policy uses the URL */marketing/joe and maps to a custom sign-in page designed exclusively for Joe in the Marketing Department.

If you list the policies in this order on the Sign-in Policies page, the system displays Joe's custom sign-in page to him when he uses the yourcompany.com/marketing/joe URL to access the device. He does not see the Marketing sign-in page, even though it is listed and evaluated first, because the path portion of his URL does not exactly match the URL defined in the first policy.

To change the order in which administrator sign-in policies are evaluated:

In the admin console, choose Authentication > Signing In > Sign-in Policies.

Click the up and down arrows to change the selected policy's placement in the list.

Click Save Changes.

Configuring Fallback Authentication Server

In case the remote authentication server is not reachable, a local authentication server acts as a fallback.

This feature is currently available in the AD server and LDAP servers.

The administrator can use a randomly generated URL to sign in. The local authentication server

supports the randomly generated URL to sign in within 10 minutes of generation. The URL is randomly

generated and provided on the Admin login screen. Disabling the URL is optional.

To set a fallback URL:

In the Admin UI choose Authentication > Signing In > Sign-in Policies.

Create a new Administrator URL in Authentication > Signing In > Sign-in Policies > Admin URL configuration with localauth and disable the same.

Under the Configure Fallback URL select the option for fallback.

Select the Backup URL from the dropdown created in step 3 above and Save changes.

About Sign-In Notifications

With sign-in notifications, you can create and configure detailed notification messages that appear for Ivanti Secure Access Client and for agentless access endpoints when the user attempts to sign in. For example, you could configure a notification message that explains terms of use, company-specific policies, a welcome page, an end user license agreement (EULA), or a message of the day (MOTD).

For a browser-based (agentless) login, the notification message appears in a separate page either before (pre-auth) or after (post-auth) user authentication during the sign-in process. For a Ivanti Secure Access Client login, the notification messages appear in a Ivanti message box. The user is expected to read the content of the sign-in notification message and acknowledge by clicking a Proceed button. The user may indicate disagreement by clicking a Decline button, which ends the login attempt.

You can configure a sign-in policy to use a sign-in notification either as pre-auth or post-auth (or both). In the case of post-auth configuration, you can either use a common message for all roles or use separate messages for each role.

You can create a multi-language sign-in notification package that relies on the language setting of the endpoint. You can customize the sign-in notification page appearance for browser-based logins by modifying the related fields in a sign-in page in the Admin UI or by using a custom sign-in page.

Sign-in notifications are supported on Windows, Mac, and for browser-based access on mobile devices. However, sign-in notifications might not work well with all mobile devices due to device limitations.

Sign-in notifications (including uploaded packages) are included in XML exports.

If a Ivanti session is resumed or extended, the pre-auth notification message is not shown again. However, if the user switches roles when resuming a session, and that role change results in a new notification, Ivanti displays the message. You can configure the post-auth message to be skipped if it has already been seen. If the post-auth message is not marked to be skipped, then it always appears.

Configuring and Implementing Sign-in Notifications

Sign-in notifications appear for Ivanti Secure Access Client and for browser-based logins when the user attempts to sign in.

To configure and implement sign-in notifications:

In the admin console, select Authentication > Signing In > Sign-in Notifications.

Click New Notification.

Specify a Name for the notification. This name appears in the sign-in policies page, and in the UI Options page for a selected role.

Select Text or Package in the Type box.

If you select Text, type the desired sign-in notification message, or copy and paste the relevant text into the Text field.

If you select Package, click the Browse button and navigate to a previously prepared .zip file. A package is typically used to provide different language versions of the notification message.

The zip file should include a default.txt file and one or more <language>.txt files (Example: en.txt).

Language-abbreviations should be strings that can appear in Accept-Language header of an HTTP request. For example:

Upload a zip file containing files with name format: <language-abbreviation>.txt (Example: en.txt).

Include 'default.txt' and one file for each language you want to support.

Language-abbreviations should be strings that can appear in Accept-Language header of an HTTP request.

The character encoding supported is UTF-8.

When you create a zip file, do not add the folder containing the files, but add the files directly.

Click Save Changes.

To enable sign-in notifications:

In the admin console, click Authentication > Signing In > Sign-in Policies.

Select an existing URL or create a new URL.

Under Configure Sign-in Notifications, select the check box for Pre-Auth Sign-in Notification, Post-Auth Sign-in Notification, or both.

After Pre-Auth Sign-in Notification, select a previously configured sign-in notification from the drop-down menu.

After Post-Auth Sign-in Notification, select the option for Use a common Sign-in Notification for all roles or Use the Sign-in Notification associated to the assigned role.

If you select Use a common Sign-in Notification for all roles, select a previously configured sign-in notification from the drop-down menu.

If you select Use the Sign-in Notification associated to the assigned role, the sign-in notification configured for the assigned role will be used.

Prevent the Post-Auth sign-in notification from being displayed to users who have seen it before, by selecting the Skip if already shown check box. (This is only a hint to the system and might not be honored in all environments.)

Click Save Changes.

You can customize the appearance of the sign-in notification message by selecting Authentication > Signing In > Sign-in Pages and creating a sign-in page or using an existing page.

Under Sign-in Notification appearance, customize UI options for Pre-Auth Notifications and Post-Auth Notifications by changing the following items:

For Notification Title enter the text that appears at the top of the sign-in notification page.

In the Proceed Button box, enter the text for the button that the user clicks to proceed with the sign-in.

This text applies to browser-based logins only. A Ivanti Secure Access Client login always displays Proceed.

Optionally, clear the check box for Display "Decline" Button. If this box is not checked, the user does not have the option to decline.

In the Decline Button box, enter the text for the button that the user clicks to decline.

This text applies to browser-based logins only. A Ivanti Secure Access Client login always displays Decline.

In the Message on Decline box, enter the text that you would like to appear when a user clicks the Decline button.

Click Save Changes.

When Console Protection is enabled for the ICS console, the Sign-In Notification configured for /admin Sign-In URL is displayed on the ICS Console. However, if the Sign-In Notification is loaded from a package, a default banner message is displayed on the console.

If you enabled Use the Sign-in Notification associated to the assigned role you must complete the implementation by selecting the sign-in notification on the Users > User Roles > Role Name > General > UI Options page or Administrators > Admin Roles > Role Name > General > UI Options page, as applicable.

If more than one role is available to a user, the sign-in notification associated with the first role assigned is displayed.

Add the sign-in page in which you have customized the sign-in notification appearance to the sign-in policy.

Defining Authorization-Only Access Policies

Authorization-only access is similar to a reverse proxy. Typically, a reverse proxy is a proxy server that is installed in front of webservers. All connections coming from the Internet addressed to one of the webservers are routed through the proxy server, which may either deal with the request itself or pass the request wholly or partially to the main webserver.

With an authorization-only access, you select a user role. the system then acts as reverse proxy server and performs authorization against the server for each request.

For example, the authorization-only access feature satisfies the following business needs:

If you have a third-party AAA policy management server, the system acts as an authorization-only agent.

If your user sessions are managed by a third-part session management system, there is no need to duplicate the user session management in the system.

With authorization-only access, there is no SSO from the system. SSO is controlled by your third-party AAA infrastructure.

Before defining this policy, you must first configure your server and define your hostnames in the Network Configuration page.

You must also specify settings in the server authorization settings section of the authentication server page. Users are redirected to the URL specified in the If Automatic Sign In fails, redirect to field when the SMSESSION cookie validation fails or if no SMSESSION cookie exists. Users are redirected to the URL specified in the If authorization fails, redirect to field when an access denied error occurs.

To create or configure authorization-only access policies:

In the admin console, choose Authentication > Signing In > Sign-in Policies.

To create a new authorization only access policy, click New URL and select authorization only access. Or, to edit an existing policy, click a URL in the Virtual Hostname column.

In the Virtual Hostname field, enter the name that maps to the system's IP address. The name must be unique among all virtual hostnames used in pass-through proxy's hostname mode. The hostname is used to access backend application entered in the Backend URL field. Do not include the protocol (for example, http:) in this field. For example, if the virtual hostname is myapp.ivehostname.com, and the backend URL is http://www.xyz.com:8080/, a request to https://myapp.ivehostname.com/test1 via the system is converted to a request to http://www.xyz.com:8080/test1. The response of the converted request is sent to the original requesting web browser.

In the Backend URL field, enter the URL for the remote server. You must specify the protocol, hostname and port of the server. For example, http://www.mydomain.com:8080/*. When requests match the hostname in the Virtual Hostname field, the request is transformed to the URL specified in the Backend URL field. The client is directed to the backend URL unaware of the redirect.

(optional) Enter a Description for this policy.

Select the server name or No Authorization from the Authorization Server drop-down menu. If you select a server, ensure that the front-end server provides the SMSESSION cookie otherwise you will receive an error.

Select a user role from the Role Option drop-down menu. Only the following user role options are applicable for authorization-only access.

Allow browsing un-trusted SSL web sites (Users > User Roles > RoleName > Web > Options > View advanced options)

HTTP Connection Timeout (Users > User Roles > RoleName > Web > Options > View advanced options)

Source IP restrictions (Users > User Roles > RoleName > General > Restrictions)

Browser restrictions (Users > User Roles > RoleName > General > Restrictions)

Ensure the user role you select has an associated Web Access policy.

Select the Allow ActiveSync Traffic only option to perform a basic of validation of the HTTP header to ensure the request is consistent with ActiveSync protocol. If you select this option only ActiveSync protocol requests can be processed. If validation fails, a message is created in the user's event log. If you do not select this option, both ActiveSync and non-ActiveSync requests are processed.

Select the Kerberos Constrained Delegation Label option to configure a KCD policy for Active Sync. This would list the existing configured Constrained Delegation labels. Selecting any one of the valid Constrained Delegation labels would force to use KCD for the Exchange Active Sync traffic. Also, this option is applicable only for Active Sync traffic.

This option also has the following dependencies:

Enforce client certificate requirement on virtual ports which are used for Active Sync.

Appropriate CA certificate should be imported under Trusted Client CAs.

The role configured to use for Active Sync should be configured to have Certificate Restrictions to Only allow users with a client-side certificate signed by Certification Authority to sign in.

Appropriate Constrained Delegation policy should be configured. Please refer to the section "Constrained Delegation" under configuring SSO policies

External configurations should be appropriately configured to support Constrained Delegation SSO; Exchange server should be configured to allow Kerberos authentication, i.e., Windows Authentication.

If Kerberos Constrained Delegation Label policy is chosen, enter the appropriate Username Template from certificate attributes.

Click Save Changes to save your edits. The System Status Overview page displays the number of current active concurrent connections and a histogram of the active concurrent connections (Authorization Only Access Active Connections plot in the Concurrent SSL Connections graph).

Configuring Sign-In Pages

A sign-in page defines the customized properties in the end-user's welcome page such as the welcome text, help text, logo, header, and footer. The system allows you to create two types of sign-in pages to present to users and administrators:

Standard sign-in pages-Standard sign-in pages are produced by Ivanti and are included with all versions of the Ivanti Connect Secure software. You can modify standard sign-in pages through the Authentication > Signing In > Sign-in Pages tab of the admin console.

Configuring Standard Sign-In Pages

Standard sign-in pages that come with the system include:

Default Sign-In Page-the system displays this page to users when they sign into the device.

You can modify the default sign-in page that the system displays to users when they sign into the device. You can also create new standard sign-in pages that contain custom text, logo, colors, and error message text using settings in the Authentication > Signing In > Sign-in Pages tab of the admin console.

To create or modify a standard sign-in page:

In the admin console, select Authentication > Signing In > Sign-in Pages.

If you are:

Creating a new page-Click New Page.

Modifying an existing page-Select the link corresponding to the page you want to modify.

(New pages only) Under Page Type, specify whether this is an administrator/user access page.

Enter a name to identify the page.

In the Custom text section, revise the default text used for the various screen labels as desired. When adding text to the Instructions field, note that you may format text and add links using the following HTML tags: <i>, <b>, <br>, <font>, <noscript>, and <a href>. However, the system does not rewrite links on the sign-in page (since the user has not yet authenticated), so you should only point to external sites. Links to sites behind a firewall will fail. If you use unsupported HTML tags in your custom message, the system may display the end-user's home page incorrectly.

Custom text of Instructions appears on the bottom left-hand side of the sign-in page.

In the Header appearance section, specify a custom logo image file for the header. Also specify Fav Icon to appear on title bar and a different header color. Select the Display Background Image check box to display the background image on welcome page.

Select the Background Color from palette or type hexadecimal RGB in the text box to change the background color on sign-in page.

If the Display Background Image option is enabled, custom text of Instructions need to be wrapped with a font color of white.

If the Display Background Image option is disabled, custom text of Instructions need to be wrapped with a font color of black.

In the Custom error messages section, revise the default text that is displayed to users if they encounter certificate errors.

You can include <<host>>, <<port>>, <<protocol>>, and <<request>> variables and user attribute variables, such as <<userAttr.cn>> in the custom error messages. Note that these variables must follow the format <variable> to distinguish them from HTML tags which have the format <tag>.

To provide custom help or additional instructions for your users, select Show Help button, enter a label to display on the button, and specify an HTML file to upload to the system. Note that the system does not display images and other content referenced in this HTML page.

Click Save Changes. The changes take effect immediately, but users with active sessions might need to refresh their Web browsers.

Click Restore Factory Defaults to reset the sign-in page, the user home page, and admin console appearance.

Preventing Sign-In URL Tampering

This feature ensures that the hostname of the current URL matches the one that is associated with the internal id embedded in URL. This feature is not enabled by default and has to be enabled by using XML import.

To enable this feature, use the following HTML tags:

<system>
<configuration>
<security>
<signin-url-check>mitigate-url-tamper<signin-url-check>
<security>
<configuration>
<system>