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 [email protected], 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

41 Chapter 4: Role Options 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. 27

42 User Access Management Framework Feature Guide 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 28

43 Chapter 4: Role Options 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 credentials, thereby avoiding the unexpected termination of the user session. NOTE: With machine authentication, a role prompt fails because no user is present to extend the session. b. For Heartbeat Interval, set the frequency at which the endpoint sends out a heartbeat to the Access Control Service to keep the session alive. For agentless access, the browser refreshes the page with every heartbeat. Users must not the browser, because this will interrupt the heartbeat and end the session. OAC, Pulse, and the Java agent provide the heartbeat. You should ensure that the heartbeat interval of the agent is greater than the Host Checker interval. If it is not, performance could be affected. In general, set the heartbeat interval to 50% more than the Host Checker interval. c. For Heartbeat Timeout, specify the amount of time the system should wait before terminating a session when the endpoint does not send a heartbeat response. d. For Auth Table Timeout, enter a timeout value for the auth table entry to be provisioned as needed. This parameter allows you to specify how long a user with no activity (for example, a user reading a static web page), can remain in the auth table before the auth table entry is cleared by the Infranet Enforcer. If the user accesses protected resources again after exceeding the timeout value specified, The system must provision the auth table entry to the Infranet Enforcer again. e. For OAC and agentless users, you can select the Enable Session Extension check box to allow users with a Layer 2 or Layer 3 connection to continue a session beyond the maximum session length. If this feature is enabled, users with OAC and agentless access can be reauthenticated and extend their current session without interruption. 29

44 User Access Management Framework Feature Guide If you select this, the timer on OAC and the browser window for agentless access display the time remaining in the session. If you do not select this option, the Extend Session button on OAC is not active, and the browser window for agentless access does not display the Extend Session option. When the user session nears the end of maximum session length, a pop up a new sign-in page for agentless and credential provider for OAC. When the user enters credentials, Host Checker verifies that the user is still compliant and the session continues. When the user extends the session before its expiration, the session time is restored to the original maximum session length time that you have specified for the role, and the log indicates the new session time. If the user fails to extend the session before session time expires, the session is terminated. For agentless access, you must select the Session Counter option on the UI Options tab to enable the session timer. f. Guest users (users created by guest user account managers) can log in with their guest account, and then tunnel into their corporate Virtual Private Network (VPN). In this case, the heartbeat connection to the Access Control Service is lost, and the user is disconnected after the heartbeat timeout expires. To prevent this, use firewall traffic as the heartbeat by selecting the Allow VPN Through Firewall check box. This feature applies only to new sessions. NOTE: When the Disable use of Allow VPN Through Firewall check box is not checked (the default setting), AJAX requests are sent to the IC at the configured interval. If the Use Traffic as Heartbeats option is enabled, AJAX heartbeat errors are masked. If a guest user is assigned two roles, and one of the roles has a Host Checker policy and one doesn't, the user loses the role with the Host Checker policy if the Host Checker policy expires while the user is accessing a VPN through a tunnel. The user will lose access to the resources associated with the Host Checker role. 3. Under Roaming session, specify: Enabled To enable roaming user sessions for users mapped to this role. A roaming user session works across source IP addresses, which allows mobile users (laptop users) with dynamic IP addresses to sign in from one location and continue working from another. Disable this feature to prevent users from accessing a previously established session from a new source IP address. This helps protect against an attack spoofing a user s session, provided the hacker was able to obtain a valid user's session cookie. Limit to subnet To limit the roaming session to the local subnet specified in the Netmask box. Users may sign in from one IP address and continue using their sessions with another IP address as long as the new IP address is within the same subnet. 30

45 Chapter 4: Role Options Disabled To disable roaming user sessions for users mapped to this role. Users who sign in from one IP address may not continue an active session from another IP address. User sessions are tied to the initial source IP address. NOTE: You must enable roaming for roles that are created for security policies that classify sessions into VLANs, for example, VLANs that have been provisioned for Users or Remediation. A session stores the client IP address. If the session gets placed in a different VLAN transition, the control channel is re-established, and a new IP address is sent to the server. If the remediation role does not have roaming enabled, the server terminates the session. This can lead to repeated problems. When the session is terminated, it cause a new log on, which reconnects to the same session, resulting in the same roaming problem. The Pulse client sets a connection roaming error and logs the server FATAL_ERROR message. 4. Click Save Changes. Related Documentation Specifying Role Access Options on page 25 Specifying UI Options for Agentless Access on page 31 Specifying UI Options for Agentless Access You can specify customized settings for the welcome page for agentless users who are mapped to a role. The system welcome (or home) is the Web interface presented to authenticated users in agentless access deployments. Select the UI Options option on the Overview tab to enable custom settings for the role. Otherwise, the system uses the default settings. If a user maps to more than one role, then the system displays the user interface settings that correspond to the first role to which the user is mapped. NOTE: If an authenticated user attempts to close the agentless browser window or to navigate to another site, a warning message is displayed. The message advises the user that they will lose access to protected resources if the user moves away from the current page. The user can select Cancel to stay on the current page, or they can select OK to go to the new site. If the user navigates to a different site, they can click the browser back button to return to the resource page, as long as the session timeout is not exceeded. To customize the welcome page for role users: 1. Select Users > User Roles > Role Name > General > UI Options. 2. (Optional) Under Header, specify a custom logo and alternate background color for the header area of the welcome page: 31

46 User Access Management Framework Feature Guide Click Browse and locate your custom image file. The new logo is displayed in the Current appearance box only after you save your changes. Type the hexadecimal number for the background color, or click the Color Palette icon and select a color. The Current appearance box updates immediately. 3. Under User Toolbar, select the Session Counter check box to display both a session countdown timer and an Extend button that allows agentless users to extend their session time to the maximum session length if the Enable Session Extension option is selected. 4. (Optional) Under Post-Auth Sign-In Notification, select a post authentication message that you configured earlier. If you select this option, the user receives an information page (for example, an end-user license agreement [EULA]) that you have created. If you defined a post sign-in notification and you select a message for a role, the user is presented with the notification message after authentication. The user is prompted to click Proceed or Decline. If the user clicks Proceed, the protected resource is available to the user. If the user clicks Decline, they are immediately logged off and returned to the authentication page. 5. (Optional) Under Personalized greeting, select the Show notification message check box, and enter a message in the associated text box. The message is displayed as a header on the welcome page after the user is authenticated. You can format text and add links using the following HTML tags: <i>, <b>, <br>, <font>, and <a href>. This information does not appear on the initial sign-in page that is displayed prior to authentication. You can also use system variables and attributes in this field. The length of the personalized greeting cannot exceed 12K, (12288 characters). If you use unsupported HTML tags in your custom message, the system might display the user s home page incorrectly. 6. (Optional) Under Informative, select the Show instruction message check box and specify any instructions to appear on the welcome page. For example, you could advise users of company privacy notices or usage restrictions, or you can link to another site for more information. As with the notification message, you can use the following HTML tags: <i>, <b>, <br>, <font>, and <a href>. If you use unsupported HTML tags in your custom message, the might display the user s home page incorrectly. If you include a link to an external website, a warning message appears informing the user of loss of access privileges if they leave the current page. To avoid this, add a tag for opening links in a new browser window. For example: <a href= target= _blank >Google</a> displays the linked text Google, and the link opens in a new browser window. The instruction message supports non-english languages. 7. (Optional) Under Other, specify whether or not to display the copyright notice and label in the footer. This setting applies only to users whose license permits disabling 32

47 Chapter 4: Role Options the copyright notice. For more information about this feature, call Juniper Networks Support. 8. (Optional) Click Restore Factory Defaults to reset all user-interface options back to factory defaults. Click Save Changes. The changes take effect immediately, but current user browser sessions might need to be refreshed to see the changes. Related Documentation Specifying Session Options on page 29 Using Sign-In Notifications on page 68 Customizing User Realm UI Views You can use customization options on the User Authentication Realms page to quickly view the settings that are associated with a specific realm or set of realms. For instance, you can view the role-mapping rules that you associated with all your user realms. Additionally, you can use these customized views to easily link to the authentication policies, servers, role-mapping rules, and roles associated with a user realms. To view a subset of data on the User Authentication Realms page: 1. Select one of the following options from the View menu: Overview Displays the authentication servers and dynamic policy evaluation settings that you have set for the specified user realms. You can also use this setting to link to the specified server configuration pages. Authentication Policy Displays Host Checker restrictions that you have enabled for the specified user realms. You can also use this setting to link to the specified Host Checker configuration pages. Role Mapping Displays rule conditions and corresponding role assignments that you have enabled for the specified user realms. You may also use this setting to link to the specified rule conditions and role assignments configuration pages. Servers Displays authentication server names and corresponding types that you have enabled for the specified user realms. You may also use this setting to link to the specified server configuration pages. Roles Displays role assignments and corresponding permissive merge settings that you have enabled for the specified user realms. 2. Select one of the following options from the For list: All realms Displays the selected settings for all user realms. Selected realms Displays the selected settings for the user realms you choose. If you select this option, select one or more of the check boxes in the Authentication Realm list. 3. Click Update. 33

48 User Access Management Framework Feature Guide 34

49 CHAPTER 5 Realm/Role Restrictions Using Source IP Access Restrictions Using Source IP Access Restrictions on page 35 Using Role Restrictions on page 37 Specifying Browser Access Restrictions on page 37 Specifying Certificate Access Restrictions on page 39 Specifying Password Access Restrictions on page 40 Specifying Host Checker Access Restrictions on page 41 This topic describes how to use the source IP access restriction feature. It includes the following information: Source IP Access Restriction Overview on page 35 Specifying Source IP Restrictions on page 36 Source IP Access Restriction Overview Use a source IP restriction at the role or realm level to control from which IP addresses users can access a sign-in page, be mapped to a role, or access a resource. Use a source IP restriction to control from which IP addresses users can access an sign-in page, be mapped to a role, or access a resource. You can restrict resource access by source IP: When administrators or users try to sign in to the Access Control Service The user must sign in from a machine whose IP address/netmask combination meets the source IP requirements for the authentication realm. If the user's machine does not have the IP address/netmask combination required by the realm, the system does not forward the user's credentials to the authentication server and the user is denied access. You can allow or deny access to any IP address/netmask combination. For example, you can deny access to all users on a wireless network ( ), or you can allow access to all other network users ( ). When administrators or users are mapped to a role The authenticated user must be signed in from a machine whose IP address/netmask combination meets the Source 35

50 User Access Management Framework Feature Guide IP requirements for each role to which the system might map the user. If not, then the system does not map the user to that role. You can also use a source IP restriction in the following ways: Source IP restriction on realms Suppose an Infranet Enforcer is installed between a particular access network and the rest of the network, and the system routes all traffic through this Infranet Enforcer. You can use a source IP restriction to allow users to log in from only the access network, because logging in from any other network results in denial of network access. For example, you can use this configuration to prevent users from logging in from networks other than a wireless network. Source IP restriction on roles You can use source IP restrictions to set up different roles for different access networks. Only endpoints from a particular access network are assigned the role that corresponds to that network. You can then create Infranet Enforcer IPsec routing policies and Infranet Enforcer source IP specifically for the that role so that endpoints route network traffic through the appropriate Infranet Enforcer. Specifying Source IP Restrictions To specify source IP restrictions: 1. Select the level at which you want to implement IP restrictions: Realm level Select: Administrators > Admin Realms > SelectRealm > Authentication Policy > Source IP Users > User Realms > SelectRealm > Authentication Policy > Source IP Role level Select: Administrators > Admin Roles > Select Role > General > Restrictions > Source IP Users > User Roles > Select Role > General > Restrictions > Source IP 2. Select one of the following options: Allow users to sign in from any IP address Allows users to sign in from any IP address to satisfy the access management requirement. Allow or deny users from the following IP addresses Specifies whether to allow or deny users access from all of the listed IP addresses, based on their settings. To specify access from an IP address: a. Enter the IP address and netmask. b. Select either Allow to allow users to sign in from the specified IP address, or Deny to prevent users from signing in from the specified IP address. 3. Click Save Changes to save your settings. Related Documentation Using Role Restrictions on page 37 Creating an Authentication Realm on page 44 36

51 Chapter 5: Realm/Role Restrictions Specifying Browser Access Restrictions on page 37 Specifying Certificate Access Restrictions on page 39 Specifying Password Access Restrictions on page 40 Specifying Host Checker Access Restrictions on page 41 Specifying Session Limits on page 27 Understanding the Evaluation Process for Policies, Rules, Restrictions, and Conditions on page 6 Using Role Restrictions You can specify access management options for the role by selecting restrictions at the top of the General tab for a role. The system uses these restrictions to determine whether or not to map a user to the role. The system does not map users to this role unless they meet the specified restrictions. You can configure any number of access management options for the role. If a user does not conform to all of the restrictions, then the system does not map the user to the role. If you configure a role that is assigned to a RADIUS proxy realm, role restrictions cannot be enforced. The proxy target authenticates users without regard to any restrictions that you configured. Related Documentation Using Source IP Access Restrictions on page 35 Specifying Browser Access Restrictions on page 37 Specifying Certificate Access Restrictions on page 39 Specifying Host Checker Access Restrictions on page 41 Specifying Role Access Options on page 25 Specifying Browser Access Restrictions Use a browser restriction to control from which Web browsers users can access a sign-in page or be mapped to a role. If a user tries to sign in using an unsupported browser, the sign-in attempt fails and a message is displayed stating that an unsupported browser is being used. This feature also enables you to ensure that users sign in from browsers that are compatible with corporate applications or that are approved by corporate security policies. You can restrict network and resource access by browser type: When administrators or users try to sign in to the Access Control Service 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 Access Control Service submits the user's credentials to the authentication server. If the realm denies the browser's user-agent 37

