Junos Pulse Access Control Service

(1)

Junos Pulse Access Control Service

User Access Management Framework Feature

Guide

Release

5.0

(2)

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

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 2038. However, the NTP application is known to have some difficulty in the year 2036.

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

(3)

List of Figures

Part 1 Overview

Chapter 1 Access Management Framework . . . 3

Figure 1: Access Management Sequence for Realm and Role Restrictions . . . 6

Figure 2: IC Series Authenticates User Against Realm and Primary Server . . . 7

Figure 3: IC Series Authorizes User . . . 8

Figure 4: IC Series Maps User to One or More User Roles and Pushes Policies . . . . 8

Figure 5: OAC and Infranet Enforcer Evaluate Policies Based on User Roles . . . 9

Figure 6: Infranet Enforcer Allows or Denies Access Based on Policy Match . . . 11

Chapter 2 Roles . . . 15

Figure 7: Security Checks Performed to Create a Session Role . . . 16

Part 2 Configuration

Figure 8: Adding an Attribute for LDAP in the Server Catalog . . . 49

Figure 9: Adding LDAP Groups . . . 50

Figure 10: Adding Active Directory Groups . . . 52

Chapter 7 Sign-In Policies . . . 55

Figure 11: Realm Selection, Phase 1 . . . 60

Chapter 8 Session Migration . . . 71

(8)

