Permissive Merge Guidelines
A permissive merge is a merge of two or more roles that combines enabled features and settings according to these guidelines:
• Any enabled access feature in one role takes precedence over the same feature set to disabled in another role. For example, if a user maps to two roles, one of which disables the Host Enforcer while the other role enables the Host Enforcer, the system enables the Host Enforcer for that session.
• In the case of user interface options, the system applies the settings that correspond to the user’s first role.
• In the case of maximum session lengths, the system applies the greatest value from all of the roles to the user’s session.
• If more than one role enables the Roaming Session feature, then the system merges the netmasks to formulate a greater netmask for the session.
Configuration of User Roles
To create a user role:
1. Select Users > User Roles.
2. Click New Role and then enter a name and, optionally, a description. This name is displayed in the list of Roles on the Roles page.
To create individual user accounts, you must add the users through the appropriate authentication server (not through the role). For instructions on how to create users on third-party servers, see the documentation that comes with that server product.
To display the role ID, place the mouse cursor over the role name on the Roles page. The role ID is displayed at the end of the link text that is displayed on the status bar at the bottom of the Web browser window. To show information on the ScreenOS Enforcer about the role ID of a specific authentication table entry, use this CLI command:
get auth table infranet auth-id <x>
After you create a role, you can click the role name to begin configuring it using the instructions in the following sections.
Related Documentation
• Specifying the Client that Endpoints Use for Access
• Understanding Realm and Role Restrictions on page 3
• Understanding the Evaluation Process for Policies, Rules, Restrictions, and Conditions on page 6
• Using the Dynamic Policy Evaluation Feature on page 11
• Configuring General Role Options on page 23
• Specifying Role Access Options on page 25
CHAPTER 3
Realms
• Understanding Authentication Realms on page 19
• Understanding Role Mapping Rules on page 20
Understanding Authentication Realms
You create authentication realms to permit clients to request authentication from the Access Control Service. The Access Control Service supports different types of agent access: UAC agents, (OAC, Pulse, the Java agent, or endpoints using agentless access), third-party 802.1X supplicants, and 802.1X phones.
Depending on the client and the authentication server you are using, different
authentication protocols can be paired with different realms. You pair realms with the appropriate authentication protocol sets when you configure sign-in policies.
An authentication realm specifies the conditions that users must meet to sign in. A realm consists of a grouping of authentication resources, including:
• An authentication server—Verifies that the identity of the user. The system forwards credentials that a user submits to an authentication server.
• A directory server—An LDAP server that provides user and group information to the Access Control Service that is used to map users to one or more user roles.
• An authentication policy—Specifies realm security requirements that must be met before the system submits a user's credentials to an authentication server for verification.
• Role-mapping rules—Conditions a user must meet in order to be mapped to one or more user roles. These conditions are based either on user information returned by the realm's directory server or the username.
• Session migration—You configure authentication groups for realms for which you want to permit session migration. With session migration configured, users authenticate to Access Control Service servers and Secure Access Service servers within the same federated network without requiring reauthentication. Session migration is supported only with Pulse.
Related Documentation
Before Configuring a Realm on page 43
•
• Creating an Authentication Realm on page 44
• Defining Authentication Access Policies on page 52
• About Sign-In Policies on page 55
• Understanding Session Migration on page 71
Understanding Role Mapping Rules
Role-mapping rules are conditions a user must meet in order to be mapped to user roles.
These conditions are based either on user information returned by the realm's directory server or the user's username. You must specify role-mapping directives in the following format: If the specified condition is|is not true, then map the user to the selected roles.
To create a role-mapping rule use Role Mapping tab of an authentication realm. When you click New Rule on this tab, the Role Mapping Rule page is displayed with an inline editor for defining the rule. This editor leads you through the three steps of creating a rule:
• Specify the type of condition on which to base the rule. Options include:
• Username
• Certificate or certificate attribute
• Custom expressions
• Specify the condition to evaluate. Options include:
• One or more usernames, certificate attributes, or expressions depending on the type of condition you select. Outer proxy cannot be used for the realm if a role-mapping rule based on usernames is created, as the system cannot see the username, and a session cannot be created.
• To what the value(s) must equate, which might include a list of usernames, client-side certificate values (static or compared to LDAP attributes), or predefined custom expressions. If you are using proxy RADIUS for outer authentication, you cannot create a role-mapping rule based on username.
• Specify the roles to assign to the authenticated user.
The system compiles a list of eligible roles to which a user can be mapped. These roles are specified by the role-mapping rules to which the user conforms. Next, the system evaluates the definition for each role to determine whether the user complies with any role restrictions. The system uses this information to compile a list of valid roles, for which the user meets any additional requirements. Finally, the system either performs a permissive merge of the valid roles or presents a list of valid roles to the user, depending on the configuration specified on the realm’s Role Mapping tab.
Related Documentation
• Understanding User Roles on page 15
• Specifying Role Mapping Rules for an Authentication Realm on page 46
PART 2
Configuration
• Role Options on page 23
• Realm/Role Restrictions on page 35
• Realms on page 43
• Sign-In Policies on page 55
• Session Migration on page 71
CHAPTER 4
Role Options
• Configuring General Role Options on page 23
• Defining Default Options for User Roles on page 24
• Specifying Role Access Options on page 25
• Specifying Session Limits on page 27
• Specifying Session Options on page 29
• Specifying UI Options for Agentless Access on page 31
• Customizing User Realm UI Views on page 33
Configuring General Role Options
Use the Overview tab to edit a role name and description and to toggle session and user interface options on and off.
To manage general role settings and options:
1. In the admin console, select Users > User Roles > Role Name > General > Overview.
2. (Optional) Revise the name and description, and then click Save Changes.
3. Under Options, check the role-specific options to enable for the role. If you do not select role-specific options, the system uses the default settings. Role-specific options include:
• Session Options—To apply the role settings in the General > Session Options page to the role. This option is selected by default.
• UI Options—To apply the role settings in the General > UI Options page to agentless access roles. This option is selected by default.
• Odyssey Settings for IC Access—To specify OAC connection and authentication options. By Default, this option is not selected. Do not select this option if you want users to access protected resources with Pulse, the Java agent, or with agentless access.
• Odyssey Settings for Preconfigured Installer—To upload a preconfigured installer for OAC. By Default, this option is not selected. Do not select this option if you want
users to access protected resources with Pulse, the Java agent, or with agentless access.
• Enable Guest User Account Management Rights—To provision users who access this role administrative rights to create and modify guest user accounts.
4. Click Save Changes.
Related Documentation
Specifying the Client that Endpoints Use for Access
•
• Using Role Restrictions on page 37
• Specifying Session Options on page 29
• Specifying UI Options for Agentless Access on page 31
• Defining Default Options for User Roles on page 24
• Specifying Role Access Options on page 25
Defining Default Options for User Roles
You can change or keep the default options for a user role by selecting Users > User Roles
> New User Role. The default options include:
• Session Options—Sets timeouts and user permissions that apply to each session established through the role.
• UI Options—Sets the appearance of agentless login pages.
• OAC Settings
• IC Access
• Preconfigured Installer
• Guest User Account Management—Provides limited permissions to allow users assigned to this role to create guest accounts.
To define these default options for user roles:
1. Select Users > User Roles > Role Name, or create a new role.
2. Modify settings in the Session Options, UI Options, and Odyssey Settings tabs.
3. If you want to use OAC for this role, select Odyssey Settings for IC Access or if you want to use the preconfigured installer option, select the check box for Odyssey Settings for Preconfigured Installer.
If you want the role to access the network with Pulse as the client, do not select the Odyssey Access Client check boxes.
4. Click Save Changes. These become the new defaults for this role.
5. To provision Pulse for this role, save the role, and then select Select Role > Users >
User Roles > Agent.
7. Select the Install Pulse option button. (Host Enforcer is not supported for Pulse).
8. Click Save Changes.
Related Documentation
Specifying the Client that Endpoints Use for Access
•
• Configuring General Role Options on page 23
• Using the Preconfigured Installer for OAC on Windows Endpoints
• Configuring the Pulse Client for a Role
• Using Role Restrictions on page 37
• Specifying UI Options for Agentless Access on page 31
Specifying Role Access Options
You can specify the following role options for user access through a role:
• Install OAC—For Windows endpoints, you can configure a role that automatically downloads OAC.
• Enable agentless access—For Windows, Macintosh, Linux, and Solaris platforms, you can allow users to access protected resources without installing and running OAC on the endpoint. This type of access is referred to as agentless access.
• Install Java agent—For Linux platforms, you can install a lightweight Java agent to provide status and session control.
• Install Pulse—For Windows platforms, you can configure a role that automatically downloads the Pulse client.
• Enable Host Enforcer—For OAC, you can enable Host Enforcer for a role and specify endpoint traffic in a Host Enforcer policy. You can also control endpoint access to resources and protect endpoints from attacks from other computers.
• Session scripts—You can specify scripts to run on Windows endpoints for users assigned to a role after OAC or Pulse connects or disconnects. For example, you can specify a script that maps network drives on an endpoint to shares on protected resources as a session start script, and you can specify a another script that disconnects the mapped network drives as session end script.
To configure these access options for a role:
1. Select Users > User Roles > Role Name > Agent.
2. To allow OAC to download automatically on Windows endpoints, select Install Agent for this role, and then select the Install Odyssey option button.
3. To allow Pulse to download automatically on Windows endpoints, select Install Agent for this role, and then select the Install Pulse option button.
4. To allow users to download and install the lightweight Java agent for Macintosh or Linux platforms, select Install Java Agent for this role.
Chapter 4: Role Options
5. (Windows only) For OAC configurations, select Enable Host Enforcer to enable Host Enforcer on the endpoint and to send Host Enforcer policies to OAC for this role. Host Enforcer is not supported on Pulse.
NOTE:
• By default, after you enable the Host Enforcer option on a role, OAC denies all traffic on the endpoint except for the following allowed types:
traffic to and from the Access Control Service and Infranet Enforcer, WINS, DNS, IPsec, DHCP, ESP, IKE, outgoing TCP traffic, and some ICMP messages (for example, PING from the endpoint to other devices is allowed). Therefore, it’s important that you configure Host Enforcer policies to specify the additional types of traffic you want to allow on each endpoint. For example, you must configure Host Enforcer policies to allow any incoming TCP traffic.
• To avoid blocking all traffic on endpoints and preventing users from accessing all network and Internet resources, we recommend that you configure Host Enforcer policies to allow the specific types of traffic on endpoints before you enable the Host Enforcer option on a role.
6. To use session scripts, under Session Scripts specify the location of the session start and end scripts you want to run on Windows endpoints after OAC connects to or disconnects. You can specify a fully qualified path. Scripts can be accessed locally or remotely by means of file share or another permanently available local network resource. You can also use environment variables, such as %USERNAME% in the script path name. For example:
\\abc\users\%USERNAME%\myscript.bat
When OAC connects to the Access Control Service, the Access Control Service system copies the session start and end scripts to a temporary directory on the endpoint (defined by the %TEMP% environment variable). When OAC disconnects, the system deletes the copied scripts from the temporary directory.
NOTE:
• Windows supports only scripts with the .bat, cmd, or .exe extension. To run a .vbs script, the user must have a batch file to call the .vbs script.
• Any files referenced in a script are not copied to the endpoint; only the script itself is copied. Any references to files in scripts must take the temporary directory on the endpoint location into account.
• After connecting to the Access Control Service, OAC copies the session end script from a network drive to a temporary directory on the endpoint so that the end script can run if the network connection fails.
• The session scripts run in the user’s context.
• If a user qualifies for multiple roles, all scripts for all roles are run. You cannot configure the order in which to run the scripts when multiple roles are assigned to a user.
7. To configure the role to permit users to use agentless access, select the Agentless tab, then select Enable Agentless Access for this role. You can also select this to allow access to endpoints in addition to using OAC on Windows machines. If you don’t select the agentless option, the system allows access to protected resources by means of OAC only.
Related Documentation
Specifying the Client that Endpoints Use for Access
•
• Configuring General Role Options on page 23
• Using Role Restrictions on page 37
• Using Host Enforcer Policies
• Understanding OAC Configuration Settings for Windows Endpoints
• Configuring the Pulse Client for a Role
• Configuring Agentless Access to Protected Resources
• Using the Java Agent
Specifying Session Limits
A session is a single authenticated connection between an endpoint and the Access Control Service. You can limit the number of sessions for a given realm.
A default of 0 means there are no limits. The maximum limit can be equal to or greater than the minimum limit for a particular realm. A maximum limit of 0 means that no users 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.
Chapter 4: Role Options
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, the client, or a browser dialog on agentless connections, displays a message giving the user the option to continue or cancel. The current user sessions are displayed in a table, and the user can delete individual sessions to reach compliance. If the user’s session limit comes into compliance, the user is given access. If the user cancels, the system does not create the session.
If a user who is connected with agentless access attempts to log in from the same source IP, the dialog displays the IP address with an asterisk (*) and gives the agentless user the option to delete the existing session.
If a user with agentless or Java agent access attempts to log in from a source IP from which a session is established, the system automatically replaces the old session with a new session.
Users can access different realms. If an endpoint accesses the system through multiple realms, multiple sessions are possible. These sessions do not count against individual realm session limits. The system verifies the session limit check after authentication, but before a session is created.
If administrators reduce the session limits, existing sessions are not effected unless the Dynamic policy evaluation option is enabled. With Dynamic policy evaluation enforced, the oldest session(s) of a non-compliant user are silently dropped.
These limits will not be enforced if the realm is configured to proxy outer authentication.
To limit the number of simultaneous sessions:
1. Select Users > User Realms > Select Realm > Authentication Policy > Limits.
2. To limit the number of concurrent sessions, select the check box for Limit number of concurrent sessions, and type either a Guaranteed minimum and/or Guaranteed maximum.
3. To limit the number of sessions for users, select Limit the number of concurrent sessions for users.
4. Specify the number of sessions permitted for users in the Session Limit text box. By default, the number is 1 if the realm maximum is greater than 0; otherwise, the default is 0. The maximum number must be no greater than the maximum number of concurrent users for the realm.
5. Click Save Changes.
Related Documentation
Understanding the Evaluation Process for Policies, Rules, Restrictions, and Conditions on page 6
•
• Using the Dynamic Policy Evaluation Feature on page 11
Specifying Session Options
Use the Session tab to specify the maximum session length, roaming capabilities, session persistence, and to enable session extension without reauthentication. Check the Session Options check box on the Overview tab to enable these settings for the role.
By default, this option is selected.
To specify general session options:
1. In the admin console, select Users > User Roles > RoleName > General > Session Options.
2. Under Session lifetime:
a. For Max. Session Length, specify the number of minutes an active non administrative user session can remain open before ending. The minimum is 6 minutes. The maximum is 725 minutes. During a user session, prior to the expiration of the maximum session length, the system prompts the user to reenter authentication
a. For Max. Session Length, specify the number of minutes an active non administrative user session can remain open before ending. The minimum is 6 minutes. The maximum is 725 minutes. During a user session, prior to the expiration of the maximum session length, the system prompts the user to reenter authentication