52 User Access Management Framework Feature Guide string, then the Access Control Service 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 might 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. The browser restrictions feature is not intended as a strict access control because a technical user can change browser user-agent strings. Rather, this feature 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 Select: Administrators > Admin Realms > Select Realm > Authentication Policy > Browser Users > User Realms > Select Realm > Authentication Policy > Browser Role level Select: Administrators > Admin Realms > Select Realm > Role Mapping > Select Create Rule > Custom Expressions Administrators > Admin Roles > Select Role > General > Restrictions > Browser Users > User Realms > Select Realm > Role Mapping > Select Create Rule > Custom Expression Users > User Roles > Select Role > General > Restrictions > Browser 2. Select one of the following options: Allow all users matching any user-agent string sent by the browser Allows users to access the network 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: a. For the user-agent string pattern, enter a string in the format *<browser_string>* where asterisk (*) 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. You cannot include escape characters (\) in browser restrictions. b. Select either: Allow to allow users to use a browser that has a user-agent header containing the <browser_string> substring. 38

53 Chapter 5: Realm/Role Restrictions Deny to prevent users from using a browser that has a user-agent header containing the <browser_string> substring. c. iii. 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 Related Documentation Understanding the Evaluation Process for Policies, Rules, Restrictions, and Conditions on page 6 Specifying Certificate Access Restrictions When you install a client-side certificate, you can restrict resource access by requiring client side certificates. Select System > Configuration > Certificates > Trusted Client CAs. When administrators or users try to sign in to the Access Control Service The user must sign in from a machine that has the specified client-side certificate (from the proper CA) and with any 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. To implement certificate restrictions at the realm level, select: Administrators > Admin Realms > Select Realm > Authentication Policy > Certificate Users > User Realms > Select Realm > 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 CA) and optionally field/value pair requirements for each role to which the system might 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. Select: Administrators > Admin Roles > Select Role > General > Restrictions > Certificate Users > User Realms > Select Realm Role Mapping > Select CreateRule > Custom Expression 39

54 User Access Management Framework Feature Guide Users > User Roles > Select Role > General > Restrictions > Certificate The value in the field depends on the naming attributes in the Relative Distinguished Name(RDN) in the subject DN of the certificate. For example, if the subject DN is cn=user1, uid=uid1, sn=lastname, OU=QA, O=juniper, C=US, you can use cn, uid, sn, E, ou, o, c. But if you use uid in a certificate where it does not exist, e.g. cn=user1, ou=qa, o=juniper, c=us, it will not match. All of the naming attributes in X509 distinguished names are supported. But to determine what you can use you must know what is in the certificate. NOTE: This applies to (Admin/User) realm and role certificate restrictions, but not for Role Mapping rules. With role mapping rules you can use additional certificate attributes in the rule itself, or in custom expressions. 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 Password Access Restrictions You can restrict network and resource access by password-length when administrators or users try to sign in. 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 local authentication server. This server requires that passwords are a minimum length of 6 characters, 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: Administrators > Admin Realms > Select Realm > Authentication Policy > Password Users > User Realms > Select Realm > Authentication Policy > Password 2. Select one of the following options: Allow all users (passwords of any length) Does not apply password restrictions on password length. Only allow users that have passwords of a minimum length Requires the user to enter a password with a minimum length that you specify. 3. Select Enable Password Management 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. Click Save Changes to save your settings. 40

55 Chapter 5: Realm/Role Restrictions 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 might require a different minimum length. For example, the local authentication database requires user passwords to be a minimum length of six characters. 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 Host Checker Access Restrictions Host Checker is a client-side application that is downloaded to endpoints upon the initial connection with the Access Control Service. Predefined rules that check for antivirus software and up-to-date virus signatures, firewalls, malware, spyware, and specific operating systems from a wide variety of industry leaders. (On Windows machines only.) (Windows machines only) Custom rules that use integrity measurement collectors (IMCs) and integrity measurement verifiers (IMVs) to perform customized client-side checks. A variety of other checks to ensure that an endpoint meets the security policies that you configure. You can configure Host Checker at the role level or the realm level. Related Documentation Understanding the Evaluation Process for Policies, Rules, Restrictions, and Conditions on page 6 Using the Dynamic Policy Evaluation Feature on page 11 Creating Global Host Checker Policies 41

56 User Access Management Framework Feature Guide 42

57 CHAPTER 6 Realms Before Configuring a Realm Before Configuring a Realm on page 43 Creating an Authentication Realm on page 44 Selecting Single Sign-on on page 46 Specifying Role Mapping Rules for an Authentication Realm on page 46 Using the LDAP Server Catalog on page 48 Defining Authentication Access Policies on page 52 Topic Details About RADIUS Proxy The Access Control Service supports RADIUS proxy for both inner and outer authentication. RADIUS proxy allows you to use an external RADIUS server for authentication. If the authentication server for a realm is a RADIUS server, three option buttons: Proxy RADIUS Inner Authentication, Proxy RADIUS Outer Authentication, and Do not proxy are visible. If the authentication server is not a RADIUS server, the proxy check boxes are hidden. RADIUS Proxy limitations When RADIUS proxy is used, realm or role restrictions cannot be enforced. Host Checker policies, Source IP restrictions, and any other limits that have been assigned will be bypassed.use RADIUS proxy only if no restrictions have been applied. LDAP and attribute server behavior If the LDAP server is down, user authentication fails. You can find messages and warnings in the event log files. When an attribute server is down, user authentication does not fail. Instead, the groups/attributes list for role-mapping and policy evaluation is empty. Dynamic Policy Evaluation If you select Dynamic policy evaluation and you do not select Refresh roles and Refresh resource policies, the system evaluates the realm s authentication policy, role-mapping rules, and role restrictions only. 43

58 User Access Management Framework Feature Guide Topic Details Performance impacts with Dynamic Policy Evaluation Because dynamic policy evaluation can potentially impact system performance, keep these guidelines in mind: Since automatic (timer-based) refreshing of user roles and resource policies can affect system performance, you can improve performance by disabling either or both of the Refresh roles and Refresh resource policies options to reduce the scope of the refresh. To improve performance, set the Refresh interval option to a longer time period. Use the Refresh Now button at times when users are not likely to be affected. Related Documentation Understanding Authentication Realms on page 19 Creating an Authentication Realm on page 44 Defining Authentication Access Policies on page 52 Creating an Authentication Realm To create an authentication realm: 1. In the admin console, select Administrators > Admin Realms or Users > User Realms. 2. On the respective Authentication Realms page, click New. Alternatively, select a realm and click Duplicate to base your realm on an existing realm. 3. Enter a name to label this realm and, optionally, a description. 4. If you are copying an existing realm, click Duplicate. Then, if you want to modify any of its settings, click the realm s name to enter into edit mode. 5. Select When editing, start on the Role Mapping page if you want the Role Mapping tab to be selected when you open the realm for editing. 6. Under Servers, specify: An authentication server to use for authenticating users who sign in to this realm. (Optional) A directory/attribute server to use for retrieving user attribute and group information for role-mapping rules and resource policies. (Optional) A RADIUS accounting server to use to track when a user signs in and out. 7. If you previously selected a RADIUS server for Authentication, the RADIUS Proxy option buttons appear. Select Proxy Outer Authentication or Proxy Inner Authentication to allow the system to proxy EAP authentication methods. Select Do not proxy if you do not want to use RADIUS proxy. 44

59 Chapter 6: Realms 8. To use dynamic policy evaluation for this realm, select Dynamic policy evaluation to enable an automatic timer for dynamic policy evaluation of this realm s authentication policy, role-mapping rules, and role restrictions. Then: a. Select the Refresh interval option to specify how often to perform an automatic policy evaluation of all currently signed in realm users. Specify the number of minutes (5 to 1440). b. Select Refresh roles to refresh the roles of all users in this realm. (This option does not control the scope of the Refresh Now button.) c. Select Refresh resource policies to also refresh the resource policies (not including Meeting and Client) for all users in this realm. (This option does not control the scope of the Refresh Now button.) d. Click Refresh Now to manually evaluate the realm s authentication policy, role-mapping rules, role restrictions, user roles, and resource policies of all currently signed-in realm users. Use this button 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 this realm s users. 9. To use session migration for endpoints with the Pulse client, select the Session Migration check box. Then enter the Authentication Group and specify whether you want to receive user attributes from IF-MAP or from a directory server. Note that you must also configure IF-MAP Federation for all of Access Control Service and Secure Access Service nodes in a session migration network. 10. Click Save Changes to create the realm. The General, Authentication Policy, and Role Mapping tabs for the authentication realm appear. 11. Perform the next configuration steps: a. Configure one or more role-mapping rules. b. Configure an authentication policy for the realm. 12. After you configure the authentication realm, select Authentication > Signing In > Sign-in Policies, add the realm to a sign-in policy, and associate the realm with an authentication protocol set. Related Documentation Defining Authentication Access Policies on page 52 Before Configuring a Realm on page 43 Using RADIUS Proxy Configuring and Managing Sign-In Policies on page 63 Using the Dynamic Policy Evaluation Feature on page 11 Understanding Session Migration on page 71 Task Summary: Configuring Session Migration on page 75 45

60 User Access Management Framework Feature Guide Selecting Single Sign-on If you select an Active Directory authentication server for a realm, a new SSO option becomes available under Authentication Policy. By default, the SSO check box is selected. When the Junos Pulse Access Control Service realm and the endpoint use the same Active Directory server, during authentication the endpoint obtains a Kerberos ticket from the Active Directory server and sends the ticket instead of sending a username and password. The Junos Pulse Access Control Service verifies the Kerberos ticket and allows Pulse to connect without prompting for a username and password from the user. This feature requires the Domain Controller to be reachable to endpoints from where the user is connecting to the device. Specifying Role Mapping Rules for an Authentication Realm When you create a new rule that uses LDAP or SiteMinder user attributes, LDAP group information, or custom expressions, you must use the server catalog. To specify role-mapping rules for an authentication realm: 1. Select Administrators > Admin Realms, Users > User Realms, or UAC > MAC Address Realms. 2. On the Authentication Realms page, select a realm and then click the Role Mapping tab. 3. Click New Rule to access the Role Mapping Rule page. This page provides an inline editor for defining the rule. 4. In the Rule based on list, select one of the following: Username The system username entered on the sign-in page. Select this option if you want to map users to roles based on their usernames. If this is a RADIUS realm, and you are using RADIUS proxy for outer authentication, you cannot configure a role-mapping rule with a username. User attribute A user attribute from a RADIUS, LDAP, or SiteMinder server. Select this option if you want to map users to roles based on an attribute from the corresponding server. This type of rule is available only for realms that use a RADIUS server for the authentication server, or that use an LDAP or SiteMinder server for either the authentication server or the directory server. After choosing the User attribute option, click Update to display the Attribute list and the Attributes button. Click the Attributes button to display the server catalog. 46

61 Chapter 6: Realms To add SiteMinder user attributes, enter the SiteMinder user attribute cookie name in the Attribute field in the server catalog. Then click Add Attribute. When you are finished adding cookie names, click OK. The system displays the names of the SiteMinder user attribute cookies in the Attribute list on the Role Mapping Rule page. Certificate or Certificate attribute Certificate or Certificate attribute is an attribute supported by the users client-side certificate. Select this option to map users to roles based on certificate attributes. The Certificate option is available for all realms. The Certificate attribute option is available only for realms that use LDAP for the authentication or directory server. After choosing this option, click Update to display the Attribute text box. Group membership Group membership is group information from an LDAP or native Active Directory server that you add to the server catalog Groups tab. Select this option to map users to roles based on either LDAP or Active Directory group information. This type of rule is available only for realms that use an LDAP server for either the authentication server or directory server or that use an Active Directory server for authentication. (Note that you cannot specify an Active Directory server as an authorization server for a realm.) Custom Expressions Custom Expressions is one or more custom expressions that you define in the server catalog. Select this option to map users to roles based on custom expressions. This type of rule is available for all realms. After you select this option, click Update to display the Expressions lists. Click the Expressions button to display the Expressions tab of the server catalog. 5. Under Rule, specify the condition to evaluate, which corresponds to the type of rule you select and consists of the following: CAUTION: If you are creating a role mapping rule for a MAC address authentication realm, the attributes list cannot be edited. If there is an LDAP server assigned to this MAC authentication server and you want to use and edit the attributes assigned to that LDAP server, please specify the LDAP server as the Directory/Attribute server. a. Specifying one or more usernames, SiteMinder user attribute cookie names, RADIUS or LDAP user attributes, certificate attributes, LDAP groups, or custom expressions. b. Specifying to what the value must equate, which might include a list of usernames, user attribute values from a RADIUS, SiteMinder, or LDAP server, client-side certificate values (static or LDAP attribute values), LDAP groups, or custom expressions. For example, you can choose a SiteMinder user attribute cookie named department from the Attribute list, choose is from the operator list, and then enter "sales" and "eng" in the text box. Alternatively, you can enter a custom expression rule that references the SiteMinder user attribute cookie named department: 47

