General Access Management

Access Management Overview

The system enables you to secure your company resources using authentication realms, user roles, and resource policies. These three levels of accessibility allow you to control access from a very broad level (controlling who may sign into the device) down to a very granular level (controlling which authenticated users may access a particular URL or file). You can specify security requirements that users must meet to sign in to the device, to gain access to features, and even to access specific URLs, files, and other server resources. The system enforces the policies, rules and restrictions, and conditions that you configure to prevent users from connecting to or downloading unauthorized resources and content.

To permit endpoints that are not directly connected to a security device to access resources behind the firewall, you can configure a Policy Secure device to provision shared user sessions from any number of different Ivanti Connect Secure devices and Infranet Controllers.

The access management framework is available on all Ivanti Connect Secure products. The access management features, including realms, roles, resource policies, and servers, are the base of the platform on which all Ivanti Connect Secure products are built.

Policies, Rules & Restrictions, and Conditions Overview

The system enables you to secure your company resources using authentication realms, user roles, and resource policies. These three levels of accessibility allow you to control access from a very broad level (controlling who may sign into the device) down to a very granular level (controlling which authenticated users may access a particular URL or file).

Accessing Authentication Realms

Resource accessibility begins with the authentication realm. An authentication realm is a grouping of authentication resources, including:

•An authentication server - verifies that the user is who one claims to be. The system forwards credentials that a user submits on a sign-in page to an authentication server.

•An authentication policy - specifies realm security requirements that need to be met before the system submits a user's credentials to an authentication server for verification.

•A directory server - specifies an LDAP server that provides user and group information to the system that it uses to map users to one or more user roles.

•Role mapping rules - specifies the conditions a user must meet for the system to map the user to one or more user roles. These conditions are based on either user information returned by the realm's directory server or the user's username.

•You can associate one or more authentication realms with the sign-in page. When more than one realm exists for a sign-in page, a user must specify a realm before submitting one's credentials. When a user submits their credentials, the system checks the authentication policy defined for the chosen realm. The user must meet the security requirements you define for a realm's authentication policy or else the system does not forward the user's credentials to the authentication server.

•At the realm level, you can specify security requirements based on various elements such as the user's source IP address or the possession of a client-side certificate. If the user meets the requirements specified by the realm's authentication policy, the system forwards the user's credentials to the appropriate authentication server. If this server successfully authenticates the user, then the system evaluates the role mapping rules defined for the realm to determine which roles to assign to the user.

Accessing User Roles

A role is a defined entity that specifies session properties for users who are mapped to the role. These session properties include information such as session time-outs and enabled access features. A role's configuration serves as the second level of resource access control. Not only does a role specify the access mechanisms available to a user, but you can also specify restrictions with which users must comply before they are mapped to a role.

At the role level, you can specify security requirements based on elements such as the user's source IP address and possession of a client-side certificate. If the user meets the requirements specified either by a role mapping rule or a role's restrictions, then the system maps the user to the role. When a user makes a request to the backend resources available to the role, the system evaluates the corresponding access feature resource policies.

Note that you may specify security requirements for a role in two places in the role mapping rules of an authentication realm (using custom expressions) or by defining restrictions in the role definition. The system evaluates the requirements specified in both areas to make sure the user complies before it maps the user to a role.

Accessing Resource Policies

A resource policy is a set of resource names (such as URLs, hostnames, and IP address/netmask combinations) to which you grant or deny access or other resource-specific actions, such as rewriting and caching. A resource policy serves as the third level of resource access control. While a role may grant access to certain types of access features and resources (such as bookmarks and applications), whether or not a user can access a specific resource is controlled by resource policies. These policies may even specify conditions that, if met, either deny or grant user access to a server share or file. These conditions may be based on security requirements that you specify. The user must meet these security requirements or else the system does not process the user's request.

At the resource level, you can specify security requirements based elements such as the user's source IP address or possession of a client-side certificate. If the user meets the requirements specified by a resource policy's conditions, then the system either denies or grants access to the requested resource. You may enable Web access at the role level, for example, and a user mapped to the role may make a Web request. You may also configure a Web resource policy to deny requests to a particular URL or path when Host Checker finds an unacceptable file on the user's machine. In this scenario, the system checks to see if Host Checker is running and indicates that the user's machine complies with the required Host Checker policy. If the user's machine complies, meaning the unacceptable file is not found, then the system grants the user access to the requested Web resource.

