Junos Pulse Access Control Service

Transcription

1 Junos Pulse Access Control Service User Access Management Framework Feature Guide Release 5.0 Published:

2 Juniper Networks, Inc North Mathilda Avenue Sunnyvale, California USA All rights reserved. Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice. Products made or sold by Juniper Networks or components thereof might be covered by one or more of the following patents that are owned by or licensed to Juniper Networks: U.S. Patent Nos. 5,473,599, 5,905,725, 5,909,440, 6,192,051, 6,333,650, 6,359,479, 6,406,312, 6,429,706, 6,459,579, 6,493,347, 6,538,518, 6,538,899, 6,552,918, 6,567,902, 6,578,186, and 6,590,785. Junos Pulse Access Control Service User Access Management Framework Feature Guide Release 5.0 All rights reserved. The information in this document is current as of the date on the title page. YEAR 2000 NOTICE Juniper Networks hardware and software products are Year 2000 compliant. Junos OS has no known time-related limitations through the year However, the NTP application is known to have some difficulty in the year END USER LICENSE AGREEMENT The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with) Juniper Networks software. Use of such software is subject to the terms and conditions of the End User License Agreement ( EULA ) posted at By downloading, installing or using such software, you agree to the terms and conditions of that EULA. ii

3 Table of Contents About the Documentation xi Documentation and Release Notes xi Supported Platforms xi Documentation Conventions xi Documentation Feedback xiii Requesting Technical Support xiii Self-Help Online Tools and Resources xiv Opening a Case with JTAC xiv Part 1 Overview Chapter 1 Access Management Framework Access Management Overview Understanding Realm and Role Restrictions Restrictions Overview Accessing Authentication Realms Accessing User Roles Realm and Role Restrictions Sequence Understanding the Evaluation Process for Policies, Rules, Restrictions, and Conditions Using the Dynamic Policy Evaluation Feature Dynamic Policy Evaluation Overview Understanding Dynamic Policy Evaluation Understanding Standard Policy Evaluation Enabling Dynamic Policy Evaluation Chapter 2 Roles Understanding User Roles User Roles Overview User Role Evaluation Permissive Merge Guidelines Configuration of User Roles Chapter 3 Realms Understanding Authentication Realms Understanding Role Mapping Rules iii

4 User Access Management Framework Feature Guide Part 2 Configuration Chapter 4 Role Options Configuring General Role Options Defining Default Options for User Roles Specifying Role Access Options Specifying Session Limits Specifying Session Options Specifying UI Options for Agentless Access Customizing User Realm UI Views Chapter 5 Realm/Role Restrictions Using Source IP Access Restrictions Source IP Access Restriction Overview Specifying Source IP Restrictions Using Role Restrictions Specifying Browser Access Restrictions Specifying Certificate Access Restrictions Specifying Password Access Restrictions Specifying Host Checker Access Restrictions Chapter 6 Realms Before Configuring a Realm Creating an Authentication Realm Selecting Single Sign-on Specifying Role Mapping Rules for an Authentication Realm Using the LDAP Server Catalog Defining Authentication Access Policies Chapter 7 Sign-In Policies About Sign-In Policies Task Summary: Configuring Sign-In Policies About Configuring Sign-In Policies Associating Authentication Realms and Protocols with User Sign-in Policies Before Configuring Sign-In Policies Configuring and Managing Sign-In Policies Configuring User Sign-In Policies Enabling and Disabling Sign-in Policies Specifying the Order of Evaluation Configuring Administrator Sign-In Policies Configuring Sign-In Pages Sign-In Page Options Configuring Standard Sign-In Pages Using Sign-In Notifications Configuring and Implementing Sign-In Notifications Chapter 8 Session Migration Understanding Session Migration Session Migration Overview Session Migration and Session Timeout How Session Migration Works iv

5 Table of Contents Session Migration and Session Lifetime Session Migration and Load Balancers Authentication Server Support Task Summary: Configuring Session Migration Configuring Session Migration for the Pulse Client Part 3 Administration Chapter 9 Administrator Roles About Delegating Administrator Roles Creating Administrator Roles Specifying Management Tasks to Delegate Delegating System Management Tasks Delegating User and Role Management Delegating User Realm Management Delegating Administrative Management Delegating Resource Policy Management Defining Role Management Privileges for an Administrative Role Defining Realm Management Privileges for an Administrative Role Defining Security Administrator Privileges Defining General System Administrator Role Settings Defining Default Options for Administrator Roles Managing General Role Settings and Options Specifying Access Management Options for the Role Chapter 10 Guest User Account Management Configuring a Guest User Account Management Role Chapter 11 Guest User Accounts Setting Up for Guest User Accounts Chapter 12 Custom Expression in Rules and Policies Using Custom Expressions in Rule Configuration Custom Expressions Custom Expression Elements Wildcard Matching Using Multi-Valued Attributes Specifying Multivalued Attributes in a Bookmark Name Distinguished Name Variables System Variables Custom Variables and Macros append daysdiff regmatch Specifying Fetch Attributes in a Realm Specifying the homedirectory Attribute for LDAP v