62 User Access Management Framework Feature Guide <userattr.department = ("sales" and "eng")> 6. Under...then assign these roles: a. Specify the roles to assign to the authenticated user by adding roles to the Selected Roles list. b. Select Stop processing rules when this rule matches if you want the system to stop evaluating role-mapping rules if the user meets the conditions specified for this rule. 7. Click Save Changes to create the rule on the Role Mapping tab. When you finish creating rules, be sure to order role-mapping rules in the order in which you want the system to evaluate them. This task is particularly important when you want to stop processing role-mapping rules when a match is identified. Related Documentation Understanding Role Mapping Rules on page 20 Using the LDAP Server Catalog on page 48 Configuring General Role Options on page 23 Understanding the Evaluation Process for Policies, Rules, Restrictions, and Conditions on page 6 Using the LDAP Server Catalog The LDAP server catalog is a secondary window through which you specify additional LDAP information for the system to use when mapping users to roles, including: Attributes The Server Catalog Attributes tab shows a list of common LDAP attributes, such as cn, uid, uniquemember, and memberof. This tab is accessible only when accessing the Server Catalog of an LDAP server. You can use this tab to manage an LDAP server s attributes by adding custom values to and deleting values from its server catalog. Note that the system maintains a local copy of the LDAP server s values; attributes are not added to or deleted from your LDAP server s dictionary. Groups The Server Catalog Groups tab provides a mechanism to easily retrieve group information from an LDAP server and add it to the server catalog. You specify the BaseDN of your groups and optionally a filter to begin the search. If you do not know the exact container of your groups, you can specify the domain root as the BaseDN, such as dc=juniper, dc=com.the search page returns a list of groups from your server, from which you can choose groups to enter into the Groups list. NOTE: The BaseDN value specified in the LDAP server s configuration page under "Finding user entries" is the default BaseDN value. The Filter value defaults to (cn=*). You can also use the Groups tab to specify groups. You must specify the fully qualified domain name (FQDN) of a group, such as cn=goodmanagers, ou=hq, ou=juniper, 48

63 Chapter 6: Realms o=com, c=us, but you can assign a label for this group that is displayed in the Groups list. Note that this tab is accessible only when accessing the Server Catalog of an LDAP server. Expressions The Server Catalog Expressions tab provides a mechanism to write custom expressions for the role-mapping rule. To display the LDAP server catalog: After you select the User attribute option on the Role Mapping Rule page, click Update to display the Attribute list and the Attributes button. Click the Attributes button to display the LDAP server catalog. (You can also click Groups after choosing the Group membership option, or click Expressions after choosing the Custom Expressions option.) Figure 8: Adding an Attribute for LDAP in the Server Catalog 49

64 User Access Management Framework Feature Guide Figure 9: Adding LDAP Groups 50

65 Chapter 6: Realms 51

66 User Access Management Framework Feature Guide Figure 10: Adding Active Directory Groups Related Documentation Specifying Role Mapping Rules for an Authentication Realm on page 46 Using Custom Expressions in Rule Configuration on page 91 Defining Authentication Access Policies An authentication policy is a set of rules that controls one aspect of access management whether or not to present a realm s sign-in page to a user. An authentication policy is part of an authentication realm s configuration, specifying rules to consider before presenting a sign-in page to a user. If a user meets the requirements 52

67 Chapter 6: Realms specified by the authentication policy, the system presents the corresponding sign-in page to the user and then forwards the user's credentials to the appropriate authentication server. If this server authenticates the user, the system continues to the role evaluation process. To specify authentication realm access policies: 1. Select Administrators > Admin Realms or Users > User Realms. 2. On the respective Authentication Realms page, select a realm and then click the Authentication Policy tab. 3. On the Authentication Policy page, configure one or more access management options. Related Documentation Using Source IP Access Restrictions on page 35 Specifying Browser Access Restrictions on page 37 Specifying Certificate Access Restrictions on page 39 Specifying Password Access Restrictions on page 40 Specifying Host Checker Access Restrictions on page 41 Specifying Session Limits on page 27 53

68 User Access Management Framework Feature Guide 54

69 CHAPTER 7 Sign-In Policies About Sign-In Policies About Sign-In Policies on page 55 Task Summary: Configuring Sign-In Policies on page 56 About Configuring Sign-In Policies on page 57 Associating Authentication Realms and Protocols with User Sign-in Policies on page 58 Before Configuring Sign-In Policies on page 62 Configuring and Managing Sign-In Policies on page 63 Configuring Administrator Sign-In Policies on page 65 Configuring Sign-In Pages on page 66 Using Sign-In Notifications on page 68 Configuring and Implementing Sign-In Notifications on page 69 Sign-in policies define both the URLs that users and administrators use to access the network and the sign-in pages that they see. The Access Control Service has two types of sign-in policies one for users and one for administrators. When you configure sign-in policies, you associate realms, sign-in pages, and URLs that are provided for users when they first log in. To allow users to sign in, you add user authentication realms to sign-in policies. You can associate realms with a variety of authentication protocols to accommodate different types of endpoints. For example, a Juniper Networks client (OAC or Pulse), IP phones, and non-juniper 802.1X supplicants can access the network, but each of these endpoints might require different authentication protocols. 55

70 User Access Management Framework Feature Guide NOTE: You can create multiple sign-in policies to enable different users to sign in to different URLs and pages. When you configure a sign-in policy, you associate it with a sign-in URL, a sign-in page, one or more realms, and an authentication protocol set. Only members of the specified authentication realm may sign in using the URL defined in the policy. When you define sign-in policies, you can use different hostnames (such as users1.yourcompany.com and users2.yourcompany.com) or different paths (such as yourcompany.com/users1 and yourcompany.com/users2) to differentiate between URLs. For Windows systems, you can display different sign-in pages for users based on whether or not you want the endpoint to download OAC or Pulse. You specify whether you want the Access Control Service to install OAC, Pulse, the Java agent, or agentless access on endpoints at the role level. If you use role-mapping to associate roles with specific realms, you can specify which users get OAC or Pulse installed and which users do not, and you can specify the associated message that each group views on the sign-in page. For example, if you have contract employees with noncompany machines onto which you do not want to install a Juniper Networks client, you can create two roles: one that allows agentless access and another requiring installation of OAC or Pulse. Then you can create two associated realms: one for agentless access and one for the Juniper Networks client. Add role-mapping rules based on usernames to assign the contract employees to the agentless role, and employees to the Juniper Networks client role. When a user attempts to log in, they are assigned to a role that either provisions agentless access or installs a Juniper Networks client. You can associate the different realms with different sign-in policies and sign-in pages, so users who login to a resource can see a sign-in page based on whether or not they are a regular employee or a contractor. Related Documentation Task Summary: Configuring Sign-In Policies on page 56 Before Configuring Sign-In Policies on page 62 Configuring and Managing Sign-In Policies on page 63 Configuring Administrator Sign-In Policies on page 65 Task Summary: Configuring Sign-In Policies User sign-in policies determine the realm that users and administrators can access. Depending on whether a sign-in policy is for endpoints (users) or administrators, the configuration options differ. For users, alternate authentication protocol sets can be configured, and realm selection is based on the authentication method that is associated 56

71 Chapter 7: Sign-In Policies with the realm. In most applications, configuring authentication protocol sets is not required. To configure sign-in policies: 1. In the admin console, select Administrators > Admin Realms or the Users > User Realms to create an authentication realm. 2. (Optional) To modify an existing sign-in page or create a new one using options, select Authentication > Signing In > Sign-in Pages. 3. (Optional) Create a new authentication protocol set to associate with the realm. This step is necessary only if the realm is required to provide access for a non-uac supplicant (for example, Microsoft Vista with a Statement of Health Host Checker policy). For users authenticating with OAC, Pulse, the Java agent for Linux clients, or agentless access, use the default 802.1X protocol set. 4. Select Authentication > Signing In > Sign-in Policies and specify a sign-in policy that associates a realm, sign-in URL, and sign-in page. 5. If you differentiate between URLs using hostnames, you must either associate each host name with its own certificate, or upload a wildcard certificate. Select System > Configuration > Certificates > Device Certificates. Related Documentation About Sign-In Policies on page 55 Before Configuring Sign-In Policies on page 62 Associating Authentication Realms and Protocols with User Sign-in Policies on page 58 Configuring Sign-In Pages on page 66 Configuring Administrator Sign-In Policies on page 65 Configuring and Managing Sign-In Policies on page 63 Creating an Authentication Realm on page 44 About Configuring Sign-In Policies User sign-in policies determine the realm that users and administrators can access. Depending on whether a sign-in policy is for endpoints (users) or administrators, the configuration options differ. For users, alternate authentication protocol sets can be configured, and realm selection is based on the authentication method that is associated with the realm. In most applications, configuring authentication protocol sets is not required. Related Documentation Configuring Administrator Sign-In Policies on page 65 Configuring and Managing Sign-In Policies on page 63 Associating Authentication Realms and Protocols with User Sign-in Policies on page 58 57

72 User Access Management Framework Feature Guide Associating Authentication Realms and Protocols with User Sign-in Policies Different types of endpoints can request authentication through the Access Control Service, including UAC agents, third-party 802.1X supplicants (including 802.1X IP phones), switches, and endpoints that request authentication with agentless access. A UAC agent is software that can use the Juniper JUAC protocol. UAC agents include OAC, Pulse, and the Java agent. By default, the Access Control Service can communicate with UAC agents, the Java agent, and endpoints with agentless access. To accommodate other types of endpoint clients, you might need to create authentication protocol sets within sign-in policies. When you add a realm in a sign-in policy, you select an authentication protocol set to be used with that realm. There are two default authentication protocol sets. For UAC agents, use the default 802.1X authentication protocol set. For 802.1X IP phones, use the default 802.1X-Phones protocol set. Third-party 802.1X supplicants cannot use the preconfigured 802.1X protocol set that is used by default with UAC agents. For example, some switches can request authentication using CHAP or EAP-MD5-Challenge. You must define a specific authentication protocol set for these requests. To define an endpoint s authentication method, you add authentication realms to sign-in policies. You configure authentication protocol sets as required, based on authentication methods that are compatible with the authentication server that you are using. The Access Control Service maps the sign-in policy to the authentication realms that you choose. Users who sign in using the URL that you provide have access only to those realms that you specify. For non-uac agents, you must select the protocols that the client and the authentication server are compatible with. See Table 3 on page 58 for details of what authentication protocols are compatible with different authentication servers. Table 3: RADIUS Sub-Protocols and Compatible Authentication Servers Authentication Servers Protocols Certificate Local LDAP Active Directory ACE Mac Auth EAP-GTC Y - PAP - Y Y Y Y - CHAP, EAP-MD5-Challenge - Y Y MS-CHAP - Y Y Y MS-CHAP-V2, EAP-MS-CHAP-V2 - Y Y Y

73 Chapter 7: Sign-In Policies Table 3: RADIUS Sub-Protocols and Compatible Authentication Servers (continued) Authentication Servers EAP-TLS Y Mac-based auth Y EAP-JUAC Y Y Y Y Y - NOTE: For 802.1X, AD authentication server used as LDAP is not supported for the following protocols: MS-CHAP, MS-CHAP-V2, and EAP-MS-CHAP-V2. The decision of what realms are available to the user within a sign-in policy is based on two factors. First, the order of realms in the list is considered. Realms at the top of the list are attempted. Second, the authentication protocol set that you choose must be compatible with the client or supplicant. To determine a compatible realm, the system looks for a RADIUS subprotocol that is compatible with the client or supplicant s available protocols, and the system automatically selects compatible realms. If the endpoint is using a UAC agent, the system presents a list of realms. Any realm with both outer and inner protocols that match the outer and inner protocols on the client is considered compatible. Protocol compatibility does not guarantee authentication. For example, CHAP and EAP-MD-5 challenge sign-in succeeds only if the stored password is retrievable as cleartext. In addition, if the client or supplicant is configured with a non-juac protocol (for example, the Windows Vista supplicant), the system searches for a realm without TNC Host Checker restrictions, browser restrictions, or certificate restrictions. NOTE: If you are configuring a realm for a Windows client, with a Statement of Health Host Checker policy, you must use an authentication protocol set with the EAP-SOH protocol. When you select EAP-SOH in an authentication protocol set, EAP-SOH is always offered first, regardless of protocol ordering. If an endpoint is using UAC agent software, the system presents the list of realms to the user or administrator when the user signs in and allows the user to choose a realm from the list. The system does not display a list of authentication realms if the URL is mapped only to one realm. Instead, it automatically uses the realm you specify. For endpoints that use a non-uac agent, you can select the User may specify the realm name as a username suffix check box. When the user provides a username with a suffix in the format user@realm, the suffix determines the realm assignment. If you do not select this option, the endpoint is assigned to the first realm in the list whose authentication server is a match with the endpoint s software. For example, if the endpoint s software is configured for tokens (EAP-Generic Token Card), and if the sign 59

