Sign-In Policies

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/ http //ww8 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> https //yourcompany net/partners/dana/term/winlaunchterm cgi?host= 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 a dministrators > 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 enabling and disabling sign in policies 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 specifying the order in which sign in policies are evaluated 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>