6 User Access Management Framework Feature Guide vi

7 List of Figures Part 1 Overview Chapter 1 Access Management Framework Figure 1: Access Management Sequence for Realm and Role Restrictions Figure 2: IC Series Authenticates User Against Realm and Primary Server Figure 3: IC Series Authorizes User Figure 4: IC Series Maps User to One or More User Roles and Pushes Policies Figure 5: OAC and Infranet Enforcer Evaluate Policies Based on User Roles Figure 6: Infranet Enforcer Allows or Denies Access Based on Policy Match Chapter 2 Roles Figure 7: Security Checks Performed to Create a Session Role Part 2 Configuration Chapter 6 Realms Figure 8: Adding an Attribute for LDAP in the Server Catalog Figure 9: Adding LDAP Groups Figure 10: Adding Active Directory Groups Chapter 7 Sign-In Policies Figure 11: Realm Selection, Phase Figure 12: Realm Selection, Phase Figure 13: Realm Selection, Phase Chapter 8 Session Migration Figure 14: Requirements for Pulse Session Migration vii

8 User Access Management Framework Feature Guide viii

9 List of Tables About the Documentation xi Table 1: Notice Icons xii Table 2: Text and Syntax Conventions xii Part 2 Configuration Chapter 7 Sign-In Policies Table 3: RADIUS Sub-Protocols and Compatible Authentication Servers Part 3 Administration Chapter 12 Custom Expression in Rules and Policies Table 4: Custom Expression Elements Table 5: System Variables and Examples ix

10 User Access Management Framework Feature Guide x

11 About the Documentation Documentation and Release Notes Documentation and Release Notes on page xi Supported Platforms on page xi Documentation Conventions on page xi Documentation Feedback on page xiii Requesting Technical Support on page xiii Supported Platforms To obtain the most current version of all Juniper Networks technical documentation, see the product documentation page on the Juniper Networks website at If the information in the latest release notes differs from the information in the documentation, follow the product Release Notes. Juniper Networks Books publishes books by Juniper Networks engineers and subject matter experts. These books go beyond the technical documentation to explore the nuances of network architecture, deployment, and administration. The current list can be viewed at For the features described in this document, the following platforms are supported: IC4500 IC6500 FIPS IC6500 MAG Series Documentation Conventions Table 1 on page xii defines notice icons used in this guide. xi

12 User Access Management Framework Feature Guide Table 1: Notice Icons Icon Meaning Description Informational note Indicates important features or instructions. Caution Indicates a situation that might result in loss of data or hardware damage. Warning Alerts you to the risk of personal injury or death. Laser warning Alerts you to the risk of personal injury from a laser. Table 2: Text and Syntax Conventions Table 2 on page xii defines the text and syntax conventions used in this guide. Convention Description Examples Bold text like this Represents text that you type. To enter configuration mode, type the configure command: user@host> configure Fixed-width text like this Italic text like this Represents output that appears on the terminal screen. Introduces or emphasizes important new terms. Identifies guide names. Identifies RFC and Internet draft titles. user@host> show chassis alarms No alarms currently active A policy term is a named structure that defines match conditions and actions. Junos OS CLI User Guide RFC 1997, BGP Communities Attribute Italic text like this Text like this Represents variables (options for which you substitute a value) in commands or configuration statements. Represents names of configuration statements, commands, files, and directories; configuration hierarchy levels; or labels on routing platform components. Configure the machine s domain name: [edit] root@# set system domain-name domain-name To configure a stub area, include the stub statement at the [edit protocols ospf area area-id] hierarchy level. The console port is labeled CONSOLE. < > (angle brackets) Encloses optional keywords or variables. stub <default-metric metric>; xii