74 User Access Management Framework Feature Guide in policy permits EAP-GTC, the endpoint is assigned the first realm in the list whose authentication server supports tokens. When an 802.1X IP phone connects through a realm with the 802.1X-Phone protocol set selected, the device is automatically directed to the proper realm for authentication based on the compatible protocol. If you are using inner or outer RADIUS proxy with a selected realm, routing with respect to authentication protocols is different. The Access Control Service forwards all traffic to a proxy target, which rejects protocols it does not support. With an outer proxy realm, the Access Control Service ignores the authentication protocol set. For an inner proxy realm, the authentication protocol set directs the Access Control Service as it negotiates the outer protocol (EAP-PEAP or EAP-TTLS) but does not affect the inner protocol. Figure 11 on page 60, Figure 12 on page 61, and Figure 13 on page 62 illustrate the realm selection process. Figure 11: Realm Selection, Phase 1 60

75 Chapter 7: Sign-In Policies Figure 12: Realm Selection, Phase 2 61

76 User Access Management Framework Feature Guide Figure 13: Realm Selection, Phase 3 Related Documentation About Sign-In Policies on page 55 Before Configuring Sign-In Policies on page 62 Configuring and Managing Sign-In Policies on page 63 Understanding Access Control Service Authentication Protocols Using Access Control Service Authentication Protocol Sets Configuring Authentication Protocol Sets Before Configuring Sign-In Policies Topic Details 62

77 Chapter 7: Sign-In Policies Wildcard characters in host name Use wildcard characters (*) only at the beginning of the host name portion of the URL. The system does not recognize wildcards in the URL path. OAC or Pulse sign in Endpoints that use OAC or Pulse with Layer 3 access the sign-in-page for the initial login. After clients are assigned a role, and provisioned with the client, subsequent authentication requests are performed through the client. Outer proxy realms If you are configuring an outer proxy realm, you do not have to specify an authentication protocol set, and not Applicable should be used as the authentication protocol. Anonymous authentication servers If you allow a user to select from multiple realms, and one of those realms uses an anonymous authentication server, the system does not display that realm in the realm list. To effectively map your sign-in policy to an anonymous realm, add only that realm to the Authentication realm list. If you attempt to add more than one realm where one realm uses anonymous auth, the system presents an error message: Unable to create new sign-in URL: cannot select both anonymous and non-anonymous realms. Username suffixes By default, the User may specify the realm name as a username suffix check box is not selected. If you choose this option, non-uac endpoints access the system by entering their credentials in the format user@realm. Proxy realm sign-in If you configure a sign-in policy with multiple realms, and one of the realms is a proxy realm, the user must append a suffix to the username to access the proxy realm. Related Documentation Configuring and Managing Sign-In Policies on page 63 Task Summary: Configuring Sign-In Policies on page 56 Configuring and Managing Sign-In Policies This topic describes how to configure and manage user sign-in policies. It includes the following information: Configuring User Sign-In Policies on page 63 Enabling and Disabling Sign-in Policies on page 64 Specifying the Order of Evaluation on page 64 Configuring User Sign-In Policies To create or configure user sign-in policies: 1. In the admin console, select Authentication > Signing In > Sign-in Policies. 2. To create a new sign-in policy, click New URL. To edit an existing policy, click a URL in the Administrator URLs or User URLs column. 63

78 User Access Management Framework Feature Guide 3. In the Sign-in URL field, enter the URL that you want to associate with the policy. Use the format <host>/<path>, where <host> is the host name of the Access Control Service, and <path> is any string users must enter. For example: users1.yourcompany.com/ic. To specify multiple hosts, use the asterisk (*) wildcard character. For example, to specify that all end-user URLs must use the sign-in page, enter */. 4. Under Authentication realm, specify the realms that must be mapped to the sign-in policy. Under Available realms, select realms from the menu. The system maps the sign-in policy only to the authentication realms that you add. 5. Under Authentication protocol set, select an authentication protocol set that you have configured previously. If endpoints will connect with a UAC agent, select the default 802.1X protocol set. The protocol set used with a realm must be compatible with the authentication server that is associated with the realm. 6. Click Add to add the new realm and authentication protocol pair. 7. Select the User may specify the realm name as a username suffix check box to allow non-uac endpoints to access the system by entering their credentials (in the format user@realm). 8. Select the Remove realm suffix before passing to authentication server check box for users to enter their credentials with a suffix to send the username without the suffix. Most authentication servers are not compatible with a realm suffix or decorated username. 9. Click Save Changes. Enabling and Disabling Sign-in Policies To enable and disable sign-in policies: 1. In the admin console, select Authentication > Signing In > Sign-in Policies. 2. To enable or disable: An individual policy Select the check box for the policy that you want to change. Then click Enable or Disable. All user policies Select or clear the Restrict access to administrators only check box at the top of the page. 3. Click Save Changes. Specifying the Order of Evaluation The Access Control Service evaluates sign-in policies in the same order that you list them on the Sign-in Policies page. When it finds a URL that matches exactly, it stops evaluating and presents the appropriate sign-in page to the administrator or user. For example, for 2 administrator sign-in policies with different URLs: The first policy uses the URL */admin and maps to the default administrator sign-in page. 64

79 Chapter 7: Sign-In Policies The second policy uses the URL yourcompany.com/admin and maps to a custom administrator sign-in page. If you list the policies in this order on the Sign-in Policies page, the system never evaluates or uses the second policy because the first URL encompasses the second one. Even if an administrator signs in using the yourcompany.com/admin URL, the system displays the default administrator sign-in page. If you list the second policy first, however, the system displays the custom administrator sign-in page to administrators who access the system using the yourcompany.com/admin URL. Note that the system accepts only wildcard characters in the hostname section of the URL and matches URLs based on the exact path. For example, two administrator sign-in policies with two different URL paths: The first policy uses the URL */marketing and maps to a custom sign-in page for the entire Marketing Department. The second policy uses the URL */marketing/joe and maps to a custom sign-in page designed exclusively for Joe in the Marketing Department. If you list the policies in this order on the Sign-in Policies page, the system displays Joe s custom sign-in page to him when he uses the yourcompany.com/marketing/joe URL to access the system. He does not see the Marketing sign-in page, even though it is listed and evaluated first, because the path portion of his URL does not exactly match the URL defined in the first policy. To change the order in which administrator sign-in policies are evaluated: 1. In the admin console, select Authentication > Signing In > Sign-in Policies. 2. Select a sign-in policy in the Administrator URLs or User URLs list. 3. Click the up or down arrow to change the selected policy s placement in the list. 4. Click Save Changes. Related Documentation Before Configuring Sign-In Policies on page 62 Associating Authentication Realms and Protocols with User Sign-in Policies on page 58 Configuring Administrator Sign-In Policies 1. In the admin console, select Authentication > Signing In > Sign-in Policies. 2. To create a new sign-in policy, click New URL. To edit an existing policy, click a URL in the Administrator URLs or the User URLs column. 3. To create an administrator sign-in policy, select the Administrators option button at the top of the page. (By default, the Users option button is selected.) 4. In the Sign-in URL field, enter the URL to associate with the policy. Use the format <host>/<path> where <host> is the hostname of the Access Control Service, and 65

80 User Access Management Framework Feature Guide <path> is any string users must enter. For example: users1.yourcompany.com/ic. To specify multiple hosts, use the asterisk (*) wildcard character. For instance: To specify that all administrator URLs must use the sign-in page, enter */admin. NOTE: Use wildcard characters (*) only at the beginning of the hostname portion of the URL. The system does not recognize wildcards in the URL path. 5. (Otional) Enter a Description for the policy. 6. From the Sign-in Page list, select the page that you want to associate with the policy. You can select the default page, a variation of the standard sign-in page, or a custom page that you create using the customizable UI feature. 7. For administrator sign-in policies, under Authentication realm, specify which realm maps to the policy, and how users and administrators must choose from among realms. If you select: User types the realm name The system maps the sign-in policy to all authentication realms but does not provide a list of realms from which the administrator can choose. Instead, the administrator must manually enter the realm name into the sign-in page. User picks from a list of authentication realms The system maps the sign-in policy to only the authentication realms that you choose. The system presents this list of realms when the administrator signs in and allows a realm to be chosen from the list. (Note that the system does not provide a list of authentication realms if the URL is mapped only to one realm. Instead, only the realm you specify is displayed) Click the Add button to add available realms to the Selected realms box. 10. Click Save Changes. Related Documentation Before Configuring Sign-In Policies on page 62 Creating an Authentication Realm on page 44 Associating Authentication Realms and Protocols with User Sign-in Policies on page 58 Configuring Sign-In Pages This topic describes how to configure sign-in pages. It includes the following information: Sign-In Page Options on page 67 Configuring Standard Sign-In Pages on page 67 66

81 Chapter 7: Sign-In Policies Sign-In Page Options A sign-in page defines the customized properties in the end-user s welcome page such as the welcome text, help text, logo, header, and footer. The system allows you to create two types of sign-in pages to present to users and administrators: Standard sign-in pages Standard sign-in pages are included with the default system. You can modify standard sign-in pages by selecting Authentication > Signing In > Sign-in Pages. Customized sign-in pages Customized sign-in pages are THTML pages that you produce using the Template Toolkit and upload in the form of an archived ZIP file. The customized sign-in pages feature enables you to use your own pages rather than modify the standard sign-in pages. Configuring Standard Sign-In Pages You can modify the default sign-in page that the system displays at sign-in. You can also create new standard sign-in pages that contain custom text, logo, colors, and error message text. To create or modify a standard sign-in page: 1. In the admin console, select Authentication > Signing In > Sign-in Pages. 2. If you are: Creating a new page Click New Page. Modifying an existing page Select the link for the page you want to modify. 3. Enter a name to identify the page. 4. In the Custom text section, revise the default text used for the various screen labels. When you add text to the Instructions field, you can format text and add links using the following HTML tags: <i>, <b>, <br>, <font>, and <ahref>. However, the system does not rewrite links on the sign-in page (because the user has not yet been authenticated), so point only to external sites. Links to sites behind a firewall will fail. If you use unsupported HTML tags in your custom message, the system might display the end-user s home page incorrectly. 5. (Optional) In the Header appearance section, specify a custom logo image file for the header and a different header color. 6. (Optional) In the Custom error messages section, revise the default text that is displayed to users if they encounter certificate errors. You can include <<host>>, <<port>>, <<protocol>>, and <<request>> variables and user attribute variables, such as <<userattr.cn>> in the custom error messages. These variables must be in the format <variable> to distinguish them from HTML tags that have the format <tag>. 7. (Optional) To provide custom help or additional instructions for your users, select Show Help button, enter a label to display on the button, and specify an HTML file to 67

82 User Access Management Framework Feature Guide upload. Note that the system does not display images and other content referenced in this HTML page. 8. Click Save Changes. The changes take effect immediately, but users with active sessions might need to refresh their Web browser. Click Restore Factory Defaults to reset the sign-in page, user home page, and admin console appearance. Related Documentation About Sign-In Policies on page 55 Using Sign-In Notifications With sign-in notifications, you can create and configure detailed notification messages that appear for Pulse clients and for agentless access endpoints when the user attempts to sign in. For example, you could configure a notification message that explains terms of use, company-specific policies, a welcome page, an end user license agreement (EULA), or a message of the day (MOTD). For a browser-based (agentless) login, the notification message appears in a separate page either before (pre-auth) or after (post-auth) user authentication during the sign-in process. For a Pulse client login, the notification messages appear in a Pulse message box. The user is expected to read the content of the sign-in notification message and acknowledge by clicking a Proceed button. The user may indicate disagreement by clicking a Decline button, which ends the login attempt. You can configure a sign-in policy to use a sign-in notification either as pre-auth or post-auth (or both). In the case of post-auth configuration, you can either use a common message for all roles or use separate messages for each role. You can create a multi-language sign-in notification package that relies on the language setting of the endpoint. You can customize the sign-in notification page appearance for browser-based logins by modifying the related fields in a sign-in page in the Admin UI or by using a custom sign-in page. Notes: Sign-in notifications are supported on Windows, Mac, and for browser-based access on mobile devices. However, sign-in notifications might not work well with all mobile devices due to device limitations. Sign-in notifications (including uploaded packages) are included in XML exports. If a Pulse session is resumed or extended, the pre-auth notification message is not shown again. However, if the user switches roles when resuming a session, and that role change results in a new notification, Pulse displays the message. You can configure the post-auth message to be skipped if it has already been seen. If the post-auth message is not marked to be skipped, then it always appears. Related Documentation Specifying UI Options for Agentless Access on page 31 Configuring and Managing Sign-In Policies on page 63 68

83 Chapter 7: Sign-In Policies Configuring and Implementing Sign-In Notifications on page 69 Configuring and Implementing Sign-In Notifications Sign-in notifications appear for Pulse client and for browser-based logins when the user attempts to sign in. To configure and implement sign-in notifications: 1. Select Authentication > Signing In > Sign-in Notifications. 2. Click New Notification. 3. Specify a Name for the notification. This name appears in the sign-in policies page, and in the UI Options page for a selected role. 4. Select Text or Package in the Type box. If you select Text, type the desired sign-in notification message, or copy and paste the relevant text into the Text field. If you select Package, click the Browse button and navigate to a previously prepared.zip file. A package is typically used to provide different language versions of the notification message. The zip file should include a default.txt file and one or more <language>.txt files (Example: en.txt). Language-abbreviations should be strings that can appear in Accept-Language header of an HTTP request. The character encoding supported is UTF-8. NOTE: When you create a zip file, do not add the folder containing the files, but add the files directly. 5. Click Save Changes. To enable sign-in notifications: 1. In the admin console, click Authentication > Signing In > Sign-in Policies. 2. Under Configure Sign-in Notifications, select the check box for Pre-Auth Sign-in Notification, Post-Auth Sign-in Notification, or both. After Pre-Auth Sign-in Notification, select a previously configured sign-in notification from the drop-down menu. After Post-Auth Sign-in Notification, select the option for Use a common Sign-in Notification for all roles or Use the Sign-in Notification associated to the assigned role. If you select Use a common Sign-in Notification for all roles, select a previously configured sign-in notification from the drop-down menu. 69