Note that you can create separate resource policies, or you can create automatic resource policies (called autopolicies) during resource profile configuration (recommended).

Policies, Rules & Restrictions, and Conditions Evaluation

The following figure illustrates the access management security checks that the system performs when a user tries to access resources through the device. A detailed description of each step follows the diagram.

The following figure depicts the Security Checks Performed During a User Session:

1.The user enters the URL of the device end-user console (such as http://employees.yourcompany.com/marketing) in a web browser.

2.The system evaluates its sign-in policies (starting with the administrator URLs and continuing to user URLs) until it matches the hostname entered by the user.

3.The system evaluates pre-authentication restrictions and determines if the user's system passes host checks and other requirements. If the pre-authentication checks fail, the system denies the user access. If the checks pass, the system prompts the user to enter the username and password for the realms whose preauthentication checks succeeded. (If required by the realm, the system prompts the user to enter two sets of credentials.) If more than one realm exists, the user must enter a realm or choose one from a list.

4.The system evaluates the post-authentication restrictions and determines whether the user's password conforms to specified limits and requirements. If the postauthentication checks fail, the system denies the user access. If the checks pass, the system passes the user's credentials to the realm's authentication server.

5.The system forwards the user's username and password to the authentication server, which returns success or failure. (A RADIUS authentication server also returns attributes for the system to use in role mapping.) If the authentication server returns failure, the system denies the user access. If the server returns success, the system stores the user's credentials. If the realm has a separate LDAP authorization server, the system also queries the LDAP server for attribute and group information and saves the information returned by LDAP. If the realm includes a secondary authentication server, the system repeats this process with the secondary server.

6.The system evaluates the realm's role mapping rules and determines the roles for which the user is eligible. The system determines eligibility using information from the LDAP or RADIUS server or the user's username.

7.The system evaluates the restrictions of the eligible roles, enabling the user to access those roles whose restrictions the user's computer meets. Restrictions may include source IP, browser type, client-side certificate, and Host Checker.

8.The system creates a "session role," determining the user's session permissions. If you enable permissive merging, the system determines session permissions by merging all valid roles and granting the allowed resources from each valid role. If you disable merging, the system assigns the user to the first role to which he is mapped.

9.When the user requests a resource, the system checks whether the corresponding access feature is enabled for the session user role. If not, the system denies the user access. If the access feature is enabled, the evaluates resource policies.

10.The system evaluates resource profiles and policies related to the user's request, sequentially processing each until it finds the profile or policy whose resource list and designated roles match the user's request. The system denies user access to the resource if specified by the profile or policy. Otherwise, the system intermediates the user request if the profile or policy enables access.

11.The system intermediates the user request, forwarding the user's request and credentials (if necessary) to the appropriate server. Then, the system forwards the server's response to the user.

12.The user accesses the requested resource or application server. The user session ends when the user signs out or the session times out due to time limits or inactivity. The system may also force the user out if the session if you enable dynamic policy evaluation and the user fails a policy.

13.The user can perform realm, role mappings and create rules based on the Enhanced Key Usage (EKU) attribute in the certificates. This attribute can be parsed in certificates to create realm restrictions, role restrictions and role mapping based on rules that contained this attribute. Also, this is supported for custom expressions. The Enhanced Key Usage has 2 parts - The EKU Text and the EKU OID. The EKU text has information about the enhanced key usage - for example - "smart card logon", "wireless", "TLS Web Server Authentication", "E-mail Protection", "TLS Web Client Authentication" and so on. The OID is an identifier for this attribute and is a dotted number representation. The restrictions and role mappings can be done on either the text or the OID.

If you enable dynamic policy evaluation, the system performs additional checks beyond the ones mentioned here.

Dynamic Policy Evaluation

Dynamic policy evaluation allows you to automatically or manually refresh the assigned roles of users by evaluating a realm's authentication policy, role mappings, role restrictions, and resource policies. When the system performs a dynamic evaluation, it checks whether the client's status has changed. (For instance, the client's Host Checker status may have changed. Or, if the user is roaming, the computer's IP address may have changed.) If the status has changed, the system enables or denies the user access to the dependent realms, roles, or resource policies accordingly.

The system does not check for changes in user attributes from a RADIUS or LDAP when performing dynamic policy evaluation. Instead, the system re-evaluates rules and policies based on the original user attributes that it obtained when the user signed into the device.

Understanding Dynamic Policy Evaluation

Please note the following about Dynamic Policy Evaluation:

•Clients that use Network Communications Protocol (NCP) do not honor policy changes. This includes PSAM and WTS/CTS.

•PSAM establishes a new NCP tunnel when the protected application opens a new connection, so PSAM establishes new NCP connections frequently. This means PSAM gets the new policy frequently.

•WTS has a persistent NCP tunnel so it does not get policy changes until the user disconnects and then reconnects.

Because the system evaluates Web and Files resource policies whenever the user makes a request for a resource, dynamic policy evaluation is unnecessary for Web and Files.

If the system determines after a dynamic policy evaluation that a user no longer meets the security requirements of a policy or role, the system terminates the connection immediately with the user. The user may see the closing of a TCP or application connection, or the termination of a user session for VPN Tunneling, Secure Application Manager, or Terminal . The user must take the necessary steps to meet the security requirements of the policy or role, and then sign into the system again.

The system logs information about policy evaluation and changes in roles or access in the Event log.

Understanding Standard Policy Evaluation

If you do not use dynamic policy evaluation, the system evaluates policies and roles only when the following events occur:

•When the user first tries to access the system sign-in page, the system evaluates the Host Checker policies (if any) for a realm.

•Immediately after the user's initial authentication, the system evaluates the user's realm restrictions in the authentication policy, role mapping rules, and role restrictions.

•When the user makes a request for a resource, the system evaluates resource access policies to determine if the associated role is allowed to access the resource.

•When the Host Checker status of the user's machine changes, the system evaluates the Host Checker policies (if any) for the role.

If you do not use dynamic policy evaluation and you make changes to an authentication policy, role mapping rules, role restrictions, or resource policies, the system enforces those changes only when the events described above occur.

If you use dynamic policy evaluation, the system enforces changes when the events described above occur, and it also enforces changes at the times you specify.

Enabling Dynamic Policy Evaluation

You can use dynamic policy evaluation in the following ways:

•Evaluate all signed-in users in a realm - You can automatically or manually refresh the roles of all currently signed-in users of a realm by using the General tab of the Administrators > Admin Realms > Select Realm or Users > User Realms > Select Realm page. You can trigger the system to perform a dynamic policy evaluation at the realm level based on:

•An automatic timer - You can specify a refresh interval that determines how often the system performs an automatic policy evaluation of all currently signed-in realm users, such as every 30 minutes. When using the refresh interval, you can also fine tune the system performance by specifying whether or not you want to refresh roles and resource policies as well as the authentication policy, role mapping rules, and role restrictions.

•On-demand - At any time, you can manually evaluate the authentication policy, role mapping rules, role restrictions, and resource policies of all currently signed-in realm users. This technique is especially useful if you make changes to an authentication policy, role mapping rules, role restrictions, or resource policies and you want to immediately refresh the roles of a realm's users.

•Evaluate all signed-in users in all realms - At any time, you can manually refresh the roles of all currently signed-in users in all realms by using settings in the System > Status >Active Users page.

•Evaluate individual users - You can automatically refresh the roles of individual users by enabling dynamic policy evaluation for Host Checker on the Authentication > Endpoint Security > Host Checker page. Host Checker can trigger the system to evaluate resource policies whenever a user's Host Checker status changes. (If you do not enable dynamic policy evaluation for Host Checker, the system does not evaluate resource policies, but it does evaluate the authentication policy, role mapping rules, and role restrictions whenever a user's Host Checker status changes.)