13 About the Documentation Table 2: Text and Syntax Conventions (continued) Convention Description Examples (pipe symbol) Indicates a choice between the mutually exclusive keywords or variables on either side of the symbol. The set of choices is often enclosed in parentheses for clarity. broadcast multicast (string1 string2 string3) # (pound sign) Indicates a comment specified on the same line as the configuration statement to which it applies. rsvp { # Required for dynamic MPLS only [ ] (square brackets) Encloses a variable for which you can substitute one or more values. community name members [ community-ids ] Indention and braces ( { } ) ; (semicolon) Identifies a level in the configuration hierarchy. Identifies a leaf statement at a configuration hierarchy level. [edit] routing-options { static { route default { nexthop address; retain; } } } GUI Conventions Bold text like this Represents graphical user interface (GUI) items you click or select. In the Logical Interfaces box, select All Interfaces. To cancel the configuration, click Cancel. > (bold right angle bracket) Separates levels in a hierarchy of menu selections. In the configuration editor hierarchy, select Protocols>Ospf. Documentation Feedback We encourage you to provide feedback, comments, and suggestions so that we can improve the documentation. You can send your comments to techpubs-comments@juniper.net, or fill out the documentation feedback form at If you are using , be sure to include the following information with your comments: Document or topic name URL or page number Software release version (if applicable) Requesting Technical Support Technical product support is available through the Juniper Networks Technical Assistance Center (JTAC). If you are a customer with an active J-Care or JNASC support contract, xiii

14 User Access Management Framework Feature Guide or are covered under warranty, and need post-sales technical support, you can access our tools and resources online or open a case with JTAC. JTAC policies For a complete understanding of our JTAC procedures and policies, review the JTAC User Guide located at Product warranties For product warranty information, visit JTAC hours of operation The JTAC centers have resources available 24 hours a day, 7 days a week, 365 days a year. Self-Help Online Tools and Resources For quick and easy problem resolution, Juniper Networks has designed an online self-service portal called the Customer Support Center (CSC) that provides you with the following features: Find CSC offerings: Search for known bugs: Find product documentation: Find solutions and answer questions using our Knowledge Base: Download the latest versions of software and review release notes: Search technical bulletins for relevant hardware and software notifications: Join and participate in the Juniper Networks Community Forum: Open a case online in the CSC Case Management tool: To verify service entitlement by product serial number, use our Serial Number Entitlement (SNE) Tool: Opening a Case with JTAC You can open a case with JTAC on the Web or by telephone. Use the Case Management tool in the CSC at Call JTAC ( toll-free in the USA, Canada, and Mexico). For international or direct-dial options in countries without toll-free numbers, see xiv

15 PART 1 Overview Access Management Framework on page 3 Roles on page 15 Realms on page 19 1

16 User Access Management Framework Feature Guide 2

17 CHAPTER 1 Access Management Framework Access Management Overview Access Management Overview on page 3 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 You can use an Infranet Enforcer or an 802.1X NAD (NAD) as the primary policy enforcement point for the network. You can also use Juniper Networks Intrusion Detection and Prevention (IDP) product as a policy enforcement measure. In addition to using these devices to control access, the Access Control Service provides numerous options that allow you to create more granular access management. Many of these options can be configured at the role level or the realm level, giving you the flexibility to control user access before authentication (apply policies at the realm level) or after authentication (apply policies at the role level). If you do not have an Infranet Enforcer to protect resources, you can use the Host Enforcer tool to enforce restrictions on endpoints using OAC. Host Enforcer is a stateful packet filter built into OAC. You create Host Enforcer policies on the Access Control Service by specifying resources for access control. Then designate the roles that are allowed or denied access to those resources. Related Documentation Understanding User Roles on page 15 Understanding Authentication Realms on page 19 Understanding Realm and Role Restrictions This topic describes access restrictions you can enforce per realm or per role. It includes the following information: Restrictions Overview on page 4 Accessing Authentication Realms on page 4 3