84 User Access Management Framework Feature Guide If you select Use the Sign-in Notification associated to the assigned role, the sign-in notification configured for the assigned role will be used. Prevent the Post-Auth sign-in notification from being displayed to users who have seen it before, by selecting the Skip if already shown check box. (This is only a hint to the system and might not be honored in all environments.) 3. Click Save Changes. 4. You can customize the appearance of the sign-in notification message by selecting Authentication > Signing In > Sign-in Pages and creating a sign-in page or using an existing page. 5. Under Sign-in Notification appearance, customize UI options for Pre-Auth Notifications and Post-Auth Notifications by changing the following items: For Notification Title enter the text that appears at the top of the sign-in notification page. In the Proceed Button box, enter the text for the button that the user clicks to proceed with the sign-in. This text applies to browser-based logins only. A Pulse client login always displays Proceed. Optionally, clear the check box for Display Decline Button. If this box is not checked, the user does not have the option to decline. In the Decline Button box, enter the text for the button that the user clicks to decline. This text applies to browser-based logins only. A Pulse client login always displays Decline. In the Message on Decline box, enter the text that you would like to appear when a user clicks the Decline button. 6. Click Save Changes. NOTE: If you enabled Use the Sign-in Notification associated to the assigned role you must complete the implementation by selecting the sign-in notification on the Users > User Roles > Role Name > General > UI Options page or Administrators > Admin Roles > Role Name > General > UI Options page, as applicable. If more than one role is available to a user, the sign-in notification associated with the first role assigned is displayed. 7. Add the sign-in page in which you have customized the sign-in notification appearance to the sign-in policy. Related Documentation Specifying UI Options for Agentless Access on page 31 Configuring and Managing Sign-In Policies on page 63 Using Sign-In Notifications on page 68 70

85 CHAPTER 8 Session Migration Understanding Session Migration Understanding Session Migration on page 71 Task Summary: Configuring Session Migration on page 75 Configuring Session Migration for the Pulse Client on page 76 This topic describes the session migration feature. It includes the following information: Session Migration Overview on page 71 Session Migration and Session Timeout on page 73 How Session Migration Works on page 73 Session Migration and Session Lifetime on page 74 Session Migration and Load Balancers on page 74 Authentication Server Support on page 74 Session Migration Overview When you enable session migration on two or more Pulse servers, a Pulse endpoint can migrate from one location to another and connect to a different Pulse server without providing additional authentication. For example, a user can be connected from home through a Pulse Secure Access server, and then arrive at work and connect to a Pulse Access Control server without being reauthenticated. If session migration is not enabled, Pulse users must be reauthenticated each time they attempt to access the network through a different Pulse server. Sessions can be migrated between Pulse Access Control and Pulse Secure Access servers that are in the same IF-MAP federated network: using either the same IF-MAP server, or using IF-MAP servers that are replicas of one another. The servers must be in the same authentication group. Authentication groups are configured through authentication realms. An authentication group is a string that you define for common usage. You can use authentication groups to group together realms with similar authentication methods. Such as,, one authentication group for SecurID authentication, another authentication group for AD. A single gateway can belong to more than one authentication group, with a different authentication group per realm. 71

86 User Access Management Framework Feature Guide The Pulse server to which a user authenticates publishes session information to the IF-MAP server. Other IF-MAP clients in the federated network can use the information to permit access without additional authentication to users. When a user session is migrated to another Pulse server, the new session information is pushed to the IF-MAP server. The IF-MAP server notifies the authenticating server, and information about the session that existed on the original server is removed leaving only session information about the current authenticating server on the IF-MAP server. The authenticating server removes information about the session from its local session table. When a session is migrated, realm role-mapping rules determine user access capabilities. You can import user attributes when a session is migrated, or you can configure a dedicated directory server to look up attributes for migrated user sessions. To ensure that session migration retains user sessions, configure a limited access remediation role that does not require a Host Checker policy. This role is necessary because the Host Checker timeout can be exceeded if an endpoint is in hibernation or asleep. With the new remediation role, the user s session is maintained. If additional Host Checker policies are configured on a role or realm to which a migrated session applies, the policies are performed before allowing the user to access the role or realm. Administrators of different Pulse servers should ensure that Host Checker policies are appropriately configured for endpoint compatibility. Session Migration on page 71 illustrates the task flow for enabling session migration for Pulse. 72

87 Chapter 8: Session Migration Figure 14: Requirements for Pulse Session Migration Start Support Session Migration? Yes Using a supported authentication system? Yes Access devices in the same IF-MAP federated network? Yes Access devices in the same authentication group? Yes No No No No Client Configuration (connections and connection policies) Client Preconfiguration (select components for the client) Distribute Pulse based on Role or create and distribute installer package Session Migration and Session Timeout Session timeout on the authenticating server does not apply to a migrated session. Instead, session start time is applicable. The inbound server evaluates session timeout using the start time of the original session on the original server. When a user reboots an endpoint for which session migration is enabled, the session is retained for a short time on the server. For sessions on the Pulse Access Control server, sessions are retained until the heartbeat timeout expires. For Pulse Secure Access server sessions, the idle timeout determines how long the session is retained. If an endpoint that is connected to a Pulse Access Control server or Pulse Secure Access server is rebooted and the user does not sign out, when the endpoint is restarted and the user attempts to connect to the same access gateway, Pulse resumes the previous session without requesting user credentials if the previous session is still active. How Session Migration Works Session migration uses IF-MAP Federation to coordinate between servers. When a session is established, the authenticating gateway publishes the session information, including a session identifier, to the IF-MAP server. The session identifier is also communicated to the Pulse client. 73

88 User Access Management Framework Feature Guide When the Pulse client connects to a migrating gateway in the same authentication group, the Pulse client sends the session identifier to the migrating gateway. The migrating gateway uses the session identifier to look up the session information in the IF-MAP server. If the session information is valid, the migrating gateway uses the session identifier to establish a local session for the endpoint that the Pulse client is running on. The IF-MAP server notifies the authenticating gateway that the user session has migrated, and the authenticating gateway deletes the session information from the IF-MAP server. Session Migration and Session Lifetime Session migration is designed to give users maximum flexibility and mobility. Users are no longer tied to the office. The workplace can travel with the user, and electronic chores such as online banking can come to work. Because of this flexibility, users might be away from their machines for long periods of time, allowing their active session to expire. Session migration requires users to have an active session on the Pulse Access Control or Pulse Secure Access server. You can adjust session lifetime to ensure that sessions do not time out while users are away from their machines. You adjust session lifetime on the gateway by selecting Users > User Roles > Role Name > General > Session Options in the admin console. Session Migration and Load Balancers A Pulse client that connects to a Pulse server that is behind a load balancer will attempt to migrate the network connection if the connected server fails. The Pulse servers must be federated and configured for session migration. For example, a load balancer that balances to 2 Pulse servers (non-clustered) balances to Server1. If Server1 fails, the load balancer then balances to Server2. A Pulse client that is connected to Server1 is migrated to Server2 without re-authentication. Authentication Server Support The behavior of session migration depends to some extent on the authentication server on the inbound side. The following list provides a summary of authentication server support: Local authentication server Migration succeeds if the username is valid on the local authentication server. LDAP server Migration succeeds if the LDAP authentication server can resolve the username to a distinguished name (DN). NIS server Migration succeeds if the NIS authentication server can find the username on the NIS server. ACE server Migration always succeeds. RADIUS server Migration always succeeds. If you select Lookup Attributes using Directory Server, no attributes are present in the user context data. Active Directory Migration always succeeds. The Lookup Attributes using Directory Server option might not work, depending on your configuration. 74

89 Chapter 8: Session Migration Anonymous No support for migrating sessions because sessions are not authenticated. Siteminder No support for migrating sessions because Siteminder SSO is used instead. Certificate No support for migrating sessions because sessions are authenticated using certificates. SAML No support for migrating sessions because SAML SSO is used instead. NOTE: For local, NIS, and LDAP authentication servers, the inbound username must reflect an existing account. Related Documentation Configuring Session Migration for the Pulse Client on page 76 Task Summary: Configuring Session Migration on page 75 Task Summary: Configuring Session Migration To permit session migration for users with the Pulse client, perform the following tasks: 1. Configure location awareness rules within a client connection set to specify locations included in the scope of session migration for users. For example, configure location awareness rules for a corporate Pulse Access Control server connection and a Pulse Secure Access server connection. 2. Configure an IF-MAP federated network, with the applicable Pulse Access Control servers and SA Series appliances as IF-MAP Federation clients of the same IF-MAP Federation server. 3. Ensure that user entries are configured on the authentication server for each gateway. 4. Ensure that user roles are configured for all users on each gateway. 5. Define a remediation role with no Host Checker policies to allow user sessions to be maintained when an endpoint is sleeping or hibernating. 6. Configure role-mapping rules that permit users to access resources on each gateway. 7. Enable and configure session migration from the User Realms page of the admin console. 8. Distribute the Pulse client to users. Related Documentation Understanding Session Migration on page 71 Configuring Session Migration for the Pulse Client on page 76 Understanding Federated Deployments 75

90 User Access Management Framework Feature Guide Configuring Session Migration for the Pulse Client NOTE: Ensure that all of the Pulse Access Control servers and Pulse Secure Access servers for which you want to enable session migration are IF-MAP Federation clients of the same IF-MAP Federation server. Additionally, make sure that each gateway is configured according to the procedures outlined in this section. To configure session migration: 1. In the admin console, select Users > User Realms. 2. Select an existing realm, or create a new realm. 3. On the General page, select the Session Migration check box. Additional options appear. 4. In the Authentication Group box, enter a string that is common to all of the gateways that provision session migration for users. The authentication group is used as an identifier. 5. Select for either the Use Attributes from IF-MAP option button or the Lookup Attributes using Directory Server option. NOTE: Select Lookup Attributes using Directory Server only if you are using an LDAP server. Attributes are served faster with an LDAP server. Related Documentation Understanding Session Migration on page 71 Task Summary: Configuring Session Migration on page 75 Understanding Federated Deployments 76

91 PART 3 Administration Administrator Roles on page 79 Guest User Account Management on page 87 Guest User Accounts on page 89 Custom Expression in Rules and Policies on page 91 77

92 User Access Management Framework Feature Guide 78

93 CHAPTER 9 Administrator Roles About Delegating Administrator Roles About Delegating Administrator Roles on page 79 Creating Administrator Roles on page 80 Specifying Management Tasks to Delegate on page 81 Defining Role Management Privileges for an Administrative Role on page 83 Defining Realm Management Privileges for an Administrative Role on page 83 Defining Security Administrator Privileges on page 84 Defining General System Administrator Role Settings on page 85 The Access Control Service access management system enables you to delegate various management tasks to different administrators through system administrator roles and security administrator roles. System and security administrator roles are defined entities that specify management functions and session properties for administrators who are mapped to those roles. You can customize an administrator role by selecting the feature sets, user roles, authentication realms, and resource policies that members of the administrator role are allowed to view and manage. Note that system administrators may only manage user roles, realms, and resource policies; security administrators can manage only administrator components. For example, you can create an administrator role called Help Desk Administrators and assign users to this role who are responsible for handling tier 1 support calls, such as helping users understand why they cannot sign in or access protected resources. In order to help with troubleshooting, you can configure settings for the Help Desk Administrators role as follows: Give the help desk administrators Write access to the Log/Monitoring page so they can view and filter the logs, tracking down critical events in individual users session histories, as well as the Maintenance > Troubleshooting page so they can trace problems on individual users systems. Give the help desk administrators Read access to the User Roles pages so they can view the restrictions on individual users roles, as well as the Resource Policy pages so they can view the policies that might be denying individual users access to protected resources. 79

94 User Access Management Framework Feature Guide Deny the help desk administrators access to the remaining System pages and Maintenance pages, which are used primarily for configuring system-wide settings such as installing licenses and service packages, not for troubleshooting user problems. NOTE: In addition to delegated administrator roles that you create, the system also includes two basic types of administrators: super administrators (.Administrators role), who can perform any administration task through the admin console and read-only administrators (.Read-only Administrators role), who can view but not change the entire system configuration through the admin console. You can also create a security administrator role called Help Desk Manager and assign users to this role who are responsible for managing the help desk administrators. You might configure settings for the Help Desk Manager role to allow the Help Desk Manager to create and delete their administrator roles. The Help Desk Manager might create administrator roles that segment responsibilities by functional areas. For example, one administrator role might be responsible for all log monitoring issues. Another might be responsible for all problems related to accessing protected resources. Related Documentation Creating Administrator Roles on page 80 Specifying Management Tasks to Delegate on page 81 Defining Role Management Privileges for an Administrative Role on page 83 Defining Realm Management Privileges for an Administrative Role on page 83 Creating Administrator Roles On the Administrators page, you can set default session and user interface options for delegated administrator roles. To create individual administrator accounts, you must add the users through the appropriate authentication server (not through the role). For example, to create an individual administrator account, select Authentication > Auth. Servers > Administrators > Users in the admin console. For instructions on how to create users on third-party servers, see the documentation that comes with that product. To create an administrator role: 1. In the admin console, select Administrators > Admin Roles. 2. Do one of the following: Click New Role to create a new administrator role with the default settings. Select the check box for an existing administrator role and click Duplicate to copy the role and its custom permissions. Note that you cannot duplicate the system default roles (.Administrators and.read-only Administrators). 80