Specifying Source IP Access Restrictions

This topic describes options to enforce source IP restrictions for access to the corporate network or intranet resources.

About Source IP Restrictions

You can enforce access rules based on the source IP address of the request. You can configure rules related to sign-in, role-mapping, and resource access.

At the realm level, you can add source IP rules to the realms associated with sign-in pages. The user must sign in from a host with an IP address that is allowed by the source IP requirements for the authentication realm. If the source IP policy does not allow the host to access the realm, the system does not forward the user's credentials to the authentication server, and the user is denied access. You can set up multiple rules. For example, you can deny access to all users on a wireless network (10.64.4.100), and allow access to all other network users (0.0.0.0).

At the user role level, you can add source IP rules to the criteria that determine user role membership. If the source IP rule disqualifies a user from a role, subsequent role mapping rules are consulted.

In resource policies, you can add allow/deny rules based on source IP.

Specifying Source IP Restrictions at the Realm Level

To specify source IP restrictions:

1.Navigate to the administrator or user realm you want to configure:

•Administrators > Admin Realms > Realm

•Users > User Realms > Realm

2.Select Authentication Policy > Source IP to display the Source IP policy configuration page.

3.Choose one of the following options:

•Allow users to sign in from any IP address - Essentially, this option turns off source IP restrictions.