18 User Access Management Framework Feature Guide Accessing User Roles on page 5 Realm and Role Restrictions Sequence on page 5 Restrictions Overview The Access Control Service enables you to secure your company resources using authentication realms and user roles. This flexibility allows you to control access from a broad level (controlling who can sign into the Access Control Service) to a granular level (controlling which authenticated users can access a particular URL or file). You create policies on the Access Control Service that permit or deny access to resources and services based on a user s role and the security compliance of the endpoint device. With OAC and Pulse, you can incorporate the Infranet Enforcer to control access more effectively. The Access Control Service manages the user authentication and roles and stores the policies. The Access Control Service assigns the user a set of roles. These roles, in turn, specify what resources the endpoint can access. The Access Control Service pushes the allow or deny information for the user in the form of firewall policies to the Infranet Enforcer, OAC, and Pulse. When the Infranet Enforcer and the client have policies that allow access for the endpoint, the Infranet Enforcer allows traffic between the endpoint and the protected resources. Realm and role restrictions are not supported for deployments in which users access the Access Control Service using non-uac agents, such as non-juniper 802.1X supplicants. Accessing Authentication Realms Resource access begins with the authentication realm. An authentication realm is a grouping of authentication resources and includes: An authentication server Verifies that the user is who they claim to be. The Access Control Service forwards the user s credentials by way of OAC or Pulse, or by using a sign-in page for agentless and Java agent deployments to an authentication server. An authentication policy Specifies realm security requirements that must be met before the Access Control Service submits a user's credentials to an authentication server for verification. A directory server Provides user and group information to the Access Control Service that the Access Control Service uses to map users to one or more user roles. Role-mapping rules Specify conditions a user must meet for the Access Control Service 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. Session Migration Lets you configure session migration for authentication realms to allow Pulse users to access multiple devices (Access Control Service and Secure Access Service) without reauthentication. You can associate one or more authentication realms with an Access Control Service sign-in page. If a sign-page has more than one realm, the user can specify a realm. When the user submits credentials, the Access Control Service checks the authentication policy 4

19 Chapter 1: Access Management Framework defined for the realm. The user and the endpoint must meet the security requirements you define for a realm's authentication policy. Otherwise, the Access Control Service does not forward the user's credentials to the authentication server. At the realm level, you can specify security requirements based on 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 Access Control Service forwards the user's credentials to the appropriate authentication server. If the server successfully authenticates the user, then the Access Control Service evaluates the role-mapping rules defined for the realm to determine which roles to assign to the user. Accessing User Roles A role specifies session properties for users who are mapped to the role. These session properties include information such as session time-outs, limitations, and restrictions. A role's configuration serves as the second level of user 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 role 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 Infranet Enforcer or OAC, or Pulse, evaluates the corresponding resource policies. You can 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. Realm and Role Restrictions Sequence Figure 1 on page 6 shows the order in which the system evaluates realm and role restrictions after a user submits credentials on a sign-in page. 5

20 User Access Management Framework Feature Guide Figure 1: Access Management Sequence for Realm and Role Restrictions Related Documentation Understanding the Evaluation Process for Policies, Rules, Restrictions, and Conditions on page 6 Using the Dynamic Policy Evaluation Feature on page 11 Understanding Session Migration on page 71 Understanding the Evaluation Process for Policies, Rules, Restrictions, and Conditions The figures in this section show the transactions that take place between a user and the Access Control Service system and between the system and an authentication server or Infranet Enforcer. The flowcharts begin with a user signing in and end with the user ending the session by exiting the client or signing out (agentless access deployments). 6

21 Chapter 1: Access Management Framework Figure 2: IC Series Authenticates User Against Realm and Primary Server 7

22 User Access Management Framework Feature Guide Figure 3: IC Series Authorizes User Figure 4: IC Series Maps User to One or More User Roles and Pushes Policies 8

23 Chapter 1: Access Management Framework Figure 5: OAC and Infranet Enforcer Evaluate Policies Based on User Roles 9

24 User Access Management Framework Feature Guide 10

25 Chapter 1: Access Management Framework Figure 6: Infranet Enforcer Allows or Denies Access Based on Policy Match Related Documentation Using the Dynamic Policy Evaluation Feature on page 11 Using the Dynamic Policy Evaluation Feature This topic describes the dynamic policy evaluation feature. It includes the following information: Dynamic Policy Evaluation Overview on page 11 Understanding Dynamic Policy Evaluation on page 12 Understanding Standard Policy Evaluation on page 12 Enabling Dynamic Policy Evaluation on page 12 Dynamic Policy Evaluation Overview 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 verifies whether the client s status is changed. (For instance, the client s Host Checker status might change, or, if the user is roaming, the computer s IP address might change.) If the status has changed, the system allows or denies the user access to the dependent realms, roles, or resource policies accordingly. The system does not monitor changes in user attributes from a RADIUS, LDAP, or SiteMinder server during dynamic policy evaluation. Instead, the system re-evaluates rules and policies based on the original user attributes that it obtained when the user signed in. 11