95 Chapter 9: Administrator Roles 3. Enter a Name (required) and Description (optional) for the new role and click Save Changes. 4. Modify settings for the role according to the instructions in the sections that follow. NOTE: If you select one of the default administrator roles (.Administrators or.read-only Administrators), you can only modify settings in the General tab (since the default administrators roles always have access to the functions defined through the System, Users, Administrators, and Resource Policies tabs). You cannot delete the.administrators and.read Only Administrators roles because they are default roles. Related Documentation Specifying Management Tasks to Delegate on page 81 Defining Role Management Privileges for an Administrative Role on page 83 Defining Realm Management Privileges for an Administrative Role on page 83 Specifying Management Tasks to Delegate This topic describes how to delegate management tasks to various delegated administrator roles. It includes the following information: Delegating System Management Tasks on page 81 Delegating User and Role Management on page 82 Delegating User Realm Management on page 82 Delegating Administrative Management on page 82 Delegating Resource Policy Management on page 82 Delegating System Management Tasks Select Administrators > Admin Roles > Select Role > System to delegate various system management tasks to different administrator roles. When delegating privileges, note the following: The system allows all administrators read-access (at minimum) to the admin console home page (System > Status > Overview), regardless of the privilege level you choose. The system does not allow delegated administrators write-access to pages where they can change their own privileges. Only those administrator roles that come with the system (.Administrators and.read-only Administrators) may access these pages: Maintenance > Import/Export (Within this page,.read-only Administrators can export settings, but cannot import them.) Maintenance > Archiving > Local Backups 81

96 User Access Management Framework Feature Guide Delegating User and Role Management Select Administrators > Admin Roles > Select Role > Users > Roles to specify which user roles the administrator role can manage. When delegating role management privileges, note that: Delegated administrators can only manage user roles. Delegated administrators cannot create new user roles, copy existing roles, or delete existing roles. If you allow the delegated administrator to read or write to any feature within a user role, the system also grants the delegated administrator read access to the Overview page for that role. Delegating User Realm Management Select Administrators > Admin Roles > Select Role > Users > Authentication Realms to specify which user authentication realms the administrator role can manage. When delegating realm management privileges, note the following: System administrators can manage only user realms. System administrators cannot create new user realms, copy existing realms, or delete existing realms. If you allow the system administrator to read or write to any user realm page, the system also grants the system administrator read-access to the General page for that role. Delegating Administrative Management Select Administrators > Admin Roles > Select Roles > Administrators to specify which system administrator roles and realms the security administrator role can manage. When delegating security administrative privileges, note the following: The security administrator role provides control over all administrative roles and realms. You can give a security administrator control exclusively over administrator roles, over administrator realms, or over both. You can restrict or grant the security administrator the permission to add and delete administrator roles and administrator realms. Delegating Resource Policy Management Select Administrators > Admin Roles > Resource Policies to specify which user resource policies the administrator role can manage. When delegating resource policy management privileges, note that delegated system administrators cannot modify the following characteristics of resource policies: The resource itself (that is, the IP address/netmask). The order in which the Infranet Enforcer evaluates the resource policies. 82

97 Chapter 9: Administrator Roles Related Documentation About Delegating Administrator Roles on page 79 Defining Role Management Privileges for an Administrative Role To define role management privileges for an administrative role: 1. In the admin console, select Administrators > Admin Roles. 2. Select the administrator role that you want to modify. 3. Select the Users > Roles tab (this is the default). 4. Under Delegate user roles, select the option button for Administrator can manage ALL roles or Administrator can manage SELECTED roles. If you only want to allow the administrator role to manage only selected user roles, select those roles in the Available roles list and click Add. 5. Specify which user role pages the delegated administrator can manage by selecting one of the following options: Write All Specifies that members of the administrator role can modify all user role pages. Custom Settings Allows you to choose administrator privileges (Deny, Read, or Write) for individual user role pages. 6. Under Delegate as read-only roles, select the user roles that you want to allow the administrator to view but not manage. NOTE: If you specify both write access and read-only access for a feature, the system grants the most permissive access. For example, if you select Administrators can manage ALL roles under Delegated user roles, and then you select the Users role in the Delegate as read-only roles section, the system allows the delegated administrator role full management privileges to the Users role. 7. Click Save Changes. Related Documentation About Delegating Administrator Roles on page 79 Defining Security Administrator Privileges on page 84 Defining Realm Management Privileges for an Administrative Role To define realm management privileges for an administrative role: 1. In the admin console, select Administrators > Admin Roles. 2. Select the administrator role to modify. 3. Select Users > Authentication Realms. 83

98 User Access Management Framework Feature Guide 4. Under Delegate user realms, select the option button for Administrator can manage ALL realms or Administrator can manage SELECTED realms. If you only want to allow the administrator role to manage selected user roles, select those roles in the Available realms list and click Add. 5. Specify which user role pages the delegated administrator can manage by selecting one of the following options: Write All Specifies that members of the administrator role can modify all user role pages. Custom Settings Allows you to choose administrator privileges (Deny, Read, or Write) for the individual user role pages. 6. Under Delegate as read-only roles, select the user authentication realms that you want to allow the administrator to view but not modify. NOTE: If you specify both write access and read-only access for an authentication realm page, the system grants the most permissive access. For example, if you select Administrators can manage ALL realms under Delegated user realms, and then select the Users role in the Delegate as read-only realms section, the system device allows the delegated administrator role full management privileges to the Users realm. 7. Click Save Changes. Related Documentation About Delegating Administrator Roles on page 79 Defining Security Administrator Privileges on page 84 Defining Security Administrator Privileges To define security administrator privileges: 1. In the admin console, select Administrators > Admin Roles > Select Role > Administrators. 2. Select the Manage ALL admin roles check box. 3. Select the Administrators tab. 4. To allow the security administrator to add and delete admin roles, select the Allow Add/Delete admin roles check box. This allows the security administrator the ability to create administrator roles, even if the security administrator is not part of the.administrators role. 5. To indicate the level of access to allow the security administrator role to set for system administrators for each major set of admin console pages (General, System tasks, Users, Administrators, and Resource Policies) choose one of the following options: 84

99 Chapter 9: Administrator Roles Deny All Specifies that members of the security administrator role cannot see or modify any settings in the category. Read All Specifies that members of the security administrator role can view, but not modify, all settings in the category. Write All Specifies that members of the security administrator role can modify all settings in the category. Custom Settings Allows you to pick and choose security administrator privileges (Deny, Read, or Write) for the individual features within the category. 6. Select the Manage ALL admin realms check box. 7. To allow the security administrator to add and delete admin realms, check the Allow Add/Delete admin realms check box. This allows the security administrator the ability to create and delete administrator realms, even if the security administrator is not part of the.administrators role. 8. To indicate the level of realm access to allow the security administrator role to set for system administrators for each major set of admin console pages (General, Authentication Policy, and Role Mapping,) choose one of the following options: Deny All Specifies that members of the security administrator role cannot see or modify any settings in the category. Read All Specifies that members of the security administrator role can view, but not modify, all settings in the category. Write All Specifies that members of the security administrator role can modify all settings in the category. Custom Settings Allows you to choose security administrator privileges (Deny, Read, or Write) for the individual features within the category. NOTE: All administrators that can manage admin roles and realms have at least read-only access to the admin role s Name and Description and to the realm's Name and Description, as displayed on the General page. 9. Click Save Changes. Related Documentation About Delegating Administrator Roles on page 79 Defining General System Administrator Role Settings This topic describes how to define role settings for the system administrator. It includes the following information: Defining Default Options for Administrator Roles on page 86 Managing General Role Settings and Options on page 86 Specifying Access Management Options for the Role on page 86 85

100 User Access Management Framework Feature Guide Defining Default Options for Administrator Roles To define the default options for all delegated administrator roles: 1. In the admin console, select Administrators > Admin Roles. 2. Click Default Options. 3. Modify settings in the Session Options and UI Options. These become the new defaults for all new delegated administrator roles. Managing General Role Settings and Options To manage general role settings and options: 1. In the admin console, select Administrators > Admin Roles > Select Role > General > Overview. 2. (Optional) Create a label for the delegated administrator role using the Name and Description fields. 3. Under Options, select one of the following: Session Options To apply the settings configured in the General > Session Options tab to the role. UI Options To apply the settings configured in the General > UI Options tab to the role. 4. Click Save Changes to apply the settings to the role. Specifying Access Management Options for the Role Use the Administrators > Admin Roles> General > Restrictions tab to specify access management options for the role. The IC Series device does not map administrators to this role unless they meet the specified restrictions. To specify access management options for the role: 1. In the admin console, select Administrators > Admin Roles> Select Role > General> Restrictions. 2. Click the tab for the option you want to configure for the role. Then configure in accordance with role configuration procedures. 3. Click Save Changes. Related Documentation About Delegating Administrator Roles on page 79 Specifying Management Tasks to Delegate on page 81 Defining Security Administrator Privileges on page 84 86

101 CHAPTER 10 Guest User Account Management Configuring a Guest User Account Management Role on page 87 Configuring a Guest User Account Management Role In some businesses, you might want to delegate responsibility for temporary or guest users to a guest user access manager (GUAM) who can use the local authentication server to provision accounts for guests. To delegate guest user account management administration rights to a user: 1. In the admin console, select Users > User Roles > Role. 2. Select the Enable Guest User Account Management Rights check box for the role. 3. Save the configuration. Users who are assigned to the role can provision guest accounts. To revoke a user s guest user account management rights, clear the check box on the role page, or use role-mapping rules to deny access to the role for a specific user. Related Documentation Configuring General Role Options on page 23 Using the Local Authentication Server Enterprise Guest User Access Feature Guide 87

102 User Access Management Framework Feature Guide 88

103 CHAPTER 11 Guest User Accounts Setting Up for Guest User Accounts on page 89 Setting Up for Guest User Accounts There is a guest box on the create and edit account pages into which the guest user access manager can enter guest addresses. After guest user accounts are created, the authentication credentials can be ed to the guest, eliminating the need to print the credentials. Though the field is always present, this feature is only available if you enable from the admin console. You can send plain text or html s. To enable the guest access accounts: 1. In the admin console, select Configuration > Guest Access. 2. Select the Enabled check box after account details. 3. Enter the hostname or IP address of your SMTP server. 4. (Optional) Enter the SMTP login credentials if the server requires credentials. 5. (Optional) Enter the SMTP password if the server requires credentials. 6. Enter the default address that should be used to send s and receive bounce-back messages. 7. Enter the subject to use in the header. 8. Select the html or text option button. The default is html. 9. Click Save Changes. To create optional custom HTML pages: a. In the admin console, select Signing In > Sign-in Pages. b. Click Upload Custom Pages. c. Under Sample Template Files, select Sample. d. At the prompt, select Open. e. Open the file guest-user- -page.thtml. 89

104 User Access Management Framework Feature Guide f. Edit the file to your specifications. NOTE: To send just the username and password in the , use the following in the template: <% I18N_USERNAME_COLON %> <% login %> <% I18N_PASSWORD_COLON %> <% passwd %> g. Save the file and then upload the zipped package with a meaningful name, for example GUAM. h. In the admin console, select Signing In > Sign-in Policies. i. Open the sign in policy that will be used by the guest user access manager, or create a new sign-in policy for the guest user access manager. j. After Sign-in page, select the zipped file that you created. k. Click Save Changes. Related Documentation Configuring Sign-In Pages on page 66 90

105 CHAPTER 12 Custom Expression in Rules and Policies Using Custom Expressions in Rule Configuration on page 91 Using Custom Expressions in Rule Configuration This topic describes custom expressions. It is intended for advanced users. It includes the following information: Custom Expressions on page 91 Custom Expression Elements on page 92 Wildcard Matching on page 95 Using Multi-Valued Attributes on page 95 Specifying Multivalued Attributes in a Bookmark Name on page 96 Distinguished Name Variables on page 97 System Variables on page 97 Custom Variables and Macros on page 106 Specifying Fetch Attributes in a Realm on page 109 Specifying the homedirectory Attribute for LDAP on page 110 Custom Expressions Many system rules, such as role mapping rules or resource policy rules, support custom expressions. A custom expression is a combination of variables that the system evaluates as a Boolean object. The expression returns true, false, or error. You can write custom expressions in the following formats. Note that elements of these formats are described in greater detail in the table that follows: variable comparisonoperator variable variable comparisonoperator simplevalue variable comparisonoperator (simplevalue) variable comparisonoperator (OR Values) variable comparisonoperator (AND Values) variable comparisonoperator (time TO time) 91