(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 . . . 55 Table 3: RADIUS Sub-Protocols and Compatible Authentication Servers . . . 58

Part 3 Administration

(10)

(11)

About the Documentation

• 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

Documentation and Release Notes

To obtain the most current version of all Juniper Networks®technical documentation, see the product documentation page on the Juniper Networks website at

http://www.juniper.net/techpubs/.

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 athttp://www.juniper.net/books.

Supported Platforms

For the features described in this document, the following platforms are supported:

• IC4500

• IC6500 FIPS

• IC6500

• MAG Series

Documentation Conventions

(12)

Table 1: Notice Icons

Description Meaning

Icon

Indicates important features or instructions. Informational note

Indicates a situation that might result in loss of data or hardware damage. Caution

Alerts you to the risk of personal injury or death. Warning

Alerts you to the risk of personal injury from a laser. Laser warning

Table 2 on page xiidefines the text and syntax conventions used in this guide.

Table 2: Text and Syntax Conventions

Examples Description

Convention

To enter configuration mode, type the configure command:

user@host> configure Represents text that you type.

Bold text like this

user@host> show chassis alarms No alarms currently active Represents output that appears on the

terminal screen. Fixed-width text like this

• A policy term is a named structure that defines match conditions and actions.

• Junos OS CLI User Guide

• RFC 1997, BGP Communities Attribute • Introduces or emphasizes important

new terms.

• Identifies guide names.

• Identifies RFC and Internet draft titles.

Italic text like this

Configure the machine’s domain name: [edit]

root@# set system domain-name

domain-name

Represents variables (options for which you substitute a value) in commands or configuration statements.

Italic text like this

• To configure a stub area, include the stubstatement at the[edit protocols ospf area area-id]hierarchy level. • The console port is labeledCONSOLE. Represents names of configuration

statements, commands, files, and directories; configuration hierarchy levels; or labels on routing platform

components. Text like this

stub <default-metric metric>; Encloses optional keywords or variables.

(13)

Table 2: Text and Syntax Conventions (continued)

Examples Description

Convention

broadcast | multicast

(string1 | string2 | string3) 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. | (pipe symbol)

rsvp { # Required for dynamic MPLS only Indicates a comment specified on the

same line as the configuration statement to which it applies.

# (pound sign)

community name members [ community-ids ]

Encloses a variable for which you can substitute one or more values. [ ] (square brackets) [edit] routing-options { static { route default { nexthop address; retain; } } } Identifies a level in the configuration

hierarchy. Indention and braces ( { } )

Identifies a leaf statement at a configuration hierarchy level. ; (semicolon)

GUI Conventions

• In the Logical Interfaces box, select All Interfaces.

• To cancel the configuration, click Cancel.

Represents graphical user interface (GUI) items you click or select.

Bold text like this

In the configuration editor hierarchy, select Protocols>Ospf.

Separates levels in a hierarchy of menu selections.

> (bold right angle bracket)

Documentation Feedback

We encourage you to provide feedback, comments, and suggestions so that we can improve the documentation. You can send your comments to

techpubs-comments@juniper.net, or fill out the documentation feedback form at

https://www.juniper.net/cgi-bin/docbugreport/. If you are using e-mail, 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,

(14)

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

http://www.juniper.net/us/en/local/pdf/resource-guides/7100059-en.pdf.

• Product warranties—For product warranty information, visit

http://www.juniper.net/support/warranty/.

• 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:http://www.juniper.net/customers/support/ • Search for known bugs:http://www2.juniper.net/kb/

• Find product documentation:http://www.juniper.net/techpubs/

• Find solutions and answer questions using our Knowledge Base:http://kb.juniper.net/ • Download the latest versions of software and review release notes:

http://www.juniper.net/customers/csc/software/

• Search technical bulletins for relevant hardware and software notifications:

https://www.juniper.net/alerts/

• Join and participate in the Juniper Networks Community Forum:

http://www.juniper.net/company/communities/

• Open a case online in the CSC Case Management tool:http://www.juniper.net/cm/

To verify service entitlement by product serial number, use our Serial Number Entitlement (SNE) Tool:https://tools.juniper.net/SerialNumberEntitlementSearch/

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 athttp://www.juniper.net/cm/. • Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico). For international or direct-dial options in countries without toll-free numbers, see

(15)

PART 1

Overview

• Access Management Framework on page 3

• Roles on page 15

(16)

(17)

CHAPTER 1

Access Management Framework

• 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

Access Management Overview

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.

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

(18)

• 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.

(19)

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 6shows the order in which the system evaluates realm and role

restrictions after a user submits credentials on a sign-in page.

(20)

Figure 1: Access Management Sequence for Realm and Role Restrictions

Understanding the Evaluation Process for Policies, Rules, Restrictions, and Conditions on page 6

•

• Understanding Session Migration on page 71

(21)

Figure 2: IC Series Authenticates User Against Realm and Primary Server

(22)

Figure 3: IC Series Authorizes User

(23)

Figure 5: OAC and Infranet Enforcer Evaluate Policies Based on User Roles

(24)

(25)

Figure 6: Infranet Enforcer Allows or Denies Access Based on Policy Match

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.

(26)

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.

(27)

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.

• Displaying Active Users

(28)

(29)

CHAPTER 2

Roles

• Understanding User Roles on page 15

Understanding User Roles

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

(30)

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.

(31)

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 5.

2. 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.

(32)

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.

• Specifying the Client that Endpoints Use for Access

• Understanding Realm and Role Restrictions on page 3

• Configuring General Role Options on page 23

(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.

Before Configuring a Realm on page 43 •

(34)

• 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.

• Understanding User Roles on page 15

(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

(36)

(37)

CHAPTER 4

Role Options

• Defining Default Options for User Roles on page 24

• Specifying Role Access Options on page 25

• Specifying Session Limits on page 27

• Specifying Session Options on page 29

• Specifying UI Options for Agentless Access on page 31

• Customizing User Realm UI Views on page 33

Configuring General Role Options

Use the Overview tab to edit a role name and description and to toggle session and user interface options on and off.

To manage general role settings and options:

1. In the admin console, select Users > User Roles > Role Name > General > Overview.

2. (Optional) Revise the name and description, and then click Save Changes.

3. Under Options, check the role-specific options to enable for the role. If you do not select role-specific options, the system uses the default settings. Role-specific options include:

• Session Options—To apply the role settings in the General > Session Options page to the role. This option is selected by default.

• UI Options—To apply the role settings in the General > UI Options page to agentless access roles. This option is selected by default.

• Odyssey Settings for IC Access—To specify OAC connection and authentication options. By Default, this option is not selected. Do not select this option if you want users to access protected resources with Pulse, the Java agent, or with agentless access.

(38)

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.

Specifying the Client that Endpoints Use for Access •

• Using Role Restrictions on page 37

• Specifying Session Options on page 29

• Defining Default Options for User Roles on page 24

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.

(39)

7. Select the Install Pulse option button. (Host Enforcer is not supported for Pulse).

• Using the Preconfigured Installer for OAC on Windows Endpoints

• Configuring the Pulse Client for a Role

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.

(40)

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

(41)

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.

• 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.

(42)

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.

Understanding the Evaluation Process for Policies, Rules, Restrictions, and Conditions on page 6

•

(43)

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.

(44)

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 Sessionbutton 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.

(45)

• 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.

Specifying Role Access Options on page 25 •

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:

(46)

• 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: , , , , 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: , , , , 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=”http://www.google.com” target=”_blank”>Google</a> displays the linked text “Google,” and the link opens in a new browser window.

(47)

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.

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.

(48)

(49)

CHAPTER 5

Realm/Role Restrictions

• 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

Using Source IP Access Restrictions

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 (10.64.4.100), or you can allow access to all other network users (0.0.0.0).

(50)

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.

(51)

• Specifying Password Access Restrictions on page 40

• Specifying Session Limits on page 27

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.

Using Source IP Access Restrictions on page 35 •

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

Junos Pulse Access Control Service