26 User Access Management Framework Feature Guide Understanding Dynamic Policy Evaluation If the system determines after a dynamic policy evaluation that a user no longer meets the security requirements of a role, it terminates the connection immediately with the user. The user must take the necessary steps to meet the security requirements of the role, and then sign in 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 sign-in page, the system evaluates the Host Checker policies 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 requests for resource, the Infranet Enforcer evaluates resource access policies to determine whether 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 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 if the preceding events occur. If you use dynamic policy evaluation, the system enforces changes if the preceding events occur, and it 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 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 12

27 Chapter 1: Access Management Framework 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. Related Documentation Displaying Active Users 13

28 User Access Management Framework Feature Guide 14

29 CHAPTER 2 Roles Understanding User Roles Understanding User Roles on page 15 This topic describes how user roles are used in the Junos Pulse Access Control Service policy framework. It includes the following information: User Roles Overview on page 15 User Role Evaluation on page 16 Permissive Merge Guidelines on page 18 Configuration of User Roles on page 18 User Roles Overview A user role defines user session parameters (session settings and options) and personalization settings (user interface customization). At the role level, you specify whether associated endpoints download OAC, Pulse, the Java agent, or whether agentless access is permitted. A user role does not specify resource access control or other resource-based options for an individual request. The individual resources that a user can access are defined by the Infranet Enforcer resource access policies, Host Enforcer policies, or RADIUS attribute policies that you configure separately. The Access Control Service supports two types of user roles: Administrators An administrator role specifies system management functions and session properties for administrators who map to the role. You can customize an administrator role by selecting the feature sets and user roles that members of the administrator role are allowed to view and manage. You create and configure administrator roles by selecting Administrators > Admin Roles in the admin console. Users A user role defines user-session parameters and personalization settings. You can customize a user role by specifying access restrictions, enabling Host Enforcer (Windows). either or agentless or Java agent access, and configuring session settings. You create and configure user roles by selecting Users > User Roles in the admin console. 15

30 User Access Management Framework Feature Guide User Role Evaluation The role-mapping engine determines a user s session role, or combined permissions valid for a user session, as illustrated in Roles on page 15. A detailed description of each step follows after the diagram. NOTE: If you assign a role to a RADIUS proxy realm, role restrictions cannot be enforced. Host Checker policies, source IP restrictions, and any other limits that have been assigned are bypassed. Use RADIUS proxy only if no restrictions have been applied. Additionally, outer proxy cannot be used if a role-mapping rule based on usernames is being used, because the system cannot see the username, and a session cannot be created. Figure 7: Security Checks Performed to Create a Session Role 16

31 Chapter 2: Roles The system performs the following security checks before creating a session for a role: 1. The system begins rule evaluation with the first rule on the Role Mapping tab of the authentication realm to which the user successfully signs in. During the evaluation, the system determines if the user meets the rule conditions. If so, then: The system adds the corresponding roles to a list of eligible roles available to the user. The system determines whether or not the stop on match feature is configured. If so, then the engine proceeds to step The system evaluates the next rule on the authentication realm s Role Mapping tab according to the process in Step 1 and repeats this process for each subsequent rule. When the system evaluates all role-mapping rules, it compiles a comprehensive list of eligible roles. 3. The system evaluates the definition for each role in the eligibility list to determine whether the user complies with any role restrictions. The system then uses this information to compile a list of valid roles, whose requirements the user also meets. If the list of valid roles contains only one role, then the system assigns the user to that role. Otherwise, the system continues the evaluation process. 4. The system evaluates the setting specified on the Role Mapping tab for users who are assigned to more than one role. These settings include: Merge settings for all assigned roles If you select this option, the system performs a permissive merge of all the valid user roles to determine the overall (net) session role for a user session. User must select from among assigned roles If you select this option, the system presents a list of eligible roles to an authenticated user. The user must select a role from the list, and the system assigns the user to that role for the duration of the user session. User must select the sets of merged roles assigned by each rule If you select this option, the system presents a list of eligible rules to an authenticated user (that is, rules whose conditions the user has met). The user must select a rule from the list, and the system performs a permissive merge of all the roles that map to that rule. If you use automatic (time-based) dynamic policy evaluation or if you perform a manual policy evaluation, the system repeats the role evaluation process described in this section. 17

32 User Access Management Framework Feature Guide 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 18

33 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 19

34 User Access Management Framework Feature Guide 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 20

35 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 21

36 User Access Management Framework Feature Guide 22

37 CHAPTER 4 Role Options Configuring General 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 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 23

38 User Access Management Framework Feature Guide 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. 6. Select the Install Agent for this role check box. 24

39 Chapter 4: Role Options 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. 25

40 User Access Management Framework Feature Guide 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. 26