106 User Access Management Framework Feature Guide variable comparisonoperator (day TO day) isemtpy (variable) isunknown (variable) (customexpr) NOT customexpr! customexpr customexpr OR customexpr customexpr customexpr customexpr AND customexpr customexpr && customexpr Custom Expression Elements Table 4: Custom Expression Elements Element Description variable Represents a system variable. A variable name is a dot-separated string, and each component can contain characters from the set [a-z A-Z 0-9_ ] but cannot start with a digit [0-9]. Variable names are case-insensitive. For system variables that you may use in role mapping rules and resource policies. When writing a custom expression in a log query field, you need to use system log variables. These variables are described in the Filter Variables Dictionary on the Filter page (System > Log/Monitoring > Events User Access Admin Access > Filters > Select Filter tab). Quoting syntax for variables: The system supports a quoting syntax for custom expression variables that allows you to use any character except '.' (period) in a user attribute name. To escape characters in an attribute name, quote some or all of the variable name using { } (curly-braces). For example, these expressions are equivalent: userattr.{login-name} = 'xyz' userattr.login{-}name = 'xyz' {userattr.login-name} = 'xyz' usera{ttr.l}{ogin-}name = 'xyz' Escape characters supported within quotes: \\ Escape a backslash (\). \{ Escape a left curly brace ({). \} Escape a right curly brace (}). \hh Escape a hexadecimal value where hh is two characters from [0-9A-Fa-f]. Examples: userattr.{tree Frog} = 'kermit' userattr.{tree\20frog} = 'kermit' 92

107 Chapter 12: Custom Expression in Rules and Policies Table 4: Custom Expression Elements (continued) Element Description Notes: There is no limit to the number of quotes you can use in a variable name. You can use the quoting syntax with any variable, not just userattr.* variables. You need to use curly-brace quotes only when writing custom expressions. comparisonoperator One of the following: = Equal to. Use with strings, numbers, and DNs.!= Not equal to. Use with strings, numbers, and DNs. < Less than. Use with numbers. <= Less than or equal to. Use with numbers. > Greater than. Use with numbers. >= Greater than or equal to. Use with numbers. simplevalue One of the following: string quoted string that may contain wildcards. IP Address a.b.c.d subnet a.b.c.d/subnetbitcount or a.b.c.d/netmask number Positive or negative integer day SUN MON TUE WED THU FRI SAT Notes about strings: A string may contain all characters except <nl> (newline) and <cr> (carriage return). Strings can be any length. String comparisons are case-insensitive. Strings can be quoted with single- or double-quotes. A quoted string may contain wildcards, including star(*), question mark (?), and square brackets ([ ]). variable comparisonoperator variable comparisons are evaluated without wildcard matching. Use a backslash to escape these characters: single-quote (') \' double-quote (") \" backslash (\) \\ hexadecimal \hh [0-9a-fA-F] Note about day: Day and time comparisons are evaluated in the system s time zone. Day range (day TO day) calculations start with the first day and step forward until the second day is reached. In time range (time TO time) calculations, the first value must be earlier than the second value. Only time variables can be compared to day and time values. The time variables are: time.* and logintime.*. 93

108 User Access Management Framework Feature Guide Table 4: Custom Expression Elements (continued) Element Description time Time of day in one of the following formats: HH:MM 24-hour HH:MMam 12-hour HH:MMpm 12-hour H:MM 24-hour H:MMam 12-hour H:MMpm 12-hour Day and time comparisons are evaluated in the Secure Access Service time zone. Day range (day TO day) calculations start with the first day and step forward until the second day is reached. In time range (time TO time) calculations, the first value must be earlier than the second value. Only time variables can be compared to day and time values. The time variables are: time.* and logintime.*. OR Value String containing one or more OR comparisons: Examples: variable comparisonoperator (number OR number...) variable comparisonoperator (string OR string...) AND Value String containing one or more AND comparisons. Examples: variable comparisonoperator (number AND number...) variable comparisonoperator (string AND string...) isempty Function that takes a single variable name (variable) argument and returns a boolean value. isempty() is true if the variable is unknown or has a zero-length value, zero-length strings, and empty lists. Example: isempty(userattr.terminationdate) isunknown Function that takes a single variable name (variable) argument and returns a boolean value. isunknown() is true if the variable is not defined. User attributes (userattr.* variables) are unknown if the attribute is not defined in LDAP or if the attribute lookup failed (such as if the LDAP server is down). Example: isunknown(userattr.bonusprogram) NOT,! Logical negation comparisonoperator. The negated expression evaluates to true if the customexpr is false and evaluates to false if the customexpr is true. The operators NOT, AND, and OR are evaluated from highest to lowest precedence in this order: NOT (from right), AND (from left), OR (from left). OR, Logical operator OR or, which are equivalent. The operators NOT, AND, and OR are evaluated from highest to lowest precedence in this order: NOT (from right), AND (from left), OR (from left). 94

109 Chapter 12: Custom Expression in Rules and Policies Table 4: Custom Expression Elements (continued) Element Description AND, && Logical AND or &&, which are equivalent. The operators NOT, AND, and OR are evaluated from highest to lowest precedence in this order: NOT (from right), AND (from left), OR (from left). customexpr Expression written in the Custom Expression Syntax (see above). Wildcard Matching In a quoted string, supported wildcards include: star (*) A star matches any sequence of zero or more characters. question mark (?) A question mark matches any single character. square brackets ([ ]) Square brackets match one character from a range of possible characters specified between the brackets. Two characters separated by a dash (-) match the two characters in the specified range and the lexically intervening characters. For example, dept[0-9] matches strings "dept0", "dept1", and up to "dept9". To escape wildcard characters, place them inside square brackets. For example, the expression ' userattr.x = " value [*]" ' evaluates to true if attribute x is exactly "value*". Using Multi-Valued Attributes Multi-valued attributes attributes that contain two or more values provide you with a convenient method for defining resources that expand into multiple individual bookmarks on the users bookmarks page. For example, assume that the user s LDAP directory contains the multi-valued attribute HomeShares: \\Srv1\Sales;\\Srv2\Marketing. When you configure the Windows File share resource definition using the HomeShares multi-valued attribute, \\<userattr.homeshares>, the user sees two bookmarks: \\Srv1\Sales \\Srv2\Marketing Now let s assume the user s LDAP directory contains a second multi-valued attribute defined as HomeFolders: Folder1;Folder2;Folder3. When you configure the Windows File share resource using both of the multi-valued attributes, \\<userattr.homeshares>\<userattr.homefolders>, the user sees the following six bookmarks: \\Srv1\Sales\Folder1 \\Srv1\Sales\Folder2 \\Srv1\Sales\Folder3 \\Srv2\Marketing\Folder1 95

110 User Access Management Framework Feature Guide \\Srv2\Marketing\Folder2 \\Srv2\Marketing\Folder3 The only exception to this functionality is when the variable includes an explicit separator string. In this case, only one bookmark containing multiple resources displays on the users bookmark page. You specify the separator string in the variable definition using the syntax sep= string where string equals the separator you want to use. For example, to specify a semi-colon as the separator, use the syntax <variable.attr sep=';'>. Use the following syntax for multi-valued attributes handling. Note that <variable> refers to a session variable such as <userattr.name> or <CertAttr.name>: <variable[index]> You specify indexes in a variety of ways. If, for example, the total number of values for a given index is 5, and you want to specify the entire range of values you use <variable[all]>. If you want to specify only the fourth value, you use <variable[4]>. <variable> is the same as <variable[all]>. <variable> is the same as <variable[all]>. <variable sep='str'> and <variable[all] sep='str'> These variable definitions always refer to a single string value with all the tokens expanded out with separator strings between the values. NOTE: Variable names cannot contain spaces. Specifying Multivalued Attributes in a Bookmark Name Another common case of using multivalued attributes occurs when you include a variable in a bookmark name and in a URL or file server/share field. For example, again assume that the user s LDAP directory contains the multi-valued attribute HomeShares: \\Srv1\Sales;\\Srv2\Marketing. When you configure the Windows File share resource definition using the HomeShares multi-valued attribute, \\<userattr.homeshares>, and you use the same attribute in the bookmark name field, <userattr.homeshares>, the system creates two bookmarks: Srv1\Sales bookmark pointing to \\Srv1\Sales Srv2\Marketing bookmark pointing to \\Srv2\Marketing This does not create a situation in which you end up with the following set of conditions: Srv1\Sales bookmark pointing to \\Srv1\Sales Srv1\Marketing bookmark pointing to \\Srv1\Marketing (error) Srv2\Sales bookmark pointing to \\Srv1\Sales (error) Srv2\Marketing bookmark pointing to \\Srv2\Marketing 96

111 Chapter 12: Custom Expression in Rules and Policies Distinguished Name Variables You can compare a distinguished name (DN) to another DN or to a string, but the system ignores wildcards, white space, and case. Note, however, that the system takes the order of DN keys into consideration. When the system compares an expression to a DN to a string, it converts the string to a distinguished name before evaluating the expression. If the system cannot convert the string due to bad syntax, the comparison fails. The DN variables are: userdn certdn certissuerdn The system also supports DN suffix comparisons using the matchdnsuffix function. For example: matchdnsuffix( certdn, "dc=danastreet,dc=net") Within the parenthesis, the first parameter is the full DN and the second is the suffix DN. You can use a variable or string for each parameter. Note that this first parameter should have more keys than the second (suffix parameter). Otherwise, if they are equal, it is the same as <firstparam> = <secondparam>. If the second parameter has more keys, matchdnsuffix returns false. System Variables The following table lists and defines system variables, gives an example for each system variable, and provides a guide as to where you may use system variables. Table 5: System Variables and Examples Variable Description Usage Examples authmethod Type of authentication method used to authenticates a user. role mapping rules, resource policy rules authmethod = ACE Server cachecleanerstatus The status of Cache Cleaner. Possible values: cachecleanerstatus = 1 cachecleanerstatus = if it is running 0 - if otherwise 97

112 User Access Management Framework Feature Guide Table 5: System Variables and Examples (continued) Variable Description Usage Examples certattr.<cert-attr> Attributes from a client-side certificate. Examples of certattr attributes include: role mapping rules resource policy rules SSO parameter fields certattr.ou = 'Retail Products Group' C - country LDAP configuration CN - common name description - description address - address GN - given name initials - initials L - locality name O - organization OU - organizational unit SN - surname serialnumber- serial number ST - state or province title - title UI - unique identifier Use this variable to check that the user s client has a client-side certificate with the value(s) specified. certattr.altname.<alt-attr> Subject alternative name value from a client-side certificate where <Alt-attr> may be: role mapping rules resource policy rules SSO parameter fields LDAP configuration certattr.altname. = "[email protected]" certattr.altname.ipaddress = ld Domain DNS registeredid ipaddress UPN UPNid UPNDomain fascn fascnac fascnsc fascncn fascncs fascnici fascnpi fascnoc fascnoi fascnpoa fascnlrc 98

113 Chapter 12: Custom Expression in Rules and Policies Table 5: System Variables and Examples (continued) Variable Description Usage Examples certattr.serialnumber Client certificate serial number. Note that all characters other than [0-9 a-f A-F] are stripped out of a string before comparison with certattr.sn. Wildcards are not supported. role mapping rules resource policy rules SSO parameter fields LDAP configuration certattr.serialnumber = userattr.certserial certattr.serialnumber = "6f:05:45:ab" certdn Client certificate subject DN. Wildcards are not permitted. role mapping rules, resource policy rules certdn = 'cn=john Harding,ou=eng,c=Company' certdn = userdn (match the certificate subject DN with the LDAP user DN) certdn = userattr.x509subjectname certdn = ('cn=john Harding,ou=eng,c=Company' or 'cn=julia Yount,ou=eng,c=Company') certdn.<subject-attr> Any variable from the client certificate subject DN, where subject-attr is the name of the RDN key. role mapping rules resource policy rules SSO parameter fields certdn.ou = 'company' certdn.e = '[email protected]' certdn.st = 'CA' Use to test the various subject DN attributes in a standard x.509 certificate. LDAP configuration certdntext Client certificate user DN stored as a string. Only string comparisons to this value are allowed. role mapping rules resource policy rules SSO parameter fields certdntext = 'cn=john Harding,ou=eng,c=Company' certissuerdn Client certificate-issuer subject DN. This variable works like a standard DN attribute such as CertDN. Wildcards are not permitted. role mapping rules resource policy rules SSO parameter fields certissuerdn = 'cn=john Harding,ou=eng,c=Company' certissuerdn = userattr.x509issuer certissuerdn = ('ou=eng,c=company' or 'ou=operations,c=company') certissuerdn.<issuer-attr> Any variable from the client certificate-issuer subject DN, where issuer-attr is the name of the RDN key. role mapping rules resource policy rules SSO parameter fields certissuerdn.ou = 'company' certissuerdn.st = 'CA' certissuerdntext Client certificate-issuer subject DN stored as a string. Only string comparisons to this value are allowed. role mapping rules resource policy rules SSO parameter fields certissuerdntext = 'cn=john Harding,ou=eng,c=Company' 99

114 User Access Management Framework Feature Guide Table 5: System Variables and Examples (continued) Variable Description Usage Examples defaultntdomain Contains the Domain value set in the authentication server configuration when you use AD/NT authentication. role mapping rules resource policy rules SSO parameter fields defaultntdomain= CORP group.<group-name> User s group membership as provided by the realm authentication or directory server. role mapping rules resource policy rules Only those groups evaluated for role mapping rules are available in the detailed rules (conditions) in the resource policies. We recommend that you use the groups variable instead of group.<group-name>, which is supported only for backwards compatibility. group.preferredpartner group.goldpartner or group.silverpartner group.employees and time.month = 9 Combination examples: Allow all partners with active status from Monday to Friday but preferred partners Monday through Saturday: ((group.partners and time = (Mon to Fri)) or (group.preferredpartners and time = (Mon to Sat))) and userattr.partnerstatus = 'active' NOTE: Spaces are not supported, such as, group.sales managers groups List of groups as provided by the realm authentication or directory server. role mapping rules resource policy rules SSO parameter fields groups=('sales managers') NOTE: You can enter any characters in the groupname, although wildcard characters are not supported. hostcheckerpolicy Host Checker polices that the client has met. role mapping rules resource policy rules SSO parameter fields hostcheckerpolicy = ('Norton' and 'Sygate') and cachecleanerstatus = 1hostCheckerPolicy = ('Norton' and 'Sygate') loginhost Host name or IP address that the browser uses to contact the Junos Pulse service. role mapping rules resource policy rules SSO parameter fields loginhost = LDAP configuration logintime The time of day at which the user submits his credentials. The time is based on system time. role mapping rules resource policy rules SSO parameter fields logintime = (8:00am) logintime= (Mon to Fri) NOTE: When using this variable in an SSO parameter field, the variable returns the UNIX string time. 100

115 Chapter 12: Custom Expression in Rules and Policies Table 5: System Variables and Examples (continued) Variable Description Usage Examples logintime.day The day of month on which the user submits his credentials, where day is The time is based on the system time. role mapping rules resource policy rules logintime.day = 3 You cannot use the TO operator with this variable. logintime.dayofweek The day of the week on which the user submits his credentials, where dayofweek is in the range [0-6] where 0 = Sunday. role mapping rules resource policy rules logintime.dayofweek = (0 OR 6) logintime.dayofweek = (mon TO fri) The system does not support the TO operator with time.dayofweek expressions if you use numbers instead of strings. In other words, logintime.dayofweek = (2 TO 6) does not work, but logintime.dayofweek = (mon to fri) does work. logintime.dayofweek = (1) logintime.dayofweek = 5 logintime.dayofyear The numeric day of the year on which the user submits his credentials, where dayofyear can be set to [0-365]. role mapping rules resource policy rules logintime.dayofyear = 100 You cannot use the TO operator with this variable. logintime.month The month in which the user submits his credentials, where month can be set to [1-12] where 1 = January. role mapping rules resource policy rules logintime.month >= 4 AND logintime.month <=9 You cannot use the TO operator with this variable. logintime.year The year in which the user submits his credentials, where year can be set to [ ]. role mapping rules resource policy rules logintime.year = 2005 You cannot use the TO operator with this variable. loginurl URL of the page that the user accessed to sign in. The system gets this value from the Administrator URLs User URLs column on the Authentication > Signing In > Sign-in Policiespage of the admin console. role mapping rules resource policy rules SSO parameter fields LDAP configuration loginurl = */admin 101

116 User Access Management Framework Feature Guide Table 5: System Variables and Examples (continued) Variable Description Usage Examples networkif The network interface on which the user request is received. Possible values: internal, external role mapping rules resource policy rules SSO parameter fields sourceip = /24 and networkif = internal ntdomain The NetBIOS NT domain used in NT4 and Active Directory authentication. role mapping rules SSO parameter fields ntdomain = jnpr ntuser The NT username used in Active Directory authentication role mapping rules SSO parameter fields ntuser = jdoe password password[1] password[2] The password entered by the user for the primary authentication server (password and password[1]) or the secondary authentication server (password[2]). role mapping rules resource policy rules SSO parameter fields password = A1defo2z realm The name of the authentication realm to which the user is signed in. role mapping rules resource policy rules Realm = ('GoldPartners' or 'SilverPartners') SSO parameter fields NOTE: AND condition will always fail as a user is only allowed to sign in to a single realm in a session. role List of all the user roles for the session. resource policy rules SSO parameter fields Role = ('sales' or 'engineering') Role = ('Sales' AND 'Support') In SSO, if you want to send all the roles to back-end applications, use <role sep = ";"> - where sep is the separator string for multiple values. The system supports all separators except and >. sourceip The IP address of the machine on which the user authenticates. You can specify the netmask using the bit number or in the netmask format: ' '. Note that you can evaluate the sourceip expression against a string variable such as an LDAP attribute. role mapping rules resource policy rules SSO parameter fields sourceip = sourceip = /24 and networkif internal userattr.dept = ('eng' or 'it') and sourceip = /16 sourceip = /24 (Class C) is the same as: sourceip = / sourceip=userattr.sourceip 102

117 Chapter 12: Custom Expression in Rules and Policies Table 5: System Variables and Examples (continued) Variable Description Usage Examples time The time of day at which the role mapping rule or resource policy rule is evaluated. The time of the day can be in 12-hour or 24-hour format. role mapping rules resource policy rules time = (9:00am to 5:00pm) time = (09:00 to 17:00) time = (Mon to Fri) Combination examples: Allow executive managers and their assistants access from Monday to Friday: userattr.employeetype = ('*manager*' or '*assistant*') and group.executivestaff and time = (Mon to Fri) time.day The day of month on which the user submits his credentials to, where day is The time is based on the system time. role mapping rules resource policy rules logintime.day = 3 time.dayofweek The day of the week on which the role mapping rule or resource policy rule is evaluated, where dayofweek is in the range [0-6] where 0 = Sunday. role mapping rules resource policy rules logintime.dayofweek = (0 OR 6) logintime.dayofweek = (1 to 5) logintime.dayofweek = 5 time.dayofyear The day of the year on which the role mapping rule or resource policy rule is evaluated. Possible values include: role mapping rules resource policy rules time.dayofyear = 100 time.month The month in which the role mapping rule or resource policy rule is evaluated. Possible values include: 1-12 role mapping rules resource policy rules time.month >= 9 and time.month <= 12 and time.year = 2004 group.employees and time.month = 9 time.year The year in which the role mapping rule or resource policy rule is evaluated, where year can be set to [ ]. role mapping rules resource policy rules time.year =

118 User Access Management Framework Feature Guide Table 5: System Variables and Examples (continued) Variable Description Usage Examples user Junos Pulse username for the user s primary authentication server (user and user@primary_auth_server_name) or secondary authentication server (user@secondary_auth_server_name). Use when authenticating against an Active Directory server, domain and username. role mapping rules resource policy rules SSO parameter fields user = 'steve' user = 'domain\\steve' primary_auth_server_name is the name of the primary auth server. If there are spaces or special characters in the name, it can be enclosed in curly brackets. For example user@{my Primary Auth Server} secondary_auth_server_name is the name of the secondary auth server. If there are spaces or special characters in the name, it can be enclosed in curly brackets. For example user@{my Secondary Auth Server} NOTE: When including a domain as part of a username, you must include two slashes between the domain and user. For example: user= yourcompany.net\\joeuser. username username@primary_auth_server_name username@secondary_auth_server_ name Junos Pulse system username for the user s primary authentication server (username and username@primary_auth_server_name) or secondary authentication server (username@secondary_auth_server_name). If the user is signing in to a certificate authentication server, then the user s Junos Pulse system username is the same as CertDN.cn. role mapping rules resource policy rules SSO parameter fields username = 'steve' and time = mon username = 'steve' username = 'steve*' username = ('steve' or '*jankowski') primary_auth_server_name is the name of the primary auth server. If there are spaces or special characters in the name, it can be enclosed in curly brackets. For example user@{my Primary Auth Server} secondary_auth_server_name is the name of the secondary auth server. If there are spaces or special characters in the name, it can be enclosed in curly brackets. For example user@{my Secondary Auth Server} 104

119 Chapter 12: Custom Expression in Rules and Policies Table 5: System Variables and Examples (continued) Variable Description Usage Examples useragent The browser s user agent string. role mapping rules The browser s user agent string. resource policy rules SSO parameter fields userattr.<auth-attr> User attributes retrieved from an LDAP, RADIUS, or SiteMinder authentication or directory server. role mapping rules resource policy rules SSO parameter fields userattr.building = ('HQ*' or 'MtView[1-3]') userattr.dept = ('sales' and 'eng') userattr.dept = ('eng' or 'it' or 'custsupport') userattr.division = 'sales' userattr.employeetype!= 'contractor' userattr.salarygrade > 10 userattr.salesconfirmed >= userattr.salesquota Negative examples: userattr.company!= "Acme Inc" or not group.contractors not (user = 'guest' or group.demo) Combination examples: Allow executive managers and their assistants access from Monday to Friday: userattr.employeetype = ('*manager*' or '*assistant*') and group.executivestaff and time = (Mon to Fri) Allow all partners with active status from Monday to Friday but preferred partners Monday through Saturday: ((group.partners and time = (Mon to Fri)) or (group.preferredpartners and time = (Mon to Sat))) and userattr.partnerstatus = 'active' 105

120 User Access Management Framework Feature Guide Table 5: System Variables and Examples (continued) Variable Description Usage Examples userdn The user DN from an LDAP server. If the user is authenticated by the LDAP server, then this DN is from the authentication server; otherwise, the DN comes from the realm's Directory/Attribute server. Wildcards are not permitted. role mapping rules resource policy rules userdn = 'cn=john Harding,ou=eng,c=Company' userdn = certdn userdn.<user-attr> Any variable from the user DN, where user-attr is the name of the RDN key. role mapping rules resource policy rules SSO parameter fields Any variable from the user DN, where user-attr is the name of the RDN key. userdntext User DN stored as a string. Only string comparisons to this value are allowed. role mapping rules resource policy rules userdntext = 'cn=john Harding,ou=eng,c=Company' SSO parameter fields Custom Variables and Macros Custom variables, like system variables, are name-value pair tags that you can use when defining role mapping rules, resource policy rules and SSO parameter fields. Custom variables are created in the Server Catalog (for example, Authentication > Auth Server > Name > Settings) by using a pre-defined macro on a system variable. Available macros are: REGMATCH Matches a regular expression pattern against a string text. APPEND Appends a text string to another text string. DAYSDIFF Calculates the difference between two dates. NOTE: These macros are located under Variable Operators in the Variables tab of the Server Catalog window. A custom variable name is a dot-separated string. Each component can contain characters from the set [a-z A-Z 0-9 _] but cannot start with a digit [0-9]. Custom variable names are case-insensitive. Custom variables are referenced as customvar.<variablename>. For example, if you create a custom variable with the name check-prefix, you reference this custom variable as customvar.check-prefix. 106

121 Chapter 12: Custom Expression in Rules and Policies append Syntax APPEND (attr, TextString) APPEND (attr, attr2) Description Append a text string to an attribute or append an attribute to another attribute and store the resulting string in the custom variable. Options attr System variable of type string. TextString Quoted ASCII string. attr2 System variable of type string. Output Fields Returns a String value. If no match is found, returns an empty string. If the system variable is multivalued, the custom variable is also multi-valued and uses the same order as the system variable. Sample Output APPEND ) In this example, the is appended to the username value. 107