•Allow or deny users from the following IP addresses - Specifies source IP restrictions. If you select this option, use the policy table controls to create source IP rules.

4.Add a rule to the table:

•Use the text boxes to specify source IP address match criteria:

•For IPv4 clients, enter IPv4 address and netmask pairs.

•For IPv6 clients, enter IPv6 address and prefix length pairs.

•Use the Allow and Deny option buttons to specify the action when a rule matches.

•Click Add to add the rule to the table.

•Use the selection box and arrow buttons to order the list. Move the highest priority restrictions to the top of the list. For example, to deny access to all users on a wireless network (10.64.4.100) and allow access to all other network users (0.0.0.0), move the wireless network address (10.64.4.100) to the top of the list and move the (0.0.0.0) network below the wireless network.

5.For administrator realms, select the ports where the administrator can log in (internal, external, and management). On virtual appliances that use traffic segregation, administrators can log in on the management port on the Default Network or Administrative Network (see Using the Traffic Segregation Feature. If necessary, click External Port or Management Port to enable the port.

6.Save the configuration.

Specifying Source IP Restrictions at the Role Level

To specify source IP restrictions:

1.Navigate to the administrator or user role you want to configure:

•Administrators > Admin Roles > Role

•Users > User Roles > Role

2.Select General > Restrictions > Source IP to display the Source IP policy configuration page.

3.Choose one of the following options:

•Allow users to sign in from any IP address - Essentially, this option turns off source IP restrictions.

•Allow or deny users from the following IP addresses - Specifies source IP restrictions. If you select this option, use the policy table controls to create source IP rules.

4.Add a rule to the table:

5.Use the text boxes to specify source IP address match criteria:

•For IPv4 clients, enter IPv4 address and netmask pairs.

•For IPv6 clients, enter IPv6 address and prefix length pairs.

6.Use the Allow and Deny option buttons to specify the action when a rule matches.

7.Click Add to add the rule to the table.

8.Use the selection box and arrow buttons to order the list. Move the highest priority restrictions to the top of the list. For example, to deny access to all users on a wireless network (10.64.4.100) and allow access to all other network users (0.0.0.0), move the wireless network address (10.64.4.100) to the top of the list and move the (0.0.0.0) network below the wireless network.

9.Save the configuration.

Specifying Source IP Restrictions in Resource Policies

A third way to use source IP restrictions is by creating custom rules in resource policies. The action for custom rules is either allow or deny. The match criteria include resources and conditions. One of the conditions you can set is source IP, so you can enforce source IP restrictions through resource policies. For example:

1.Navigate to Users > Resource Policies.

2.Select a policy. Click Web Access Policies, for example, to display its policies list.

3.Click the Initial Policy for Local Resources policy to edit it.

4.Click the Detailed Rules tab.

5.Under Conditions, expand the Prebuilt Conditions list, expand the SourceIPStr selections, select one of the example expressions, such as SourceIPStr = "192.168.10.0/24" or SourceIPStr = "2001:DB8::15", and click Insert Expression to add the string to the Conditions box.

6.Modify the IP address. In other words, replace 192.168.10.0/24 with an IPv4 address / netmask pair; replace 2001:DB8::15 with an IPv6 address.

7.Specify the other match condition (resource) and specify the action (allow or deny).

8.Save the configuration.

Specifying Browser Access Restrictions

Use a browser restriction to control from which Web browsers users can access a system sign-in page or be mapped to a role. If a user tries to sign in to the device using an unsupported browser, the sign-in attempt fails. This feature also enables you to ensure that users sign in to the device from browsers that are compatible with corporate applications or are approved by corporate security policies.

You can restrict system and resource access by browser-type:

•When administrators or users try to sign in to Ivanti Connect Secure - The user must sign in from a browser whose user-agent string meets the specified user-agent string pattern requirements for the selected authentication realm. If the realm "allows" the browser's user-agent string, then the system submits the user's credentials to the authentication server. If the realm "denies" the browser's user-agent string, then the system does not submit the user's credentials to the authentication server.

•When administrators or users are mapped to a role - The authenticated user must be signed in from a browser whose user-agent string meets the specified user-agent string pattern requirements for each role to which the system may map the user. If the user-agent string does not meet the "allowed" or "denied" requirements for a role, then the system does not map the user to that role.

•When users request a resource - The authenticated, authorized user must make a resource request from a browser whose user-agent string meets the specified "allowed" or "denied" requirements for the resource policy corresponding to the user's request. If the user-agent string does not meet the "allowed" or "denied" requirements for a resource, then the system does not allow the user to access the resource.

The browser restrictions feature is not intended as a strict access control since browser user-agent strings can be changed by a technical user. It serves as an advisory access control for normal usage scenarios.

To specify browser restrictions:

1.Select the level at which you want to implement browser restrictions:

•Realm level - Navigate to:

•Administrators > Admin Realms > Select Realm > Authentication Policy > Browser

•Users > User Realms > Select Realm > Authentication Policy > Browser

•Role level - Navigate to:

•Administrators > Admin Realms > Select Realm > Role Mapping > Select|Create Rule based on Custom Expressions

•Administrators > Admin Roles > Select Role > General > Restrictions > Browser

•Users > User Realms > Select Realm > Role Mapping > Select|Create Rule based on Custom Expression

•Users > User Roles > Select Role > General > Restrictions > Browser

2.Choose one of the following options:

•Allow all users matching any user-agent string sent by the browser - Allows users to access the system or resources using any of the supported Web browsers.

•Only allow users matching the following User - agent policy-Allows you to define browser access control rules. To create a rule:

•For the User-agent string pattern, enter a string in the format

*browser_string*

where start (*) is an optional character used to match any character and browser_string is a case-sensitive pattern that must match a substring in the user-agent header sent by the browser. Note that you cannot include escape characters (\) in browser restrictions.
For example, the following is a browser sent user-agent header:
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.22 (KHTML, like Gecko)
where:

•Mozilla/5.0 indicates compatibility with the Mozilla rendering engine.

•(Windows NT 6.1; WOW64) are the details of the system in which the browser is running.

•AppleWebKit/537.22 is the platform the browser users.

•(KHTML, like Gecko) is the browser platform details.

Using the above example, enter *Windows NT* as a string pattern for specifying the Windows NT system. For more details on user-agent strings, see your specific browser's documentation.

•Select either:

•Allow to allow users to use a browser that has a user-agent header containing the <browser_string> substring.

•Deny to prevent users from using a browser that has a user-agent header containing the <browser_string> substring.

•Click Add.

3.Click Save Changes to save your settings.
Rules are applied in order, so the first matched rule applies.
Literal characters in rules are case sensitive, and spaces are allowed as literal characters.
For example, the string *Netscape* matches any user-agent string that contains the substring Netscape.
The following rule set grants resource access only when users are signed in using Internet Explorer 5.5x or Internet Explorer 6.x. This example takes into account some major non-IE browsers that send the 'MSIE' substring in their user-agent headers:

*Opera*Deny

*AOL*Deny

*MSIE 5.5*Allow

*MSIE 6.*Allow

Deny

Specifying Certificate Access Restrictions

When you install a client-side certificate on the device through the System > Configuration > Certificates > Trusted Client CAs page of the admin console, you can restrict system and resource access by requiring client-side certificates:

•When administrators or users try to sign in to Ivanti Connect Secure - The user must sign in from a machine that possesses the specified client-side certificate (from the proper certificate authority (CA) and possessing any optionally specified field/value pair requirements). If the user's machine does not possess the certificate information required by the realm, the user can access the sign-in page, but once the system determines that the user's browser does not possess the certificate, the system does not submit the user's credentials to the authentication server and the user cannot access features on the device.

To implement certificate restrictions at the realm level, navigate to:

•Administrators > Admin Realms > SelectRealm > Authentication Policy > Certificate

•Users > User Realms > SelectRealm > Authentication Policy > Certificate

•When administrators or users are mapped to a role - The authenticated user must be signed in from a machine that meets the specified client-side certificate requirements (proper certificate authority (CA) and optionally specified field/value pair requirements) for each role to which the system may map the user. If the user's machine does not possess the certificate information required by a role, then the system does not map the user to that role.

•Administrators > Admin Roles > SelectRole > General > Restrictions > Certificate

•Users > User Realms > Select Realm Role Mapping > Select|CreateRule > CustomExpression

•Users > User Roles > SelectRole > General > Restrictions > Certificate

•When users request a resource - The authenticated, authorized user must make a resource request from a machine that meets the specified client-side certificate requirements (proper certificate authority (CA) and optionally specified field/value pair requirements) for the resource policy corresponding to the user's request. If the user's machine does not possess the certificate information required by a resource, then the system does not allow the user to access the resource.

•Users > Resource Policies> SelectResource > SelectPolicy > Detailed RulesSelect|CreateRule > ConditionField

The user can perform realm, role mappings and create rules based on the Enhanced Key Usage (EKU) attribute in the certificates. This attribute can be parsed in certificates to create realm restrictions, role restrictions and role mapping based on rules that contained this attribute. Also, this is supported for custom expressions. The Enhanced Key Usage has two parts - the EKU Text and the EKU OID. The EKU text has information about the enhanced key usage - for example - "smart card logon", "wireless", "TLS Web Server Authentication", "E-mail Protection", "TLS Web Client Authentication" and so on. The OID is an identifier for this attribute and is a dotted number representation. The restrictions and role mappings can be done on either the text or the OID.

Specifying Password Access Restrictions

You can restrict system and resource access by password-length when administrators or users try to sign in to the device. The user must enter a password whose length meets the minimum password-length requirement specified for the realm. Note that local user and administrator records are stored in the system authentication server. This server requires that passwords are a minimum length of 6 characters by default, regardless of the value you specify for the realm's authentication policy.

To specify password restrictions:

1.Select an administrator or user realm for which you want to implement password restrictions.

Navigate to:

•Administrators > Admin Realms > Select Realm > Authentication Policy > Password

•Users > User Realms > Select Realm > Authentication Policy > Password

2.Choose one of the following options:

•Allow all users (passwords of any length) - Does not apply password length restrictions to users signing in to the device.

•Only allow users that have passwords of a minimum length - Requires the user to enter a password with a minimum length of the number specified.

This option is not applicable for IKEv2 users and therefore is not enforced for IKEv2 users.

3.Select Enable Password Management if you want to enable password management. You must also configure password management on the authentication server configuration page (local authentication server) or through an LDAP server.

4.If you have enabled a secondary authentication server, specify password length restrictions using the restrictions above as a guideline.

5.Click Save Changes to save your settings.

By default, the system requires that user passwords entered on the sign-in page be a minimum of four characters. The authentication server used to validate a user's credentials may require a different minimum length. The local authentication database, for example, requires user passwords to be a minimum length of six characters.

Specifying Session Limits

In addition to the access management options you may specify a limit for concurrent users. A user who enters a URL to one of this realm's sign-in pages must meet any access management and concurrent user requirements specified for the authentication policy before the system presents the sign-in page to the user.

Setting the minimum or maximum setting limit amount allows you to configure realms that are more likely to be available when the device is nearing the amount of licensed users.

Valid numbers for the minimum amount of sessions are between 0 and the license limit. A default of 0 means there is no limits. All of the realms minimum limits can add up to the license limit but cannot exceed it. You cannot modify an existing realm's minimum limit or add a new realm's minimum limit that exceeds the license limit. The maximum limit can be equal to or greater than the minimum limit for a particular realm. Value 0 for maximum limit means no user can log in to the realm.

You can also limit the number of concurrent users per session; a user can have multiple sessions. For example, if a user logs in from two machines in the same realm, an additional session is created. Each session counts towards the user license.

Users who enter through a realm with this feature enabled must have no more than the specified number of sessions open. If the user attempts to open a new session that exceeds the limit, a message appears that denies access or allows the user to continue or cancel.

When considering concurrent users per session, make note of the following:

•All session-related SSO attributes are saved in their respective session in the cache. These attributes are not shared with other sessions.

•All form-related SSO attributes are saved in their respective session in the cache. These attributes are not shared with other sessions.

•All Form-SSO related attributes are saved in their respective session in the cache. The Form SSO state will not be shared with other sessions. The admin configured Form SSO values will be shared across all sessions.

•End-user's home page changes are reflected across all sessions. Any changes to the following will appear in the other concurrent sessions:

•Bookmarks

•Panel sorting (Preferences > User Home)

•E-mail information and Daylight Saving Time (Preferences > General)

•Autostart Client Application Session (Preferences > Applications)

•Cached E-mail Info settings (Preferences > Advanced)

•Delete Cookies (Preferences > Advanced) now has options to let you remove cookies from the current session only or to remove cookies from all sessions.

•Delete Password (Preferences > Advanced) now has options to let you remove passwords from the current session only or to remove passwords stored by all sessions.

•Host Checker information is saved in each session. They are not shared across concurrent sessions

•Log messages will contain session identifiers (concatenated at the end of the log message) to differentiate which session the message refers to.

•Each user session maintains its own VPN Tunneling information. This information is not shared between concurrent sessions. However, administrator network connect sessions are shared between concurrent sessions.

•If you log in to the device as administrator, the first session is edit mode. If you log in as an administrator in a concurrent session, that administrator is logged in as read-only mode.

•VPN Tunneling bandwidth allocation is enforced on a per-session basis. For example, if a user is allocated a 1M bandwidth then each user session has a 1M bandwidth. The total bandwidth for this user is the number of sessions of this user times 1M.

•Users can launch terminal services, JSAM or PSAM from any session. Session information is saved per each session; they are not shared across concurrent sessions. Multiple instances of terminal services, JSAM and PSAM cannot be started on the same client.

If you enable the multiple sessions per user feature, IKEv2 clients and VPN Tunneling clients may not be assigned the same IP address. For example, an IKEv2/VPN Tunneling client may be assigned a different VPN Tunneling VIP address each time they connect to the device when the system is obtaining the DHCP addresses from a DHCP server.

Use limits restrictions to set minimum and maximum concurrent users on the realm.

To specify the number of concurrent users limit restrictions:

1.Select an administrator or user realm for which you want to implement limits restrictions.

•Administrators > Admin Realms >SelectRealm> Authentication Policy > Limits

•Users > User Realms > SelectRealm > Authentication Policy > Limits

2.To limit the number of concurrent users on the realm, select Limit the number of concurrent users and then specify limit values for these options:

•Guaranteed minimum - You can specify any number of users between zero (0) and the maximum number of concurrent users defined for the realm, or you can set the number up to the maximum allowed by your license if there is no realm maximum.

•Maximum (optional) - You can specify any number of concurrent users from the minimum number you specified up to the maximum number of licensed users. If you enter a zero (0) into the Maximum field, no users are allowed to log into the realm.

3.Click Save Changes.

To specify the number of concurrent users per session limit restriction:

1.Select Authentication > Signing In > Sign-in Policies.

2.Select the Restrict access to administrators only to immediately terminate all user sessions from all nodes across the cluster. Once enabled, only administrator URLs are accessible across the cluster. Note that Administrators can attempt to sign in even if all rules on this page are disabled.

3.Select the Enable multiple user sessions check box to allow users to have multiple concurrent sessions, and specify whether the user can log in when the maximum number of sessions is reached:

•Deny any more session from the user-Displays a message saying the login is denied because it would exceed the maximum number of concurrent sessions.

•Allow the user to login-Allows the user to log in. If the Display open user session[s] warning notification option is enabled, the user can select which session to close; otherwise the session that has been idle the longest is closed automatically.

4.Select the Display open user session[s] warning notification check box to allow users who have met the maximum session count to close one of their existing sessions before continuing with the current log in. If this option is disabled, the system terminates the session that has been idle the longest. This option applies only if Enable multiple user sessions is enabled along with Allow the user to log in. Specify when the user is warned about concurrent sessions:

•Select Always to notify users each time they log in when they already have another active session

•Select If the maximum session has been exceeded to display the warning message only when the user's maximum session count has been met.

5.To specify the maximum number of concurrent sessions:

•Select Users > User Realms > RealmName > Authentication Policy > Limits.

•Specify the number of sessions permitted for users in the Maximum number of sessions per user text box.

•Click Save Changes.

If you do not select the Enable multiple user sessions check box, only one session per user is allowed regardless of the value you specify in the Maximum number of sessions per user text box.

Trusted Server List

The system uses two mechanisms to install and launch client software from a web browser:

•ActiveX controls (available only for Windows/IE)

•Java applets

With both mechanisms, the user is prompted to trust ActiveX controls and Java applets they have not run before. Inherent problems with these types of mechanisms are:

•When the user trusts an ActiveX control that control is trusted forever.

•When trusting a Java applet, users are trusting all code that is signed by the exact same code signing certificate.

To address the above, administrators can create a text file (called a whitelist) that contains a list of trusted devices, fully qualified domain names or IP addresses, one per line. Administrators can configure two types of whitelists:

•Admin whitelist - The admin whitelist file can be modified only by the endpoint administrator. The administrator must use SMS or other mechanism to copy the admin whitelist file to the end-user's system. Admin whitelist files are located in:

%ProgramFiles%\Pulse Secure\Whitelist.txt (Windows)

/usr/local/pulsesecure/whitelist.txt (Macintosh and Linux)

•User whitelist - Users can themselves make the decision to trust a device. When the user makes a decision to trust device, the device gets added to the user whitelist. User whitelist files are located in:

%AppData%\Pulse Secure\Whitelist.txt (Windows)

/~/Library/Application Support/Pulse Secure/whitelist.txt (Macintosh)

/~/.pulse_secure/whitelist.txt (Linux)

The trusted server list feature is for applications launched from a browser window. It does not apply to applications launched from the command-line or other means.

Administrator and User Configuration

The following is a snippet of a whitelist file:

qa.pulsesecure.netdev1.pulsesecure.net66.129.224.48

Whitelist files are not deleted when the software is removed.

There are two modes of enforcement:

•Allow Admin List Only - When software launches from the device that is not in the administrator whitelist, the launch fails and the user receives the error message "You are not allowed to launch software downloaded from <server>. Contact your system administrator for assistance." If the device is in the administrator whitelist, the launch proceeds as requested.

•Prompt - When software launches from the device that is not in the administrator whitelist or the user whitelist, the user is prompted if they want to launch the software with the message "Do you want to download, install and/or execute software from the following server". If the user declines, the launch fails. If the user accepts, the launch proceeds. The user also has the option to automatically add the device to the user whitelist file by selecting one of the following options from the message window:

•Always - Add the server to the user whitelist file and download, install or launch the software

•Yes - Download, install or launch the software but don't add the server to the user whitelist file

•No - Do not download, install or launch software and don't add the server to the user whitelist file

If the first line of the whitelist file contains "AllowAdminListOnly" (case insensitive) then Allow Admin List Only enforcement mode is used. Otherwise, prompt mode enforcement is used.

A snippet of a whitelist file using Allow Admin List Only enforcement is shown here:

AllowAdminListOnly qa.pulsesecure.net dev1.pulsesecure.net 66.129.224.48

Prompt enforcement is the default mode when you upgrade your software to the latest revision.

To add clusters to the whitelist file:

•For Active/Passive clusters, enter the VIP in the whitelist.

•For Active/Active clusters, enter the load balancer hostname in the whitelist.

White List Flow Chart

The following steps outline the process for determining whether to launch the software

1.f the URL of the page initiating the launch does not begin with https, abort the launch and notify the user.

2.ElsIe if the admin whitelist exists,

•If the origin site is listed in the whitelist, proceed with the launch.

•If the origin site is not in the whitelist and the whitelist starts with "AllowAdminListOnly", abort the launch and notify the user.

3.Else if the user whitelist exists,

•If the origin site is in the user whitelist, proceed with the launch.

4.Prompt the user if they trust the origin site.

5.If the user agrees to trust the origin:

•If they select Always, then add the server to user whitelist file.

•Proceed with the launch.

6.Abort the launch.