122 User Access Management Framework Feature Guide daysdiff Syntax DAYSDIFF (attr, timeformat) Description Calculates the number of days between the attribute and the current time. Options attr System variable of type string. timeformat Output time format. Valid values are: UTC, TIMET, MMDDYYYY Output Fields Returns an Integer value. Sample Output DAYSDIFF ( certattr.validupto, UTC) In this example, calculate the difference in days between the current time and the value of certattr.validupto and express the time in UTC (Coordinated Universal Time). 108

123 Chapter 12: Custom Expression in Rules and Policies regmatch Syntax REGMATCH (attr, regex, groupingnumber) Description Match the regular expression pattern against an attribute and store the result in the custom variable. Options attr System variable of type string. regex Quoted string containing the regular expression to be applied to the attr option. groupingnumber The group value to assign to the custom variable. Additional Information The regular expression supports the Perl Compatible Regular Expressions (PCRE) syntax. A grouping (capture buffer) in the regex pattern can also be used to define a custom variable. Output Fields Returns a String value. If no match is found, returns an empty string. If the system variable is multivalued, the custom variable is also multi-valued and uses the same order as the system variable. Sample Output REGMATCH (mailid, ^(.*)@juniper.net$, 1) In this example, a mailid of [email protected] creates a custom variable with value myname. Specifying Fetch Attributes in a Realm To facilitate the support for various parameterized settings in user roles and resource policies, you have the ability to specify additional fetch attributes. The system stores the fetch attributes when users log in so that you can use them in parameterized role or resource policy definitions. The system pulls all the attributes that are currently stored in the Sever Catalog for the user's authentication or authorization LDAP server. So, make sure to add the LDAP user attributes that are used in role or resource policy definitions in the LDAP Server Catalog first. When a user logs in, the system retrieves user attributes that are referenced in the role mapping rules plus all of the additional attributes referenced in the Server Catalog and stores all these values. Note that this should not incur a significant performance overhead because all the user attributes are retrieved in one single LDAP query. 109

124 User Access Management Framework Feature Guide NOTE: When you substitute variables, such as in IP/Netmasks or host names, the values in the session are appropriately converted into the data type that is required by the particular application definition. Specifying the homedirectory Attribute for LDAP You can create a bookmark that automatically maps to a user s LDAP home directory. You can accomplish this using the LDAP attribute homedirectory. You need to configure a realm that specifies the LDAP server instance as its auth server, and you need to configure role-mapping rules and a bookmark that points to the LDAP homedirectory attribute. Related Documentation User Access Management Framework Feature Guide User Access Management Framework Feature Guide 110