Pulse Policy Secure. Getting Started Guide. Product Release 5.1. Document Revision 1.0 Published:

Transcription

1 Pulse Policy Secure Getting Started Guide Product Release 5.1 Document Revision 1.0 Published: by Pulse Secure, LLC. All rights reserved

2 Pulse Secure, LLC 2700 Zanker Road, Suite 200 San Jose, CA by Pulse Secure, LLC. All rights reserved Pulse Secure and the Pulse Secure logo are trademarks of Pulse Secure, LLC in the United States. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners. Pulse Secure, LLC assumes no responsibility for any inaccuracies in this document. Pulse Secure, LLC reserves the right to change, modify, transfer, or otherwise revise this publication without notice. Pulse Policy Secure Getting Started Guide The information in this document is current as of the date on the title page. END USER LICENSE AGREEMENT The Pulse Secure product that is the subject of this technical documentation consists of (or is intended for use with) Pulse Secure 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. Revision History Changes for rebranding 2014 by Pulse Secure, LLC. All rights reserved

3 Table of Contents About the Documentation... xi Documentation and Release Notes... xi Supported Platforms... xi Documentation Conventions... xi Requesting Technical Support... xiv Self-Help Online Tools and Resources... xiv Opening a Case with PSGSC... xiv Part 1 Overview Chapter 1 Product Overview... 3 Understanding the Pulse Policy Secure Solution... 3 Pulse Policy Secure Solution Overview... 3 Pulse Policy Secure Components... 4 Pulse Policy Secure Solution in the Network... 5 How Pulse Policy Secure Determines User Access and Protects Resources... 7 Pulse Policy Secure Solution Configuration Overview... 7 Before You Configure Pulse Policy Secure... 8 Chapter 2 Deployment Overview Understanding Pulse Policy Secure Deployment Options Pulse Policy Secure Deployment Summary Understanding the Initial Pulse Policy Secure Deployment User Experience Chapter 3 Task Guidance Using Task Guidance Chapter 4 Network Settings Network Configuration Chapter 5 Host Checker Host Checker Chapter 6 RADIUS Pulse Secure Access Control Service 802.1X Overview Chapter 7 Junos Enforcer Introduction to the Junos Enforcer Using IPsec with the Junos Enforcer Chapter 8 ScreenOS Enforcer Introduction to the ScreenOS Enforcer by Pulse Secure, LLC. All rights reserved iii

4 Getting Started Guide Part 2 Installation Chapter 9 Client Install the Client and Test the Initial Configuration Install and Configure Odyssey Access Client or Pulse Policy Secure Part 3 Configuration Chapter 10 Access Control Service Configuring Pulse Policy Secure Solution Chapter 11 OAC Preconfigure Odyssey Access Client for Endpoint Download Chapter 12 Pulse Policy Secure Configure Pulse Policy Secure for Endpoint Download Chapter 13 Host Checker Policy Require a Process to Run on the Endpoint Chapter 14 RADIUS Configuring Location Group Policies Configuring RADIUS Client Policies Configuring RADIUS Attributes Chapter 15 Junos Enforcer Configuring the Pulse Policy Secure Device to Connect to the Junos Enforcer...51 Configuring a Security Policy for Source IP Enforcement Configuring IPsec on the Junos Enforcer Chapter 16 ScreenOS Enforcer Configuring the Access Control Service to Connect to the ScreenOS Enforcer Configuring IPsec Enforcement Part 4 Administration Chapter 17 User Authentication Set Up User Authentication on the Pulse Policy Secure Device Chapter 18 User Roles Set Up User Roles on the Pulse Policy Secure Device Set Up User Role Mapping on the Pulse Policy Secure Device Chapter 19 Sign-In Policy Create a Sign-In Policy Chapter 20 Certificates Validate the Pulse Policy Secure Device Certificate Setting Up and Using OpenSSL...70 Chapter 21 RADIUS Using RADIUS Attribute to Specify VLANs for Endpoints iv 2014 by Pulse Secure, LLC. All rights reserved

5 Table of Contents Chapter 22 Resource Access Policy Creating a Resource Access Policy Chapter 23 Junos Enforcer Setting Up the Interfaces and Security Zones on the Junos Enforcer Synchronizing the Time on the Junos Enforcer and the Pulse Policy Secure Device Setting Up Certificates for the Pulse Policy Secure Device and the Junos Enforcer Setting Up the Pulse Policy Secure Device on the Junos Enforcer Chapter 24 ScreenOS Enforcer Setting Up the Interfaces on ScreenOS Set the Time on the Pulse Policy Secure Device and ScreenOS Enforcer Setting Up Certificates for the Pulse Policy Secure Device and Infranet Enforcer Setting Up the Pulse Policy Secure Device Instance on the ScreenOS Enforcer Part 5 Troubleshooting Chapter 25 Device Connection Testing the Connection Chapter 26 Host Checker Policy Test the Host Checker Policy and Remediation by Pulse Secure, LLC. All rights reserved v

6 List of Figures Part 1 Overview Chapter 1 Product Overview... 3 Figure 1: 802.1X Layer 2 with the Infranet Enforcer... 6 Figure 2: Layer 3 with the Infranet Enforcer... 6 Figure 3: 802.1X Layer 2 without the Infranet Enforcer... 6 Chapter 6 RADIUS Figure 4: Using 802.1X Enforcement Chapter 7 Junos Enforcer Figure 5: Server Front End Scenario Chapter 8 ScreenOS Enforcer Figure 6: Server Front End Scenario Part 4 Administration Chapter 21 RADIUS Figure 7: Using a RADIUS Attributes Policy to Specify VLANs Chapter 23 Junos Enforcer Figure 8: Security Zones Part 5 Troubleshooting Chapter 26 Host Checker Policy Figure 9: Odyssey Access Client Remediation Instructions Display Figure 10: Odyssey Integrity Status Remediation Instructions Figure 11: Odyssey Access Client Connected by Pulse Secure, LLC. All rights reserved vii

7 List of Tables Part 1 About the Documentation... xi Table 1: Notice Icons... xii Table 2: Text and Syntax Conventions... xii Overview Chapter 1 Product Overview... 3 Table 3: Summary of Actions Required to Configure Pulse Policy Secure Solution. 8 Table 4: Configuration Topics... 9 Chapter 2 Deployment Overview Table 5: Scenarios and Methods of Deployment Chapter 4 Network Settings Part 4 Table 6: Pulse Policy Secure device Internal Network Interface Port Settings Administration Chapter 21 RADIUS Table 7: Pulse Policy Secure device network interface port settings by Pulse Secure, LLC. All rights reserved ix

8 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 xiv Documentation and Release Notes To obtain the latest version of Pulse Secure technical documentation, see the product documentation page at If the information in the latest release notes differs from the information in the documentation, follow the product Release Notes. Supported Platforms For the features described in this document, the following platforms are supported: IC4500 IC6500 FIPS IC6500 MAG Series xii 2014 by Pulse Secure, LLC. All rights reserved

9 Getting Started Guide Documentation Conventions Table 1 on page xii defines notice icons used in this 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. Tip Indicates helpful information. Best practice Alerts you to a recommended use or implementation. 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 Represents output that appears on the terminal screen. user@host> show chassis alarms No alarms currently active Italic text like this Introduces or emphasizes important new terms. Identifies guide names. Identifies RFC and Internet draft titles. 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 Represents variables (options for which you substitute a value) in commands or configuration statements. Configure the machine s domain name: [edit] root@# set system domain-name domain-name xii 2014 by Pulse Secure, LLC. All rights reserved

10 About the Documentation Table 2: Text and Syntax Conventions (continued) Convention Description Examples Text like this Represents names of configuration statements, commands, files, and directories; configuration hierarchy levels; or labels on routing platform components. 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>; (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 by Pulse Secure, LLC. All rights reserved xiii

11 Getting Started Guide Requesting Technical Support Technical product support is available through the Pulse Secure Global Support Center (PSGSC). If you are a customer with an active support contract, or are covered under warranty, and need post-sales technical support, you can access our tools and resources online or open a case with PSGSC. Product warranties For product warranty information, visit Self-Help Online Tools and Resources For quick and easy problem resolution, Pulse Secure has designed an online selfservice portal called the Pulse Secure Global Support Center (PSGSC) 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: 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 PSGSC You can open a case with PSGSC on the Web or by telephone. Use the Case Management tool in the CSC at Call (toll-free in the USA, Canada, and Mexico). For international or direct-dial options in countries without toll-free numbers, see xiv 2014 by Pulse Secure, LLC. All rights reserved

12 PART 1 Overview Product Overview on page 3 Deployment Overview on page 11 Task Guidance on page 15 Network Settings on page 17 Host Checker on page 19 RADIUS on page 21 Junos Enforcer on page 23 ScreenOS Enforcer on page by Pulse Secure, LLC. All rights reserved 1

13 CHAPTER 1 Product Overview Understanding the Pulse Policy Secure Solution on page 3 Pulse Policy Secure Solution Configuration Overview on page 7 Before You Configure Pulse Policy Secure on page 8 Understanding the Pulse Policy Secure Solution This topic provides an overview of the Pulse Policy Secure solution. It includes the following information: Pulse Policy Secure Solution Overview on page 3 Pulse Policy Secure Components on page 4 Pulse Policy Secure Solution in the Network on page 5 How Pulse Policy Secure Determines User Access and Protects Resources on page 7 Pulse Policy Secure Solution Overview The Pulse Policy Secure solution provides a mechanism for authenticating users and assessing the health of their host machines to control network access. Pulse Policy Secure solution coordinates network security compliance and provides the control required to support network applications, manage network use, and reduce threats from unauthorized users and compromised host machines attempting to access the network. You configure rules in Host Checker policies to specify the minimum criteria for the security compliance of host machines that are allowed to enter the network. The policies that you create control access for users, the client or agent that users access the network with, and the host machine or endpoint on which the clients run. Policy enforcement is through Juniper Networks firewalls (the ScreenOS Enforcer or the Junos Enforcer, collectively named Infranet Enforcers), 802.1X enabled switches, wireless access points, and/or packet filters configured on the endpoints. Additionally, you can deploy Juniper Networks Intrusion Detection and Prevention (IDP) as an enforcement point. Pulse Policy Secure solution can also provide access control for unmanageable devices like printers or IP phones using MAC address authentication by Pulse Secure, LLC. All rights reserved 2

14 Getting Started Guide Pulse Policy Secure Components Pulse Policy Secure solution consists of these Juniper Networks components: Pulse Policy Secure A central policy management server that validates the user s identity, determines the endpoint s security compliance, and manages network policies. Pulse Policy Secure pushes the policies to the endpoint and optionally, to the Infranet Enforcer. Pulse Policy Secure agent Pulse Policy Secure solution uses a Pulse Policy Secure agent to connect with endpoints. The Pulse Policy Secure agent is client software that runs on the endpoint and determines the endpoint s compliance to the enterprise security policies you specify. The Pulse Policy Secure agent communicates with Pulse Policy Secure to verify the endpoint s continued compliance with the policies using the built-in Host Checker. NOTE: You can also deploy Pulse Policy Secure solution to endpoints with a subset of features using a non-pulse Policy Secure agent such as a non-pulse Secure 802.1X supplicant. This overview focuses on using a Pulse Policy Secure agent. You can use the following Pulse Policy Secure agents: Odyssey Access Client (OAC) You can configure the system to automatically install OAC on supported Windows endpoints. You can manually install OAC on Macintosh endpoints. OAC includes built-in components (including Host Checker) to provide maximum protection and functionality. Pulse Policy Secure Pulse Policy Secure provides a single, dynamic, integrated multiservice client for Windows. Pulse is an intelligent, location-aware network access and acceleration client. Pulse delivers identity-enabled network security and access control, providing comprehensive endpoint security. Host Checker is integrated into Pulse. In addition to using the client with a Pulse Policy Secure deployment, Pulse supports the Pulse Connect Secure and Juniper Networks SRX Series devices as a dynamic virtual private network (VPN) client. Java agent For Linux endpoints, you can install a lightweight Java agent. With the Java agent, Host Checker is downloaded automatically to assess and monitor endpoint security. Host Checker (agentless) You can configure Pulse Policy Secure to automatically install Host Checker for agentless access deployments on Windows, Macintosh, and Linux or Solaris endpoint platforms. You use agentless access for endpoints onto which you do not want to download OAC, Pulse, or the Java agent. NOTE: In this guide and related documentation, the names OAC, Pulse, Java agent, and agentless Host Checker access refer to the specific type of Pulse Policy Secure agent by Pulse Secure, LLC. All rights reserved

15 Chapter 1: Product Overview Enforcement points Devices that dynamically enforce access policies for protected resources. You can control user access with Layer 2 or Layer 3 enforcement. The following types of devices can be used as Pulse Policy Secure enforcement points: Infranet Enforcer A Juniper Networks security device is an optional component that operates with Pulse Policy Secure to enforce access policies. You can use the ScreenOS Enforcer in Layer 2 and Layer 3 deployments. An SRX Series services gateway can be used in Layer 3 deployments. The Infranet Enforcer is deployed in front of servers and resources that you want to protect, and serves as a firewall to enforce the security policies that you configure to control access to protected resources X devices You can use IEEE 802.1X-enabled switches or access points with Pulse Policy Secure solution components to control access to the network using Layer 2 authentication. The 802.1X protocol provides port-based authenticated access to a LAN. This standard applies to both wireless and wired networks. In a wireless network, the 802.1X authentication occurs after the client has associated to an access point using an association method. Wired networks use the 802.1X standard without association. You can use 802.1X enabled switches or access points with or without the Infranet Enforcer as part of the solution. If you do not deploy the Infranet Enforcer, the 802.1X enabled switch or access point functions as the enforcement point. You can create different security zones by configuring VLANs on the network and assigning different roles to the appropriate VLAN. Pulse Policy Secure Solution in the Network Pulse Policy Secure solution is extremely flexible and offers numerous options for integration into your existing network. Figure 1 on page 6 illustrates a deployment using 802.1X with a switch or access point for Layer 2 connectivity. Figure illustrates a network deployment using Layer 3. These examples take advantage of the Infranet Enforcer to protect network resources. You can also deploy Pulse Policy Secure without the Infranet Enforcer by using VLANs to segregate unauthenticated or unauthorized traffic. Figure 3 on page 6 illustrates this kind of deployment by Pulse Secure, LLC. All rights reserved 4

16 Getting Started Guide Figure 1: 802.1X Layer 2 with the Infranet Enforcer Figure 2: Layer 3 with the Infranet Enforcer Figure 3: 802.1X Layer 2 without the Infranet Enforcer by Pulse Secure, LLC. All rights reserved

17 Chapter 1: Product Overview How Pulse Policy Secure Determines User Access and Protects Resources You create Pulse Policy Secure policies to control access to resources and services. Access is based on successful authentication, the user s assigned role, and the security compliance of the endpoint device. For example, you can provide full access to protected resources for an employee s role, and limited access for a contractor role. You can create Host Checker policies that require endpoints to meet security requirements. For example, you can require an endpoint to use a minimum version of an antivirus application with up-to-date antivirus definitions. If the endpoint does not meet the security requirements, you can configure the Host Checker policy to display instructions that tell the user how to bring the endpoint into compliance. After you populate the system with users, policies, and authentication services, you determine how users gain access to network resources. Pulse Policy Secure and Infranet Enforcer can work together to provide granular endpoint security and firewall services to control access to protected resources for qualified users. If you are using the Infranet Enforcer, Pulse Policy Secure pushes policies to the Infranet Enforcer when the two devices connect. Based on user identity and endpoint status, the system assigns the user a set of roles that specify which resources the user can access. The system pushes the set of roles associated with each endpoint s source IP address (called auth table entries) to the Infranet Enforcer. The Infranet Enforcer allows traffic between the endpoint and the protected resources based on resource access policies that you create. For 802.1X Layer 2 deployments in which you are not using the Infranet Enforcer, you can set up network VLANs and direct endpoints that do not meet security requirements to a quarantine VLAN. The user accesses a switch or access point to be authenticated through Pulse Policy Secure. The user's identity and the endpoint health assessment are used to determine which VLAN or other RADIUS attribute to use. The quarantine VLAN can limit access to remediation servers that provide users with instructions and the software they need for bringing their endpoint into compliance with security policies. Related Documentation Understanding Pulse Policy Secure Deployment Options on page 11 Pulse Policy Secure Solution Configuration Overview Table 3 on page 8 outlines the general steps for installing and configuring the Pulse Policy Secure solution. Variables to be considered depend on the specific network topology and the nature of your access control needs. Use this table as a general guide, and read the product documentation for complete information of all of the network access control options available with Pulse Policy Secure solution. Your access control needs are complex, and Pulse Policy Secure solution is versatile. Take the time to thoroughly understand the required actions by Pulse Secure, LLC. All rights reserved 6

18 Getting Started Guide Table 3: Summary of Actions Required to Configure Pulse Policy Secure Solution Action Required or Optional Install the hardware Required Upgrade and license the Pulse Policy Secure software Required Install the Infranet Enforcer Or use 802.1X Install Certificates Only with Infranet Enforcer Connect the Pulse Policy Secure and the Infranet Enforcer Only with Infranet Enforcer Configure authentication server(s) (or use the local server) Required Configure Roles and Realms Required Configure OAC or Pulse options Or third-party client Configure Infranet Enforcer Resource Access policies Only with Infranet Enforcer Configure IPsec and/or Source IP enforcement Only with Infranet Enforcer Configure Sign-in policies, add realms and authentication protocols Required Configure third-party agent Or OAC or Pulse Configure Host Enforcer policies Optional Configure Host Checker policies Required Configure 802.1X for Layer 2 access Or use Infranet Enforcer Related Documentation Configuring Pulse Policy Secure Solution on page 35 Deploying Pulse Policy Secure Solution to Users Pulse Policy Secure Deployment Summary on page 11 Before You Configure Pulse Policy Secure The following table summarizes the steps required to completely configure Pulse Policy Secure solution by Pulse Secure, LLC. All rights reserved

19 Chapter 1: Product Overview Table 4: Configuration Topics Topic Details Date and Time of the Infranet Enforcer and Pulse Policy Secure Be sure to set the date and time of the Infranet Enforcer to match the date set for Pulse Policy Secure. If possible, use a Network Time Protocol (NTP) server to set the date and time for both appliances. Kerberos If you configure the Pulse Policy Secure to use Active Directory for user authentication, Windows endpoint users can automatically sign in to the Pulse Policy Secure using the same credentials they use to access their Windows desktops. Non-Pulse Secure supplicants If you are connecting with 802.1X, and you are using a non- Pulse Secure supplicant (a non-pulse Policy Secure agent), the Infranet Enforcer is not supported, unless you are using an IF-MAP Federation network with a DHCP server. Related Documentation Configuring Pulse Policy Secure Solution on page 35 Deploying Pulse Policy Secure Solution to Users Pulse Policy Secure Deployment Summary on page 11 Using Kerberos SSO 2014 by Pulse Secure, LLC. All rights reserved 8

20 CHAPTER 2 Deployment Overview Understanding Pulse Policy Secure Deployment Options on page 11 Pulse Policy Secure Deployment Summary on page 11 Understanding the Initial Pulse Policy Secure Deployment User Experience on page 12 Understanding Pulse Policy Secure Deployment Options You can deploy Pulse Policy Secure in several ways to provide access control for network assets. You can use Layer 2 or Layer 3 authentication with the Infranet Enforcer, or you can use Layer X without the Infranet Enforcer to direct users to different VLANs. Both the ScreenOS Enforcer and the SRX Series Services Gateway (Junos Enforcer) are supported as the policy decision point. You can use the built-in Pulse Policy Secure agents, OAC for Windows or Macintosh endpoints, the Java agent for Linux, or agentless access. Alternately, you can deploy the solution with the Windows or Macintosh native 802.1X supplicant (a non-pulse Policy Secure agent). With Pulse Policy Secure 4.x and later you can use the Pulse Secure client. NOTE: Deployment Scenario describes the basic steps for configuring Pulse Policy Secure and the Infranet Enforcer in an example of a server front-end deployment scenario. You can adapt the information in that guide to your specific deployment. Related Documentation Pulse Policy Secure Solution Configuration Overview on page 7 Before You Configure Pulse Policy Secure on page 8 Configuring Pulse Policy Secure Solution on page 35 Deploying Pulse Policy Secure Solution to Users Pulse Policy Secure Deployment Summary on page 11 Understanding the Pulse Policy Secure Solution on page 3 Pulse Policy Secure Deployment Summary Table 5 on page 12 summarizes the deployment scenarios and methods for Pulse Policy Secure by Pulse Secure, LLC. All rights reserved 9

21 Getting Started Guide Table 5: Scenarios and Methods of Deployment Scenarios Methods OAC, Pulse, or non-juniper 802.1X supplicant Unauthenticated wired network access (no 802.1X authentication) Captive portal Redirect HTTP traffic in user s browser to the user sign-in URL Announcement Instruct users to use a web browser to manually find the sign-in URL 802.1X switches that allow unauthenticated access by using a preconfigured VLAN that allows limited network access Captive portal Redirect HTTP traffic in user s browser to the user sign-in URL Announcement Instruct users to use a web browser to manually find the sign-in URL 802.1X switches or wireless access points that do not allow any means to access Pulse Policy Secure Preinstallation of OAC, Pulse, or third-party supplicant by means of SMS or remote login on endpoints Users who do not have administrator rights on endpoint, which is required for OAC or Pulse installation Agentless or Java agent (no 802.1X authentication) Captive portal Redirect HTTP traffic in user s browser to the sign-in URL Announcement Instruct users to use a browser to manually find the sign-in URL Related Documentation Deploying Pulse Policy Secure Solution to Users Understanding the Initial Pulse Policy Secure Deployment User Experience on page 12 Understanding the Initial Pulse Policy Secure Deployment User Experience The user experience during initial deployment depends on whether the user is accessing the Windows or Macintosh version of OAC, Pulse, the Java agent, an agentless deployment, or a non-pulse Policy Secure agent (third-party 802.1X supplicant). Additionally, you can preconfigure the settings for OAC and Pulse on Pulse Policy Secure (recommended), and you can configure SSO for Windows endpoints. If you evaluate or enforce a Host Checker policy at the realm level, OAC and Pulse automatically run the built-in Host Checker on the endpoint to verify for security compliance before the user is authenticated. If the endpoint is in compliance, the user is assigned the role. If you enforce Host Checker at the role level, the user can be authenticated, but can access only roles whose Host Checker policies the endpoint can pass by Pulse Secure, LLC. All rights reserved

22 Chapter 2: Deployment Overview OAC on supported Windows endpoint platforms If you have configured OAC as the client for a role on Windows machines, the first time the user accesses Pulse Policy Secure using a browser, the system automatically installs OAC on the user s computer with the OAC configuration settings you specify. If you enable validation of the device certificate, the user must allow the root CA certificate to be installed. After the initial OAC installation, OAC automatically starts when the user signs into their computer, and displays a sign-in dialog box to sign in to Pulse Policy Secure. If you integrate a solution with Active Directory Service and enable SSO, Windows endpoint users automatically sign in using the same credentials they use to access their Windows desktop. The sign-in dialog box for OAC does not appear. OAC on supported Macintosh endpoint platforms OAC is not automatically installed on Macintosh endpoints. You can direct users to a sign-in page, and the system detects what type of client is attempting to log in. If the machine is a Macintosh, the system displays a landing page from which the user can download and manually install OAC. Pulse on supported Windows endpoint platforms If you have configured Pulse as the client for a role on Windows machines, the first time the user accesses the system using a browser, Pulse Policy Secure automatically installs Pulse on the user s computer with the configuration settings you specify. The user is prompted to accept the security certificate. After the initial installation, Pulse automatically starts when the user signs into their computer and displays a sign-in dialog box to sign in. If you integrate a solution with Active Directory Service and enable SSO, Windows endpoint users automatically sign in using the same credentials they use to access their Windows desktop. The sign-in dialog box for Pulse does not appear. Java agent If you provision a Linux user for access with the Java agent, a lightweight client is automatically downloaded after the user is authenticated through a browser. The agent displays connection status, the IP address, and a logout mechanism. The user is not required to leave the browser window open, but if the session expires, the user must provide credentials through a browser again. Agentless access If you configure agentless access for users on Windows, Macintosh, Linux, or Solaris endpoints, the user always signs in directly using a browser instead of OAC. If you evaluate or enforce a Host Checker policy at the realm level, Host Checker is installed and is run on the endpoint. NOTE: When using agentless access, the user must leave the browser window that contains the sign-in page open. If the user closes the browser window or opens a different window, the endpoint loses the connection to Pulse Policy Secure, and the Infranet Enforcer denies the user access to protected resources. Non-Pulse Policy Secure agent software (third-party 802.1X supplicant) Users of non-pulse Policy Secure agent software must preinstall a security certificate and configure authentication protocols that have been configured for the access management framework. These clients can connect only via Layer 2, so if any restrictive Host Checker policies are configured, users cannot connect. You can configure a default VLAN with no Host Checker restrictions for the initial login by Pulse Secure, LLC. All rights reserved 11

23 Getting Started Guide Related Documentation Creating an Initial Configuration of OAC for Windows Endpoints Using Kerberos SSO Additional Methods for Accessing Protected Resources by Pulse Secure, LLC. All rights reserved

24 CHAPTER 3 Task Guidance Using Task Guidance Using Task Guidance on page 15 Task Guidance provides a graphical interface to make configuring the device simpler. When you initially log in to Pulse Policy Secure, the main Task Guidance page is displayed on screen. If you close Task Guidance, you can access the feature by selecting Guidance in the upper right corner of the screen. The console is displayed with labels for different configuration options that you perform to configure the device. When you click on a label, that section expands to display individual tasks. When you navigate to a page with configuration tasks, a new console pops up to provide instruction. You can scroll the Instruction console up and down, allowing you to view the configuration page, or you can close the console. If you close the console, an Instruction link is displayed in the upper right corner of the screen. If you click the Instruction link, specific information about the current configuration page is displayed. After you complete a task, you are prompted to go to the next task by Pulse Secure, LLC. All rights reserved 13

25 CHAPTER 4 Network Settings Network Configuration Network Configuration on page 17 NOTE: You should upgrade the Pulse Policy Secure device to the latest version and apply the applicable licensing by following the instructions in Pulse Secure Licensing Guide. In this example deployment scenario, the Pulse Policy Secure device uses the network settings for the internal network interface as shown in Table 6 on page 17. Table 6: Pulse Policy Secure device Internal Network Interface Port Settings IP address: Network mask: Gateway IP: Link speed: Auto Primary DNS server: DNS domain(s): localhost If you want to use these settings in your deployment, you can either connect a serial cable to the Infranet Enforcer Console port (using 9600 baud 8 N 1), or change the settings by using the System > Network Settings > Internal Port > Settings page. Or, you can substitute your own settings in the following instructions as necessary. Related Documentation Set Up User Authentication on the Pulse Policy Secure Device on page by Pulse Secure, LLC. All rights reserved 14

26 CHAPTER 5 Host Checker Host Checker Host Checker on page 19 You can use Host Checker to perform checks on endpoint computers that connect to the Pulse Policy Secure device to make sure the endpoints meet certain security requirements. For example, you can make sure that a certain process or application is running on an endpoint before allowing a user to sign in to the Infranet Enforcer and access protected resources. If the user s computer does not meet any of the Host Checker policy requirements, you can display a custom-made HTML remediation page to the user. This page can contain your specific instructions as well as links to resources to help the user bring the computer into compliance with each Host Checker policy. Host Checker runs as a built-in component of Pulse Policy Secure for Windows, the Odyssey Access Client on Macintosh and Windows, or as an independent client-side agent on Windows, Macintosh, or Linux. This section contains a simple example of using a Host Checker policy to require a process to run on the endpoint. This is only one example of the many ways you can configure Host Checker. For example, you can: Host Checker includes many predefined rules that check for antivirus software, firewalls, malware, spyware, and specific operating systems from a wide variety of vendors. You can enable one or more of these rules within a Host Checker client-side policy to ensure that the integrated third-party applications that you specify are running on endpoint computers. Host Checker can monitor and verify that the virus signatures installed on endpoint computers are up to date. Host Checker uses a list of the current virus signatures from the vendor(s) you specify for pre-defined antivirus rules in a Host Checker policy. If an endpoint computer does not have the current virus signatures installed, the Host Checker policy fails. In your deployment, you can configure Host Checker policies to perform checks that are more specific to your requirements. For more information, see Endpoint Security Feature Guide. Related Documentation Require a Process to Run on the Endpoint on page 45 Test the Host Checker Policy and Remediation on page by Pulse Secure, LLC. All rights reserved 15

27 CHAPTER 6 RADIUS Pulse Secure Access Control Service 802.1X Overview on page 21 Pulse Secure Access Control Service 802.1X Overview This chapter describes how to configure 802.1X enforcement in the Pulse Secure Access Control Service solution. You can adapt the information in this chapter to your specific deployment. The information in this chapter applies only to deployments that use 802.1X-enabled wired switches or wireless access points. Figure 4 on page 21 shows one example of an 802.1X deployment with an Infranet Enforcer. In this example, the remediation server must be connected to the same subnet as the external port of the Pulse Policy Secure device. Figure 4: Using 802.1X Enforcement 2014 by Pulse Secure, LLC. All rights reserved 16

28 Getting Started Guide To configure the Pulse Policy Secure device as a RADIUS server for an 802.1X network access device (NAD) you will need to configure a location group, a RADIUS access policy, and RADIUS attributes. A location group associates a sign-in policy with a group of NADs. A RADIUS client policy specifies NAD parameters such as IP address that enable the Pulse Policy Secure device to respond to the device. A RADIUS attribute associates RADIUS return attributes and VLAN tunnel assignment with user roles, and the VLAN assignment determines the network to which an endpoint is assigned. Related Documentation Configuring Location Group Policies on page 47 Configuring RADIUS Client Policies on page 48 Using RADIUS Attribute to Specify VLANs for Endpoints on page 73 Configuring RADIUS Client Policies on page by Pulse Secure, LLC. All rights reserved

29 CHAPTER 7 Junos Enforcer Introduction to the Junos Enforcer Introduction to the Junos Enforcer on page 23 Using IPsec with the Junos Enforcer on page 24 This topic describes the steps for configuring the Junos Enforcer in an example of a server front-end deployment scenario. You can adapt the information in this guide to apply to your specific deployment. See Junos SRX Enforcer Feature Guide for more detailed information about using the Junos Enforcer with the Pulse Policy Secure device. The example deployment scenario in this topic uses simple trust and untrust enforcement options on the Pulse Policy Secure Enforcer. In a production environment, you can define more complex policies based on user identity and group information. The users are in the untrust zone ( /24), and the protected resource is in the trust zone ( /24). See Figure 5 on page 23 for an example of this scenario. Figure 5: Server Front End Scenario 2014 by Pulse Secure, LLC. All rights reserved 18

30 Getting Started Guide NOTE: For cabling, rack mounting, terminology, and basic configuration instructions for Infranet Enforcer platforms, see the user guide that shipped with the Infranet Enforcer or visit the Juniper Networks website at to download the user guide for the platform you are using. Related Setting Up the Interfaces and Security Zones on the Junos Enforcer on page 79 Documentation Synchronizing the Time on the Junos Enforcer and the Pulse Policy Secure Device on page 80 Using IPsec with the Junos Enforcer You use the CLI to configure IPsec on the Junos Enforcer. Unlike the ScreenOS Enforcer, you cannot create policies on the Pulse Policy Secure device and push the policies to the Junos Enforcer. The source interface is specified in the IKE gateway configuration on the Junos Enforcer. In security policies you specify a VPN and the IKE gateway in the VPN. For more information see Security Configuration Guide for J Series Services and SRX Series Services Gateways. NOTE: IPsec on the Junos enforcer can handle up to 5,000 concurrent IKE gateways. The Junos Enforcer does not support Dynamic IPsec. To configure IPsec on the Junos Enforcer, perform three primary tasks: Configure the Pulse Policy Secure device as a RADIUS server for the Junos Enforcer client to enable XAUTH. (You must use the internal interface on the Pulse Policy Secure device. The external interface does not support XAUTH.) Configure IKE and IPsec parameters to specify security restrictions for SAs. Configure security policies to route traffic between the security gateway and the interface for endpoints. The Pulse Policy Secure device polls the Junos Enforcer to retrieve the following configuration details: IKE gateway interface Destination zone Identity Preshared seed RADIUS shared secret by Pulse Secure, LLC. All rights reserved

31 Chapter 7: Junos Enforcer The Pulse Policy Secure device pushes these details to the client to allow establishment of a dial-up VPN tunnel. Related Documentation Configuring IPsec on the Junos Enforcer on page 52 Creating a Resource Access Policy on page by Pulse Secure, LLC. All rights reserved 20

32 CHAPTER 8 ScreenOS Enforcer Introduction to the ScreenOS Enforcer Introduction to the ScreenOS Enforcer on page 27 This guide describes how to configure the ScreenOS Enforcer in the server front-end deployment scenario. You can adapt the information in this chapter to apply to your specific deployment. The example deployment scenario in this guide uses simple trust and untrust enforcement options on the Pulse Policy Secure Enforcer. In a production environment, you can define more complex policies based on user identity and group information. The users are in the untrust zone ( /24), and the protected resource is in the trust zone ( /24). See Figure 5 on page 23 for an example of this scenario. Figure 6: Server Front End Scenario NOTE: For cabling, rack mounting, terminology, and basic configuration instructions for Infranet Enforcer platforms, see the user guide that shipped with the Infranet Enforcer or visit the Juniper Networks Web site at to download the user guide for the platform you are using by Pulse Secure, LLC. All rights reserved 21

33 Getting Started Guide Related Documentation Setting Up the Interfaces on ScreenOS on page by Pulse Secure, LLC. All rights reserved

34 PART 2 Installation Client on page by Pulse Secure, LLC. All rights reserved 23

35 CHAPTER 9 Client Install the Client and Test the Initial Configuration on page 31 Install and Configure Odyssey Access Client or Pulse Policy Secure on page 32 Install the Client and Test the Initial Configuration This section describes how to install and test the client. NOTE: Before you test your initial configuration, make sure ActiveX is enabled in the endpoint Web browser. To install the client and to test the initial configuration: 1. Enter the Pulse Policy Secure device s IP address in a Web browser. For example: 2. Click Yes to the security alert. NOTE: To prevent your Web browser s security warning from appearing each time you sign into the Pulse Policy Secure device, import the certificate of the CA that signed the Pulse Policy Secure device s server certificate into your Web browser s list of trusted root certification authorities. Odyssey Access Client or Pulse Policy Secure installs automatically on the endpoint, depending on the client that you chose for the user roles. 3. When you are prompted to trust the Pulse Policy Secure device by installing the root certificate you generated earlier, select Add this trusted server to the database and then click Yes. 4. When you are prompted for login name, sign in using the user name you configured. For example, enter testuser and click OK. 5. When you are prompted for password, enter the password you configured (for example, abcd1234) and click OK by Pulse Secure, LLC. All rights reserved 24

36 Getting Started Guide If Notepad is not running, the endpoint fails the Host Checker security policy and you are assigned the Quarantine role. Related Preconfigure Odyssey Access Client for Endpoint Download on page 39 Documentation Configure Pulse Policy Secure for Endpoint Download on page 43 Install and Configure Odyssey Access Client or Pulse Policy Secure For this example, Odyssey Access Client or Pulse Policy Secure is used as the supplicant for 802.1X authentication. Endpoints can use the client to be authenticated and to obtain an IP address to connect to the network and access protected resources. The easiest way to deploy a client on endpoints is to have users navigate to the Pulse Policy Secure s sign-in URL with a Web browser. Odyssey Access Client automatically installs on the user s computer with the settings you preconfigured. If you are using 802.1X network access devices that do not allow users to connect to the Pulse Policy Secure without a client installed, you must preinstall Odyssey Access Client or Pulse Policy Secure. You can download Odyssey Access Client (Pulse Policy Secure Agent) or Pulse Policy Secure from by selecting Maintenance > System > Installers. For detailed configuration details, see or the Pulse Policy Secure Administrators Guide. Related Documentation Configuring Location Group Policies on page 47 Configuring RADIUS Client Policies on page 48 Using RADIUS Attribute to Specify VLANs for Endpoints on page by Pulse Secure, LLC. All rights reserved

37 PART 3 Configuration Access Control Service on page 35 OAC on page 39 Pulse Policy Secure on page 43 Host Checker Policy on page 45 RADIUS on page 47 Junos Enforcer on page 51 ScreenOS Enforcer on page by Pulse Secure, LLC. All rights reserved 26

38 CHAPTER 10 Access Control Service Configuring Pulse Policy Secure Solution on page 35 Configuring Pulse Policy Secure Solution To configure the Pulse Policy Secure solution: 1. If you have not already done so, install the hardware. 2. If you have not already done so, upgrade and license the software. 3. If you are using the Infranet Enforcer, install the device. 4. If you are using the Infranet Enforcer, perform both of the following steps to set up certificates: Import a signed server certificate into Pulse Policy Secure. Import the certificate of the certificate authority (CA) that signed Pulse Policy Secure server certificate into the Infranet Enforcer. 5. If you are using the Infranet Enforcer, configure the connection to the Infranet Enforcer. 6. Configure user authentication and authorization by setting up roles, authentication and authorization servers, and authentication realms: a. Define user and administrator roles. Roles define user session parameters and OAC, Pulse, or agent/agentless options. The system is preconfigured with one user role (Users) and two administrator roles (Administrators and Read-Only). b. Define authentication and authorization servers. Authentication and authorization servers authenticate user credentials and determine user privileges within the system. The system is preconfigured with one local authentication server (System Local) to authenticate users and one local authentication server (Administrators) to authenticate administrators. You must add users to either the local authentication server or the external authentication servers. c. Define authentication realms. Authentication realms contain policies specifying conditions the user or administrator must meet to sign in to the system. For example, you can use an authentication policy to specify that users can access protected resources only if they are signing in from a particular location. When configuring an authentication realm, you must create rules to map users to roles and specify, which server (or servers) they should use to authenticate and authorize realm members. The system is preconfigured with one realm (Users) that maps all users authenticated through the System Local server to the Users role. The system is also preconfigured with one realm (Admin Users) that maps all users authenticated through the Administrators server to the Administrators role by Pulse Secure, LLC. All rights reserved 27

39 Getting Started Guide NOTE: The system modifies usernames that contain spaces or characters that are not valid on the Infranet Enforcer. For example, usernames with spaces appear in auth table entries as one word, and quotes in usernames appear without the quotes. 7. (Optional) Select and configure OAC options (such as timeout values and restrictions), or create Pulse configuration parameters. Macintosh endpoints can use the Macintosh version of OAC. To configure client-side settings on the Macintosh version, you can create a script from the Windows version of Odyssey Client Administrator and import it to the Macintosh to populate agent settings. Alternately, you can configure endpoints to connect with agentless access, or you can configure the lightweight Java agent for access with Linux endpoints. In an 802.1X deployment, you can also use a non-juniper supplicant. 8. If you are using the Infranet Enforcer, configure resource access policies to specify which roles are allowed or denied access to resources. 9. If you are using the Infranet Enforcer, do one of the following to set up source IP enforcement and/or IPsec enforcement: Set up source IP enforcement by configuring an infranet auth policy on the Infranet Enforcer. Source IP enforcement allows the Infranet Enforcer to control which zones use resource access policies to allow or deny traffic. Set up IPsec enforcement on Windows endpoints that OAC supports. You can use IPsec enforcement between the endpoint and the Infranet Enforcer instead of source IP enforcement. To use IPsec, you must set up a VPN tunnel for a dial-up user with IKE on the Infranet Enforcer. 10. In a Layer 2 environment without the Infranet Enforcer, configure OAC, Pulse, or a non-pulse Secure 802.1X supplicant for endpoints. You must also configure policies to allow Pulse Policy Secure RADIUS server to work with the NAD (NAD). If you have not already done so, install and configure the 802.1X NADs on the network. See the documentation provided with the NAD. If you have not already done so, configure VLANs within the network for deployments that are not using the Infranet Enforcer. The simplest scenario is to configure two VLANs: one for authenticated users and a remediation VLAN for users who do not meet authentication requirements. 11. Optionally, configure Host Enforcer policies to protect endpoints that use OAC and enforce policies on the endpoint itself by allowing only the traffic you specify in the Host Enforcer policies for the role. While this is not a substitute for a firewall, Host Enforcer policies can add another layer of access control. Host Enforcer is not supported on Pulse by Pulse Secure, LLC. All rights reserved

40 Chapter 10: Access Control Service 12. Create Host Checker policies and set remediation options. 13. Determine at which levels within the access management framework to enforce the Host Checker policies: To enforce Host Checker policies when the user first accesses the Pulse Secure gateway, implement the policies at the realm level. To allow or deny users access to roles based on their compliance with Host Checker policies, implement the policies at the role level. To map users to roles based on their compliance with Host Checker policies, use custom expressions. 14. If necessary, configure agentless access to protected resources for endpoint platforms that OAC or Pulse do not support, including Linux and Solaris. 15. If necessary, configure the Java agent for access to protected endpoints for Linux. 16. Deploy Pulse Policy Secure solution to users. TIP: Be sure to set the date and time of the Infranet Enforcer to match the date set for Pulse Policy Secure. If possible, use a Network Time Protocol (NTP) server to set the date and time for both appliances. Related Documentation Upgrading the System Software Deploying Pulse Policy Secure Solution to Users Understanding Licensing Using Certificate-Based Security with Infranet Enforcer Deployments Understanding User Roles AAA Server Overview Understanding Authentication Realms About Resource Access Policies Understanding Infranet Enforcer Source IP Security Policies Understanding Pulse Policy Secure Support for IPsec Routing Policies Understanding 802.1X Network Access Control Deployments Using Host Enforcer Policies Creating Global Host Checker Policies Additional Methods for Accessing Protected Resources 2014 by Pulse Secure, LLC. All rights reserved 29

41 CHAPTER 11 OAC Preconfigure Odyssey Access Client for Endpoint Download on page 39 Preconfigure Odyssey Access Client for Endpoint Download After you perform the initial installation, you can use a preconfigured installer to manage the security and access settings on the Odyssey Access Client using the Pulse Policy Secure device admin console. See Using the Preconfigured Installer for OAC on Windows Endpoints. Alternately, you can configure Pulse Policy Secure as the client that downloads to endpoints. NOTE: Except for the login name in the profile, all of the other configuration settings you specify on the Pulse Policy Secure device overwrite any existing settings on the endpoint if Odyssey Access Client is already installed when the user accesses the Infranet Enforcer. For the sake of simplicity, these instructions describe how to preconfigure the Odyssey Access Client for the testuser you created for a basic default installation. To create an initial configuration of Odyssey Access Client: 1. In the admin console, select roles that you created from. 2. Click the Agent tab. 3. Click on Odyssey Settings. The IC Access page appears. 4. Select Use Pulse Policy Secure device's host name. The Infranet Enforcer host name is used for the name of the profile and the Infranet Enforcer instance in Odyssey Access Client. If the Infranet Enforcer does not have a hostname configured, enter the URL for the Infranet Enforcer or the redirect URL from a captive portal is used instead for the name. 5. Leave Require connection to this Pulse Policy Secure device option cleared. 6. Under Profile, select Prompt for login name using the following prompt to display a dialog box to enter the testuser name during the initial Odyssey Access Client installation. The testuser name is then configured in the Login name setting, and the user is not prompted again. You can also configure the text string used for the prompt in the dialog box. 7. Select Permit login using password to enable password authentication, then select Prompt for password to have Odyssey Access Client prompt the testuser to enter a password when the user is authenticated the first time after startup. 8. Specify whether to use Tunneled TLS (TTLS) or Protected EAP (PEAP) as the outer authentication protocol for traffic between Odyssey Access Client and the Infranet Enforcer. Select Use EAP-TTLS as outer authentication protocol or Use EAP-PEAP as outer authentication protocol. 9. Leave the Personal certificate usage option cleared by Pulse Secure, LLC. All rights reserved 30

42 Getting Started Guide 10. Leave Anonymous name set to anonymous. 11. To use 802.1X enforcement in this example scenario, specify the type of adapter(s) to configure in Odyssey Access Client: Configure wired adapter(s) Odyssey Access Client configures the wired adapter on the user s computer that is actively being used to access the Infranet Enforcer on an 802.1X-enabled network. If the user is accessing the Infranet Enforcer through a wireless adapter during Odyssey Access Client installation, then Odyssey Access Client automatically configures a wired adapter to use for wired access to the Infranet Enforcer at a later time. Configure wireless adapter(s) Select this option only if the endpoint is connecting to the Infranet Enforcer by using 802.1X. Odyssey Access Client configures the wireless adapter on the user s computer that is actively being used to access the Infranet Enforcer on an 802.1X-enabled network. If the user is accessing the Infranet Enforcer through a wired adapter during Odyssey Access Client installation, then Odyssey Access Client automatically configures a wireless adapter to use for wireless access to the Infranet Enforcer at a later time. If you select this option, you must also configure the Network name (SSID) under Network properties. You might also need to configure other Network properties depending on your environment. NOTE: If you select Configure wireless adapter(s), Windows Wireless Zero Configuration (WZC) is disabled for the wireless adapter that Odyssey Access Client configures. If the user removes a wireless adapter from the local Odyssey Access Client configuration, the user must enable the adapter again by selecting Control Panel > Network Connections> adapter name > Properties > Wireless Networks and then selecting the Use Windows to configure my network settings option. 12. (Only if you enable Configure wireless adapter) under Network, specify the network settings you want to configure in Odyssey Access Client for wireless adapters. Network name (SSID) Specify the network name or SSID service set identifier (SSID) of the wireless network to which Odyssey Access Client must connect. A network name can be up to 32 alphanumeric characters and is case sensitive. Association mode Specify the association mode Odyssey Access Client must use for associating to the access point hardware on your network. Open Connect to a network through an access point or switch that implements 802.1X authentication. Select this mode if users are not required to use shared mode or Wi-Fi Protected Access (WPA). WPA Connect to a network through an access point that implements WPA. WPA2 Connect to a network through an access point that implements WPA2, the second generation of WPA that satisfies i by Pulse Secure, LLC. All rights reserved

43 Chapter 11: OAC Encryption method Specify the encryption method you want Odyssey Access Client to use. The available choices depend on the association mode you select. None Use 802.1X authentication without WEP keys. This option is available only if you configure access point association in open mode. This is a typical setting to use for wireless hotspots. WEP Use WEP keys for data encryption. You can select this option if you selected open mode association. Select WEP encryption if the access points in your network require WEP encryption. Odyssey Access Client automatically generates the WEP keys. TKIP Use the temporal key integrity protocol (TKIP). Select TKIP if the access points in your network require WPA or WPA2 association and are configured for TKIP data encryption. AES Use the advanced encryption standard protocol. Select AES if the access points in your network require WPA or WPA2 association and are configured for AES data encryption. NOTE: If you select WEP encryption, the Infranet Enforcer automatically selects the Keys will be generated automatically for data privacy option in the Odyssey Access Client Network properties for the wireless adapter. 13. Click Save Changes. NOTE: For more information about the Odyssey Access Client configuration settings, see 802/information-products/pathway-pages/oac/product/ Related Documentation Set Up User Roles on the Pulse Policy Secure Device on page 65 Host Checker on page 19 Validate the Pulse Policy Secure Device Certificate on page 69 Install the Client and Test the Initial Configuration on page by Pulse Secure, LLC. All rights reserved 32

44 CHAPTER 12 Pulse Policy Secure Configure Pulse Policy Secure for Endpoint Download on page 43 Configure Pulse Policy Secure for Endpoint Download You can distribute Pulse Policy Secure to endpoints for Windows machines. Pulse Policy Secure is Pulse Secure s lightweight, multi-platform client introduced in Pulse Policy Secure Release 4.x and later. You do not need to preconfigure the Pulse Policy Secure client. The default client installer on the Pulse Policy Secure device is preconfigured to connect to the client. When endpoints first connect to the Pulse Policy Secure device using a browser, Pulse Policy Secure automatically downloads with the necessary components and connections that are required. To distribute Pulse Policy Secure, you must enable the download from the User Roles page. 1. In the admin console, navigate to the full access and quarantine roles that you configured previously. 2. Select the Agent tab. 3. Select the Install Pulse Policy Secure option button. 4. Click Save Changes. NOTE: For more information about the Pulse Policy Secure configuration settings, see the Pulse Policy Secure Administration Guide. Related Documentation Set Up User Roles on the Pulse Policy Secure Device on page 65 Host Checker on page 19 Validate the Pulse Policy Secure Device Certificate on page 69 Install the Client and Test the Initial Configuration on page by Pulse Secure, LLC. All rights reserved 33

45 CHAPTER 13 Host Checker Policy Require a Process to Run on the Endpoint on page 45 Require a Process to Run on the Endpoint This section describes how to configure a Host Checker policy that uses a process-check rule to verify that the notepad.exe process is running on the endpoint. To require a process to run on the endpoint: 1. In the Pulse Policy Secure device admin console, select Authentication > Endpoint Security > Host Checker. 2. Under Policies, click New. 3. Enter a name in the Policy Name field, such as NotepadMustRun, and then click Continue. 4. To create a process-check rule, select Custom: Process under Rule Settings and then click Add. a. For Rule Name, type: NotepadProcess. b. For Process Name, type: notepad.exe. c. Select Required to require that this process is running. d. Leave the MD5 Checksums blank. e. Click Save Changes to save the rule. 5. To display a remediation page with instructions to the user for when the endpoint does not meet the requirements of the Host Checker policy: a. Select Enable Custom Instructions on the Host Checker Policy page. b. Type instructions to display to the user. For example: You must run Notepad before you can sign in. 6. Click Save Changes to save the Host Checker policy. 7. Implement the Host Checker policy at the role level: a. Select Users > User Roles > Full Access. b. Select Restrictions > Host Checker. c. Select Allow users whose workstations meet the requirements specified by these Host Checker policies. d. Select the NotepadMustRun policy and click Add. e. Click Save Changes by Pulse Secure, LLC. All rights reserved 34

46 Getting Started Guide Related Documentation Install the Client and Test the Initial Configuration on page by Pulse Secure, LLC. All rights reserved

47 CHAPTER 14 RADIUS Configuring Location Group Policies Configuring Location Group Policies on page 47 Configuring RADIUS Client Policies on page 48 Configuring RADIUS Attributes on page 49 You can use location group policies to organize or logically group network access devices (NADS) by associating them with specific sign-in policies. Sign-in policies provide a way to define and direct independent access control policies with the network. Location groups associate sign-in policies with the NADS. A sign-in policy defines the URL and realms that users of NADS can use to access the Pulse Policy Secure device. When creating a sign-in policy, you associate it with the appropriate URL and realms. When you create a realm, you associate it with an authentication server. Thus, by associating a location group with a sign-in policy, you can associate a group of NADS with an authentication server along with the other realm settings such as an authentication policy and role mapping. For example, you can create location group policies to logically group the NADS in each building at a corporate campus. You will configure one location group in this example deployment. For more information on location groups, see Network Access Control Feature Guide. To configure a location group policy on the Pulse Policy Secure device: 1. Create a sign-in policy that you want to associate with the location group. Alternately, use the */testsite/ sign-in policy you created earlier. 2. In the admin console, select Pulse Policy Secure > Network Access > Location Group. 3. Click New Location Group. 4. On the New Location Group, enter a name for this location group policy, such as testlocationgroup. 5. For Description, enter an optional description. 6. For Sign-in Policy, select the sign-in policy to associate with the location group. 7. Leave MAC Authentication Realmset to None. 8. Click Save Changes by Pulse Secure, LLC. All rights reserved 36

48 Getting Started Guide Related Documentation Pulse Secure Access Control Service 802.1X Overview on page 21 Configuring RADIUS Client Policies To enable the Pulse Policy Secure device to respond to a NAD, you must configure a RADIUS client policy in the Pulse Policy Secure device with the following information about the device: The IP address of the NAD The shared secret used by both the Pulse Policy Secure device and the NAD The make and model of the NAD, which you select from a list of devices in the Pulse Policy Secure device admin console The Pulse Policy Secure device supports a large number of specific NADs by using its built-in standard RADIUS and vendor-specific, proprietary dictionary files. The Pulse Policy Secure device uses the dictionary files to store lists of RADIUS attributes and parse authentication requests and generate responses. When you select the device s make and model in a RADIUS client policy, you select a dictionary file that contains the vendor-specific attributes (VSAs) for that device. Whenever the Pulse Policy Secure device receives a RADIUS packet from that device, it consults the dictionary file for any nonstandard attributes that it encounters in the packet. If you do not know the make and model of a device, you can use the standard RADIUS attributes by choosing the Standard RADIUS setting in a RADIUS client policy. You can use only the dictionaries installed on the Pulse Policy Secure device. You cannot load additional dictionaries or change the values of the installed dictionaries entries. To configure a RADIUS client policy on the Pulse Policy Secure device: 1. If you have not already done so, configure a location group policy. At least one location group policy is required before you can configure a RADIUS client policy. 2. In the Pulse Policy Secure device admin console, select Pulse Policy Secure > Network Access > RADIUS Client. 3. Click New RADIUS Client. 4. On the RADIUS Client Policy page, enter a name to label this RADIUS client policy. Although you can assign any name to a RADIUS client entry, use the device's IP address or host name to avoid confusion. 5. For Description, enter an optional description. 6. For IP Address, enter the IP address of the NAD. 7. Optional) For IP Address Range, enter For Shared Secret, enter the RADIUS shared secret. A RADIUS shared secret is a case-sensitive password for validating communications between the Pulse Policy Secure device and NAD. The Pulse Policy Secure device supports shared secrets of up to 127 alphanumeric characters, including spaces and the following special characters: ~!@#$%^&*()_+ \=- {}[]: ;<>?/., by Pulse Secure, LLC. All rights reserved Downloadrights reserved

49 Chapter 14: RADIUS 9. For Make/Model, select the make and model of the NAD. This selection tells the Pulse Policy Secure device which dictionary of RADIUS attributes to use when communicating with this client. NOTE: If you are not sure of the make and model you are using or if your device is not in the list, select - Standard RADIUS - for Make/Model. If the NAD is not fully RFC compliant and does not accept RFC3680 Tunnel Attributes with tags, select - Standard RADIUS: No VLAN tags - for Make/Model. 10. For Location Group, select the location group you created earlier (testlocationgroup) to use with this NAD. 11. Click Save Changes. Related Documentation Pulse Secure Access Control Service 802.1X Overview on page 21 Configuring RADIUS Attributes Before you configure a RADIUS attributes policy, verify the following configuration on the NADs you want to use with the Pulse Policy Secure device: The NAD must support RADIUS-based, dynamic VLAN assignment. The ports must be 802.1X enabled. The VLAN IDs you want to use in the Pulse Policy Secure device RADIUS VLAN policies must be configured on the devices. The endpoints must be able to obtain an IP address from a DHCP server that is in the VLANs you are using. In this example scenario, you will create two RADIUS attributes policies; one for the Full Access role, and another policy for the Quarantine role. To configure a RADIUS attributes policy for the Full Access role: 1. In the Pulse Policy Secure device admin console, select Pulse Policy Secure > Network Access > RADIUS Attributes. 2. Click New Policy. 3. On the New Policy. page: a. For Name, enter a name to label this policy, such as FullAccessVLANPolicy. b. For Description, enter an optional description. 4. Under Location Group select the location group you created earlier (testlocationgroup). 5. Under RADIUS Attributes, select VLAN to configure VLAN assignment according to RFC 3580 by returning the RADIUS tunnel attributes to the NAD. Specify VLAN ID by Pulse Secure, LLC. All rights reserved 38

50 Getting Started Guide 6. For Interface, select Internal. You must also connect the Pulse Policy Secure device internal interface to VLAN In the Roles section, select Policy applies to SELECTED roles and then add the Full Access role to this list from the Available roles list. 8. Click Save Changes. To configure a RADIUS attributes policy for the Quarantine role: 1. In the Pulse Policy Secure device admin console, select Pulse Policy Secure > Network Access > RADIUS Attributes. 2. Click New Policy. 3. On the New Policy. page: a. For Name, enter a name to label this policy, such as QuarantineVLANPolicy. b. For Description, enter an optional description. 4. Under Location Group select the location group you created earlier (testlocationgroup). 5. Under RADIUS Attributes, select VLAN to configure VLAN assignment according to RFC 3580 by returning the RADIUS tunnel attributes to the NAD. Specify VLAN ID For Interface, select Internal. You must also connect the Pulse Policy Secure device internal interface to VLAN In the Roles section, select Policy applies to SELECTED roles and then add the Full Access role to this list from the Available roles list. 8. Click Save Changes by Pulse Secure, LLC. All rights reserved

51 CHAPTER 15 Junos Enforcer Configuring the Pulse Policy Secure Device to Connect to the Junos Enforcer on page 51 Configuring a Security Policy for Source IP Enforcement on page 52 Configuring IPsec on the Junos Enforcer on page 52 Configuring the Pulse Policy Secure Device to Connect to the Junos Enforcer The Junos Enforcer connects with the Infranet Enforcer over an SSL connection. To initiate the connection between the two appliances, you must specify the password and serial number of the Junos Enforcer. The Junos Enforcer initiates the connection to the Pulse Policy Secure device. The Pulse Policy Secure device presents its SSL server certificate to the Junos Enforcer. Optionally, you can configure the Junos enforcer to verify the certificate, and you can specify constraints with which the Pulse Policy Secure device must comply. The Junos Enforcer and the Pulse Policy Secure device perform mutual authentication with the proprietary JUEP-MAUTH challenge response authentication based on the password configured. For security reasons, the password does not appear in the message sent to the Pulse Policy Secure device. After the SSL handshake, all further communication between the Pulse Policy Secure device and the Junos Enforcer occurs over the SSL connection. The Junos Enforcer is the client, and the Pulse Policy Secure device is the server. To configure the Pulse Policy Secure device to accept a connection from the Junos Enforcer: 1. On the left navigation bar in the Pulse Policy Secure device admin console, select Pulse Policy Secure > Infranet Enforcer > Connection. 2. Click New Enforcer. The New Infranet Enforcer dialog box appears. By default, the new ScreenOS Enforcer page appears. 3. Select the Junos option button. The Junos Enforcer page appears. 4. Enter the name of the Infranet Enforcer in the Name box. For this example, use the name Enforcer. 5. Enter the password for the Junos Enforcer. 6. Enter the serial number of the Junos Enforcer. You can view the serial number on the Junos Enforcer using the command: show chassis hardware 7. Ensure that the server certificate for the Pulse Policy Secure device is configured for the interface to which the Junos Enforcer is connecting. 8. Click Save Changes by Pulse Secure, LLC. All rights reserved 40

52 Getting Started Guide Related Documentation Setting Up the Pulse Policy Secure Device on the Junos Enforcer on page 81 Configuring a Security Policy for Source IP Enforcement on page 52 Configuring a Security Policy for Source IP Enforcement NOTE: You can configure polices on the Pulse Policy Secure device and push the policies to the ScreenOS Enforcer. If you are using the Junos Enforcer, you must configure policies through the CLI. The following security policy adds enforcement in Pulse Policy Secure a security policy named pol1 from the zone named untrust to the zone named trust. 1. Define the incoming (source) zone (untrust) by typing the following statement: user@host# set security policies from-zone untrust to-zone trust policy pol1 match sourceaddress any 2. Define the destination zone (trust) by typing the following statement: user@host# set security policies from-zone untrust to-zone trust policy pol1 match destination-address any 3. Define the policy action by typing the following statement: user@host# set security policies from-zone untrust to-zone trust policy pol1 match application any user@host# set security policies from-zone untrust to-zone trust policy pol1 then permit application-services uac-policy For instructions on using IPsec with the Junos Enforcer, see Junos SRX Enforcer Feature Guide. Related Documentation Using IPsec with the Junos Enforcer on page 24 Configuring IPsec on the Junos Enforcer This example shows a sample configuration for setting up IPsec on the Junos Enforcer. To use IPsec with the ScreenOS Enforcer, you can configure basic IPsec security policies on the Pulse Policy Secure device and then push the policies to the firewall. On the Junos Enforcer, this functionality does not exist. For the Junos Enforcer, use the CLI to configure settings to create SAs on the Junos Enforcer that are negotiated with the Pulse Policy Secure client. Before you begin, verify that security zones and interfaces are set up and that IPsec routing policies and optional IP address pool policies have been configured on the Pulse Policy Secure device. J Series Juniper Networks devices support up to four proposals for Phase 2 negotiations, allowing you to define the range of tunnel parameter restrictions that endpoints can accept by Pulse Secure, LLC. All rights reserved

53 Chapter 15: Junos Enforcer For a complete explanation of IPsec on the Junos Enforcer see the Junos OS Initial Configuration Guide for Security Devices. To configure IPsec on the Junos Enforcer: 1. Configure the Pulse Policy Secure device as a RADIUS server for the Junos Enforcer client. In this example, you create an instance of the Pulse Policy Secure device hostname dev1086 as the RADIUS server. The IP address is You must provide a shared secret, which is used to permit the Pulse Policy Secure device to accept RADIUS packets from the device. user@host# set access profile dev1086 authentication-order radius user@host# set access profile dev1086 radius-server secret some-shared-secret If you are configuring Pulse Policy Secure devices in an active/active cluster, you must configure all IP addresses for individual Pulse Policy Secure devices. The shared secret must be the same, as in the following example: user@host# set access profile dev1086 authentication-order radius user@host# set access profile dev1086 radius-server secret some-shared-secret user@host# set access profile dev1086 radius-server secret some-shared-secret If you are configuring an active/passive cluster, configure the Pulse Policy Secure devices VIP as the RADIUS server IP address. 2. Configure IKE and IPsec security parameters. NOTE: IPsec with the Junos Enforcer is supported only with aggressive mode and Encapsulation Security Payload (ESP). In aggressive mode, Phase 1 security proposals are negotiated with two exchanges and a total of three messages: First message The initiator proposes the SA, initiates a Diffie-Hellman exchange, and sends a pseudorandom number and the IKE identity. Second message The recipient accepts the SA; authenticates the initiator; and sends a pseudorandom number, the IKE identity, and, if using certificates, the recipient's certificate. Third message The initiator authenticates the recipient, confirms the exchange, and, if using certificates, sends the initiator's certificate. Because the participants identities are exchanged in the clear (in the first two messages), Aggressive mode does not provide identity protection. ESP protects the inner IP packet, while the outer header remains unprotected. You define the security proposals, including all of the IKE parameters that determine 2014 by Pulse Secure, LLC. All rights reserved 42

54 Getting Started Guide NOTE: IPsec with the Junos Enforcer is supported only with aggressive mode and Encapsulation Security Payload (ESP). In aggressive mode, Phase 1 security proposals are negotiated with two exchanges and a total of three messages: First message The initiator proposes the SA, initiates a Diffie-Hellman exchange, and sends a pseudorandom number and the IKE identity. Second message The recipient accepts the SA; authenticates the initiator; and sends a pseudorandom number, the IKE identity, and, if using certificates, the recipient's certificate. Third message The initiator authenticates the recipient, confirms the exchange, and, if using certificates, sends the initiator's certificate. Because the participants identities are exchanged in the clear (in the first two messages), Aggressive mode does not provide identity protection. ESP protects the inner IP packet, while the outer header remains unprotected. You define the security proposals, including all of the IKE parameters that determine the strength of the IPsec tunnels. These options define the SAs for this IPsec tunnel. In this example, you set up a phase 1 IKE proposal named prop1, using Diffie-Hellman Group 2, authentication algorithm SHA1, and encryption algorithm 3DES-CBC. user@host# set security ike proposal prop1 authentication-method pre-shared-keys The client supports only the pre-shared key authentication method. user@host# set security ike proposal prop1 dh-group group2 The client supports group1, group2, and group5. user@host# set security ike proposal prop1 authentication-algorithm sha1 The client supports md5 and sha1. user@host# set security ike proposal prop1 encryption-algorithm 3des-cbc The client supports des-cbc, 3des-dbc, aes-128-cbc, aes-192-cbc, and aes-256-cbc In this example, you set up an IKE policy named pol1 with aggressive mode, the preshared key and the proposal that was configured in the previous section. user@host# set security ike policy pol1 mode aggressive The client supports only aggressive mode. user@host# set security ike policy pol1 proposals prop1 user@host# set security ike policy pol1 pre-shared-key ascii-text some-preshared-key Only ASCII is supported. Do not use a hexadecimal pre-shared key. In this example, you configure an IKE gateway named gateway1 with 5000 connection limits, host.company.com identity, group IKE ID, IKE policy pol1 configured above, and XAUTH dev user@host# user@host# set security ike gateway gateway1 ike-policy pol by Pulse Secure, LLC. All rights reserved

55 Chapter 15: Junos Enforcer set security ike gateway gateway1 dynamic hostname host.company.com set security ike gateway gateway1 dynamic connections-limit 5000 set security ike gateway gateway1 dynamic ike-user-type group-ike-id set security ike gateway gateway1 dynamic connections-limit (maximum 5,000) set security ike gateway gateway1 external-interface ge-0/0/2.0 set security ike gateway gateway1 xauth access-profile dev1086 The Pulse Policy Secure device and the client support only group-ike-id. In this example, you configure an IPsec phase 2 proposal named prop1 with ESP protocol, HMAC-SHA1-96 authentication algorithm, and 3DES-CBC encryption algorithm. user@host# set security ipsec proposal prop1 protocol esp The client supports only ESP. user@host# set security ipsec proposal prop1 authentication-algorithm hmac-sha1-96 The client supports hmac-md5-96, and hmac-sha1-96. user@host# set security ipsec proposal prop1 encryption-algorithm 3des-cbc The client supports des-cbc, 3des-cbc, aes-128-cbc, aes-192-cbc, aes-256-cbc, and no encryption-algorithm. In this example, you configure an IPsec phase 2 policy name pol1 with proposal prop1. user@host# set security ipsec policy pol1 proposals prop1 In this example, you configure an IPsec VPN named vpn1 with IKE gateway gateway1 and IPsec policy pol1. user@host# set security ipsec vpn vpn1 ike gateway gateway1 user@host# set security ipsec vpn vpn1 ike ipsec-policy pol1 user@host# set security ipsec vpn vpn1 establish-tunnels immediately user@host#set security ike gateway gateway1 external-interface ge-0/0/0.0 user@host#set security ike gateway gateway1 xauth access-profile The client requires that the tunnel be established immediately. 3. Create the security policy. In this section, you enable the VPN vpn1, and add enforcement in Pulse Policy Secure a security policy named pol1 from the zone named untrust to the zone named trust. user@host# set security policies from-zone untrust to-zone trust policy pol1 match source-address any NOTE: Always specify any with the following command. user@host# set security policies from-zone untrust to-zone trust policy pol1 match destination-address any user@host# set security policies from-zone untrust to-zone trust policy pol1 match application any user@host# set security policies from-zone untrust to-zone trust policy pol1 then permit tunnel ipsec-vpn vpn1 user@host# set security policies from-zone untrust to-zone trust policy pol1 then permit application-services uac-policy 2014 by Pulse Secure, LLC. All rights reserved 44

56 Getting Started Guide Related Documentation Using IPsec with the Junos Enforcer on page 24 Creating a Resource Access Policy on page by Pulse Secure, LLC. All rights reserved

57 CHAPTER 16 ScreenOS Enforcer Configuring the Access Control Service to Connect to the ScreenOS Enforcer on page 57 Configuring IPsec Enforcement on page 58 Configuring the Access Control Service to Connect to the ScreenOS Enforcer You must configure the connection between the Access Control Service and the Infranet Enforcer. To configure the conneection: 1. Select Pulse Policy Secure > Infranet Enforcer > Connection. 2. Click New Enforcer. 3. On the New Enforcer page: a. For Name, enter the name of the Infranet Enforcer, such as isg2000.xyz.com. b. For NACN password, enter an NACN password for this Infranet Enforcer, such as xyz123. You must enter the same NACN password you specified when you configured the Pulse Policy Secure device instance on the Infranet Enforcer. c. Enter the administrator name and password for signing in to the Infranet Enforcer. The default name and password for the Infranet Enforcer are netscreen and netscreen. Be sure to change these defaults to more secure settings. d. Enter the serial number of the Infranet Enforcer. You can view the serial number on the Home page of the Infranet Enforcer Web UI, or by using the CLI command get system. e. For Location Group, select - No 802.1X - because this example does use an Infranet Enforcer as an 802.1X RADIUS client of the Infranet Enforcer. 4. Click Save Changes. Related Documentation Setting Up the Pulse Policy Secure Device Instance on the ScreenOS Enforcer on page 86 Configuring IPsec Enforcement on page by Pulse Secure, LLC. All rights reserved 46

58 Getting Started Guide Configuring IPsec Enforcement To prevent source IP spoofing, Odyssey Access Client or Pulse Policy Secure and the Pulse Policy Secure device can use IPsec to encrypt the traffic between an endpoint and the Infranet Enforcer. NOTE: Odyssey Access Client or Pulse must be running on the Windows endpoint for IPsec to operate. IPsec is not supported on agentless endpoints. Note that IPsec enforcement is optional on Windows and is not supported on any other platforms, such as Macintosh and Linux. Instead, you can use source IP enforcement by setting up a source-based policy on the Infranet Enforcer. This example deployment does not include Network Address Translation (NAT) devices in your deployment. If you use any NAT devices, you must configure IP pool policies. The following instructions describe how to configure an IPsec tunnel to the /24 network for users mapped to the Full Access role when they are signed in. To configure IPsec enforcement: 1. Select Pulse Policy Secure > Infranet Enforcer > Connection, and click the name in the Enforcer column of the Infranet Enforcer on which you want to configure IPsec enforcement. NOTE: The Pulse Policy Secure device must be connected to the Infranet Enforcer before you can use the Pulse Policy Secure device to set up IPsec enforcement on the Infranet Enforcer. 2. Select Pulse Policy Secure > Infranet Enforcer > ScreenOS Policies then: a. Select the source zone for the policy from the Source Zone list. The source zone is the zone where the endpoint is located. b. Select the destination zone for the policy from the Destination Zone list. The destination zone is where the protected resources are located. c. Select IPsec from the Type drop-down list. d. Click Add. e. Select Save Changes to save the IPsec policy. The Infranet Enforcer sets up a VPN tunnel for a dial-up user with IKE on the Infranet Enforcer that consists of a user, user group, IKE gateway, and VPN for each source interface in the source zone of the policy. The Infranet Enforcer uses the source by Pulse Secure, LLC. All rights reserved

59 Chapter 16: ScreenOS Enforcer interface number and the ID of the destination zone to uniquely name each of these objects. 3. Configure an IPsec routing policy to specify which Infranet Enforcer device the endpoints must use to access each set of resources when using IPsec: a. In the Pulse Policy Secure device admin console, select Pulse Policy Secure > Infranet Enforcer > IPsec Routing. b. Click New Policy. c. For Name and Description, enter any name and description for this policy. d. For Resources, enter the IP address and netmask of each resource that requires endpoints to use IPsec, one per line, in the following format: <ip address> [/netmask] For example, type /24 to specify the protected resources on the trust interface of the Infranet Enforcer. e. For Exceptions, use the following format, one per line, to specify the IP address and netmask of each resource that has traffic that must not flow through the Infranet Enforcer: <ip address> [/netmask] NOTE: Each exception must be a subset of what you specify for Resources. Do not use IPsec for the Infranet Enforcer, the Infranet Enforcer, and networks where your endpoints are located. For example, if you create an IPsec routing policy that uses IPsec on an entire network range (such as /0) for your protected resources, be sure to specify exceptions in the same policy for the IP addresses assigned to Infranet Enforcer, Infranet Enforcer, and the endpoints. f. From the Enforcer list, select the Infranet Enforcer you configured earlier to which endpoints connect to access the resources specified in this IPsec routing policy. g. For Destination Zone, enter the name of the zone where the protected resources specified in this IPsec routing policy are located (trust is used in the example scenario). i. If you are not concerned with inter-operability with other third-party IPsec clients running on the endpoint, such as Microsoft IPsec, leave Always use UDP encapsulation and Always use a virtual adapter deselected for this example scenario. j. In the Roles section, select Policy applies to SELECTED roles, select Full Access and click Add to apply this policy to users who are mapped to the Full Access role. k. Click Save Changes by Pulse Secure, LLC. All rights reserved 48

60 Getting Started Guide Related Documentation Creating a Resource Access Policy on page by Pulse Secure, LLC. All rights reserved

61 PART 4 Administration User Authentication on page 63 User Roles on page 65 Sign-In Policy on page 67 Certificates on page 69 RADIUS on page 73 Resource Access Policy on page 77 Junos Enforcer on page 79 ScreenOS Enforcer on page by Pulse Secure, LLC. All rights reserved 50

62 CHAPTER 17 User Authentication Set Up User Authentication on the Pulse Policy Secure Device on page 63 Set Up User Authentication on the Pulse Policy Secure Device The Pulse Policy Secure device supports a variety of user authentication and authorization servers. To quickly set up user authentication, you can use local authentication on the Pulse Policy Secure device. There is a preconfigured local authentication server, System Local. To set up local user authentication on the Pulse Policy Secure device: 1. In the Pulse Policy Secure device admin console, select Authentication > Auth. Servers. 2. Click an Pulse Policy Secure device authentication server to which you want to add a user account, or you can use System Local. To create a new Pulse Policy Secure device authentication, choose Local Authentication from the New list, click New Server, specify a name, and click Save Changes. 3. Select the Users tab and click New. 4. Enter a username, full name, and password for the user. For example, enter testuser as a user name and abcd1234 as a password for testing this example configuration. 5. Click Save Changes. The user record is added to the Pulse Policy Secure device database. Related Documentation Set Up User Roles on the Pulse Policy Secure Device on page 65 Set Up User Role Mapping on the Pulse Policy Secure Device on page by Pulse Secure, LLC. All rights reserved 51

63 CHAPTER 18 User Roles Set Up User Roles on the Pulse Policy Secure Device on page 65 Set Up User Role Mapping on the Pulse Policy Secure Device on page 66 Set Up User Roles on the Pulse Policy Secure Device You will use two roles in the example deployment to distinguish between users who have endpoints that comply with security policies from those using endpoints that do not comply. To set up the user roles: 1. In the Pulse Policy Secure device admin console, choose Users > User Roles. 2. Click New Role and then enter Full Access as the name of the role that allows users with compliant endpoints to access the protected resources. NOTE: The Pulse Policy Secure device is configured by default to download Odyssey Access Client to endpoints. You can also install Pulse Policy Secure. 3. Click Save Changes. 4. In the Pulse Policy Secure device admin console, select Users > User Roles to create a second role. 5. Click New Role and then enter Quarantine as the name of the role that denies users who attempt access with non-compliant endpoints. Related Documentation Set Up User Role Mapping on the Pulse Policy Secure Device on page 66 Preconfigure Odyssey Access Client for Endpoint Download on page 39 Configure Pulse Policy Secure for Endpoint Download on page by Pulse Secure, LLC. All rights reserved 52

64 Getting Started Guide Set Up User Role Mapping on the Pulse Policy Secure Device After you set up the two roles, map the user testuser to those roles. To set up role mapping: 1. In the Pulse Policy Secure device admin console, select Users > User Realms. 2. Create a new test realm: a. On the User Authentication Realms page, click New. b. Enter a name to label this realm (such as testrealm) and optionally a description. c. Select System Local or the authentication server that you configured from the Authentication list. d. Select None from the Directory/Attribute list. e. Select None from the Accounting list. f. Click Save Changes. 3. On the Role Mapping tab for testrealm: a. Click New Rule. b. For Rule Based on, select Username. c. Under Rule: If username, enter testuser. 4. Under then assign these roles, select Full Access role, then click Add. 5. Select the Quarantine role, then click Add. 6. Click Save Changes. Related Documentation Set Up User Roles on the Pulse Policy Secure Device on page 65 Create a Sign-In Policy on page 67 Host Checker on page by Pulse Secure, LLC. All rights reserved

65 CHAPTER 19 Sign-In Policy Create a Sign-In Policy Create a Sign-In Policy on page 67 A sign-in policy is associated with the Web page (sign-in page) that users see when first logging in the Pulse Policy Secure device with the URL that you provide. To create a user sign-in policy: 1. In the admin console, select Authentication > Signing in > Sign-in Policies. 2. To create a new sign-in policy, click New URL and select Users. 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 hostname of the Pulse Policy Secure device, and <path> is any string users must enter. For example */testsite/. 4. (Optional) Enter a Description for the policy. 5. In the Sign-in Page list, select Default Sign-in Page. 6. Under Available realms, select the testrealm that you created. 7. Under Authentication protocol set, select 802.1X, (even if you are not using 802.1X). 8. Click Save Changes. Related Documentation Set Up User Role Mapping on the Pulse Policy Secure Device on page by Pulse Secure, LLC. All rights reserved 54

66 CHAPTER 20 Certificates Validate the Pulse Policy Secure Device Certificate on page 69 Setting Up and Using OpenSSL on page 70 Validate the Pulse Policy Secure Device Certificate Whenever users install a Pulse Secure client by accessing the Pulse Policy Secure device through a Web browser, the Validate server certificate option is automatically selected. When this option is enabled, Odyssey Access Client or Pulse Policy Secure validates the server certificate of the Pulse Policy Secure device. The Pulse Secure client is automatically configured to trust the Pulse Policy Secure device if it can verify that the Pulse Policy Secure device is passing a valid certificate. For this verification to occur, the trusted root certificate of the CA that signed the Pulse Policy Secure device server certificate must be installed on the endpoint. If the CA certificate is not installed, the use cannot be authenticated. You can instal the trusted root CA certificate on the endpoint in one of three ways: You can use a CA certificate that is chained to a root certificate that is already installed on the endpoint, such as VeriSign. Users or you can import the CA certificate on the endpoint using Internet Controller or other Microsoft Windows tools through whatever method your organization uses to distribute root certificates. You can upload the CA certificate and any intermediate CA certificates to the Pulse Policy Secure device. During installation, the Pulse Policy Secure device automatically installs the CA certificates on the endpoint. When prompted during installation, the user must allow installation of the CA certificate. To upload CA certificates to the Pulse Policy Secure device: 1. In the admin console, select System > Configuration > Certificates > Trusted Server CAs. 2. Click Import Trusted Server CA. 3. Browse to the CA certificate to upload to the Pulse Policy Secure device, and click Import Certificate by Pulse Secure, LLC. All rights reserved 55

67 Getting Started Guide Related Documentation Preconfigure Odyssey Access Client for Endpoint Download on page 39 Configure Pulse Policy Secure for Endpoint Download on page 43 Setting Up and Using OpenSSL If you do not have a CA, follow the instructions in this chapter to use OpenSSL on Windows to create a CA certificate and sign the CSR for the server certificate. NOTE: This topic describes how to use OpenSSL to create the CA certificate for the Infranet Enforcer and sign the CSR for the Pulse Policy Secure device server certificate. You can also use OpenSSL to create a trusted root CA certificate to validate the Odyssey Access Client and Pulse Policy Secure certificate of the Pulse Policy Secure device. Use the instructions in this section to create a CA certificate and to sign the CSR for the Pulse Policy Secure device server certificate. To set up and use OpenSSL: 1. Download and install OpenSSL from this site: 2. At the Windows command prompt, type the following commands: cd \openssl md certs cd certs md democa md democa\newcerts edit democa\index.txt 3. Press ALT-F and then the S key to save the file. 4. Press ALT-F and then the X key to exit the editor. 5. At the Windows command prompt, type the following command: edit democa\serial 6. Type the following value in the document window: Press ALT-F and then the S key to save the file. 8. Press ALT-F and then the X key to exit the editor. 9. At the Windows command prompt, type the following command: set path=c:\openssl\bin;%path% 10. To create a CA key, type the following command at the Windows command prompt in the c:\openssl\certs directory: openssl genrsa -out ca.key 1024 The following output appears: by Pulse Secure, LLC. All rights reserved

68 Chapter 20: Certificates Loading 'screen' into random state - done Generating RSA private key, 1024 bit long modulus e is (0x To create a CA certificate, type the following command at the Windows command prompt in the c:\openssl\certs directory: openssl req -new -x509 -days 365 -key ca.key -out democa/cacert.pem 12. Enter the appropriate distinguished name (DN) information for the CA certificate. You can leave some fields blank by entering a period(.). Country Name: US State or Province Name: CA Locality Name: Sunnyvale Organization Name: XYZ Org. Unit Name: IT Common Name: ic.xyz.com Address: user@xyz.com 13. To create and sign a CSR, Create a certificate signing request (CSR) for a server certificate select System > Configuration > Certificates > Device Certificates on the Pulse Policy Secure device admin console: a. Click New CSR. b. Enter the required information. NOTE: The Organization Name in the CSR must match the CA certificate's Organization Name. If the Organization Names do not match, you cannot sign the CSR. c. Click Create CSR. d. Select and copy all of the text in the text box under Step 1 into a text editor, and save the text file as: c:\openssl\certs\ic.csr e. To sign the certificate, type the following command at the Windows command prompt in the c:\openssl\certs directory: openssl ca -in ic.csr -out ic.crt -keyfile ca.key f. Type Y to sign the certificate. g. Type Y to commit the certificate. You are now ready to import the server certificate into the Pulse Policy Secure device and the CA certificate into the Infranet Enforcer. Related Documentation Setting Up Certificates for the Pulse Policy Secure Device and the Junos Enforcer on page by Pulse Secure, LLC. All rights reserved 57

69 Getting Started Guide Setting Up Certificates for the Pulse Policy Secure Device and Infranet Enforcer on page by Pulse Secure, LLC. All rights reserved

70 CHAPTER 21 RADIUS Using RADIUS Attribute to Specify VLANs for Endpoints on page 73 Using RADIUS Attribute to Specify VLANs for Endpoints A RADIUS packet contains values called attributes. The specific attributes in each packet depend on the NAD or RADIUS server that sent it. Different kinds of NADs require different attributes to control their behavior. A return list is a set of attributes that the Pulse Policy Secure device returns to the NAD after authentication succeeds. The return list usually provides additional parameters that the NAD needs to complete the connection. Return list attributes are authorization configuration parameters. You can configure a RADIUS attributes policy in the Pulse Policy Secure device to send return list attributes to an 802.1X NAD. For example, you can specify which VLAN endpoints must use to access the network. You can also configure other functions on a NAD's port based on the role assigned to the user who is currently using that port. For example, a particular switch might let you use return list attributes to configure Quality of Service (QoS) functions (Bandwidth and/or Priority) on the device's port based on the current user's role. You can select RADIUS attributes by name from a predefined list. For each attribute, you specify values using strings or numbers. NOTE: Be sure to select the correct make and model of the NAD. During authentication, the Pulse Policy Secure device filters the return list based on the dictionary for the NAD that sent the authentication request. The Pulse Policy Secure device omits any return list attribute that is not valid for the device. You can use RADIUS attributes to specify which VLAN endpoints must use to access the network. You can also specify how endpoints to which the RADIUS attributes policy is applied must communicate with the Pulse Policy Secure device once they are on the network. Figure 7 on page 74an example of using a RADIUS attributes policy to specify VLANs for endpoints by Pulse Secure, LLC. All rights reserved 59

71 Getting Started Guide Figure 7: Using a RADIUS Attributes Policy to Specify VLANs Because this example scenario uses only two VLANs on the NADs, you can connect the Pulse Policy Secure device internal interface to one VLAN, and the Pulse Policy Secure device external interface to the other VLAN. You must also configure one RADIUS attributes policy with the internal option and another RADIUS attributes policy with the External option to specify the VLANs that must connect to each interface. The following sections describe how to configure two RADIUS attributes policies for the two VLANs shown Figure 7 on page 74. One policy is named Full Access and the other is named Quarantine. In the Full Access policy, you specify VLAN 1, select the internal option to specify the Pulse Policy Secure device internal interface, and select the Full Access role. In the Quarantine policy, you specify VLAN 655, select the External option to specify the Pulse Policy Secure device external interface, and select the Quarantine role. When an endpoint is assigned VLAN 1 through the Full Access policy, it connects by using the IP address of the Pulse Policy Secure device s internal interface. Users on VLAN 1 have full network access. When an endpoint is assigned VLAN 655 through the Quarantine policy, it connects by using the IP address of the Pulse Policy Secure device s external interface. Users on VLAN 655 can access only a remediation server Because User 1 is authenticated and the endpoint complies with Host Checker security policies, the user is assigned a role on the Full Access VLAN that allows him full network access and access to protected resources. Although User 2 is authenticated, the endpoint does not comply with Host Checker security policies therefore, the user is assigned a role on the Quarantine VLAN that allows access only to a remediation server. In this example deployment scenario shown in Figure 7 on page 74, the Pulse Policy Secure device uses the network in Network Settings on page 17 for the internal and external ports by Pulse Secure, LLC. All rights reserved

72 Chapter 21: RADIUS Change the settings by selecting System > Network Settings > Internal Port > Settings and System > Network Settings > External Port > Settings. Table 7: Pulse Policy Secure device network interface port settings Internal port network settings: External port network settings: IP address: IP address: Network mask: Network mask: Gateway IP: Gateway IP: Link speed: Auto Link speed: Auto Primary DNS server: Primary DNS server: DNS domain(s): localhost DNS domain(s): localhost Related Documentation Configuring RADIUS Client Policies on page by Pulse Secure, LLC. All rights reserved 61

73 CHAPTER 22 Resource Access Policy Creating a Resource Access Policy Creating a Resource Access Policy on page 77 An Infranet Enforcer resource access policy specifies which users are allowed or denied access to a set of protected resources. You specify which users to allow or deny access by choosing the roles for each Infranet Enforcer resource access policy. For this example scenario, these instructions show how to provide all users access to the /24 network when they are signed in. To create a resource access policy: 1. In the Infranet Enforcer admin console, select Pulse Policy Secure > Infranet Enforcer > Resource Access. 2. Click New Policy. 3. On the New Policy page: a. For Name and Description, enter any name and description for this policy, such as FinanceServer. b. For Resources, specify the protocol, IP address, network mask, and port of each resource (or range of addresses) for which this Infranet Enforcer resource access policy applies, one per line. You cannot specify a hostname in an Infranet Enforcer resource access policy. You can specify only an IP address. You can use TCP, UDP, or ICMP. For example, type: /24 to specify the protected resources on the trust interface of the Infranet Enforcer. c. In the Infranet Enforcer section, add the Enforcer you created to the selected Enforcers box. d. In the Roles section, select Policy applies to SELECTED roles, select Full Access, and click Add to apply this resource access policy to users who are mapped to the Full Access role. e. In the Action section, select Allow access. 4. Click Save Changes. Related Documentation Introduction to the Junos Enforcer on page 23 Introduction to the ScreenOS Enforcer on page by Pulse Secure, LLC. All rights reserved 62

74 Getting Started Guide CHAPTER 23 Junos Enforcer Setting Up the Interfaces and Security Zones on the Junos Enforcer on page 79 Synchronizing the Time on the Junos Enforcer and the Pulse Policy Secure Device on page 80 Setting Up Certificates for the Pulse Policy Secure Device and the Junos Enforcer on page 80 Setting Up the Pulse Policy Secure Device on the Junos Enforcer on page 81 Setting Up the Interfaces and Security Zones on the Junos Enforcer You must define at least two security zones to protect one area of the network from the other. Figure 8 on page 79 illustrates these security zones. Figure 8: Security Zones From the perspective of security policies, traffic enters into one security zone and exits through another security zone. This combination of a from-zone and a to-zone is called a context. Security zones are the building blocks for policies. They are logical entities to which one or more interfaces are bound. Security zones provide a means of distinguishing groups of hosts (user systems and other hosts, such as servers) and their resources from one another to apply different security measures to them by Pulse Secure, LLC. All rights reserved 63

75 Getting Started Guide Follow these steps to set up the interfaces on the Junos Enforcer for this example scenario. 1. To configure the interface and its IP address for the trust zone, type the following statement in Edit mode: set interfaces ge-0/0/1 unit 0 family inet address /24 2. To configure the trust zone and assign the interface to it, type the following statement in Edit mode: user@host# set security zones security-zone trust interfaces ge-0/0/ To configure the interface and its IP address for the untrust zone, type the following statement in Edit mode: user@host# set interfaces ge-0/0/1 unit 0 family inet address /24 4. To configure the untrust zone and assign the interface to it, type the following statement in Edit mode: user@host# set security zones security-zone untrust interfaces ge-0/0/1.0 Related Documentation Synchronizing the Time on the Junos Enforcer and the Pulse Policy Secure Device on page 80 Synchronizing the Time on the Junos Enforcer and the Pulse Policy Secure Device Ensure the time settings on both appliances are no more than 2 minutes apart and be sure to use the same time zone. See the Junos OS Administration Library for Routing Devices for instructions on setting up Network Time Protocol (NTP). Related Documentation Setting Up Certificates for the Pulse Policy Secure Device and the Junos Enforcer on page 80 Setting Up the Pulse Policy Secure Device on the Junos Enforcer on page 81 Configuring the Pulse Policy Secure Device to Connect to the Junos Enforcer on page 51 Setting Up Certificates for the Pulse Policy Secure Device and the Junos Enforcer NOTE: Certificate validation from the Pulse Policy Secure is optional. To provide certificate trust from the Pulse Policy Secure: 1. If you do not have one already, obtain the CA (Certificate Authority) certificate that signed the Pulse Policy Secure device server certificate to load on the Junos Enforcer. 2. Import the CA certificate into the Junos Enforcer. 3. Specify the CA certificate to be used to verify the Pulse Policy Secure device. For instructions on importing a CA certificate to verify the Pulse Policy Secure device. See the Junos OS CLI Reference and Junos OS Initial Configuration Guide for Security Devices. For instructions on how to import the server certificate into the Pulse Policy Secure device see Certificate Security Administration by Pulse Secure, LLC. All rights reserved

76 Chapter 23: Junos Enforcer Related Documentation Setting Up the Pulse Policy Secure Device on the Junos Enforcer on page 81 Setting Up the Pulse Policy Secure Device on the Junos Enforcer This example describes a configuration with the Pulse Policy Secure device on the untrust interface side (the same side as endpoints). See the Junos OS CLI Reference and the Junos OS Initial Configuration Guide for Security Devices for more detailed information. To configure the Junos Enforcer: 1. Ensure that the DHCP server is disabled or enabled as required for the deployment. For instructions on setting up DHCP, see the Junos OS Administration Library for Routing Devices. 2. Create an instance of the Pulse Policy Secure device on the Junos Enforcer and provide the network information required for connecting through the CLI. This information includes the Pulse Policy Secure device host name, IP address, and the interface to which the device connects. The default port for communication with the Pulse Policy Secure device is (You cannot change the port.) You must also specify a password, which must match the password configured on the Pulse Policy Secure device. To create an Pulse Policy Secure instance on the Junos Enforcer: a. Type the Pulse Policy Secure device s hostname. user@host# set services unified-access-control infranet-controller hostname b. Type the Pulse Policy Secure device s IP address. user@host# set services unified-access-control infranet-controller hostname address ip-address c. Type the Junos interface to which the Pulse Policy Secure device connects. user@host# sset services unified-access-control infranet-controller hostname interface interface-name d. Type the password that the SRX Series or J Series device must use to initiate secure communications with the Pulse Policy Secure device. user@host# set services unified-access-control infranet-controller hostname password password See the Junos OS CLI Reference for complete CLI instructions and syntax. 3. Set the appropriate timeout and interval values, and specify a timeout action. The timeout that you set specifies the amount of time beyond which the Junos Enforcer attempts to reconnect with the Pulse Policy Secure device if no communication is received. The interval specifies how often the Pulse Policy Secure device sends a heartbeat to the Junos Enforcer. 4. Verify routing from the Pulse Policy Secure device to the untrust interface. When you finish configuring the Pulse Policy Secure device instance, the Junos Enforcer can initiate the connection with the Pulse Policy Secure device. Optionally, the Junos Enforcer validates the IC 2014 by Pulse Secure, LLC. All rights reserved 65

77 Getting Started Guide Series device server certificate if so configured. The device sends the serial number to authenticate with the Pulse Policy Secure device. For the Junos Enforcer to establish communication, you must configure the Junos Enforcer on the Pulse Policy Secure device. Related Documentation Configuring the Pulse Policy Secure Device to Connect to the Junos Enforcer on page 51 Configuring a Security Policy for Source IP Enforcement on page by Pulse Secure, LLC. All rights reserved

78 CHAPTER 24 ScreenOS Enforcer Setting Up the Interfaces on ScreenOS on page 83 Set the Time on the Pulse Policy Secure Device and ScreenOS Enforcer on page 83 Setting Up Certificates for the Pulse Policy Secure Device and Infranet Enforcer on page 84 Setting Up the Pulse Policy Secure Device Instance on the ScreenOS Enforcer on page 86 Setting Up the Interfaces on ScreenOS To set up the interfaces on the ScreenOS Enforcer: 1. Log in to the ScreenOS Enforcer serial console. 2. Type the following CLI commands to set the IP address and zone membership for the two interfaces in the example scenario. set interface ethernet1/1 zone trust set interface ethernet1/1 ip set interface ethernet1/2 zone untrust set interface ethernet1/2 ip set interface ethernet1/2 manage ssl set interface ethernet1/2 manage ssh set interface ethernet1/2 ip manageable NOTE: To configure an Infranet Enforcer from the untrust zone, you must first enable manageability for the untrust zone on that Infranet Enforcer. For more information, see series/product/ Related Documentation Introduction to the ScreenOS Enforcer on page 27 Set the Time on the Pulse Policy Secure Device and ScreenOS Enforcer on page 83 Set the Time on the Pulse Policy Secure Device and ScreenOS Enforcer Setting the time on the IV Series device and the Infranet Enforcer is critical because the Pulse Policy Secure device uses digital certificates to secure communication with the Infranet Enforcer by Pulse Secure, LLC. All rights reserved 67

79 Getting Started Guide NOTE: Ensure that the time settings on both appliances are no more than two minutes apart, and be sure to use the same time zone. Otherwise, the IC Infranet Enforcer cannot validate the Infranet Pulse Policy Secure device server certificate, and a connection cannot occur between the appliances. To set the time on the Pulse Policy Secure device: 1. In the admin console, select System > Status > Overview. 2. In the System Date & Time section, click Edit. 3. Select a time zone from the Time Zone menu. The Pulse Policy Secure device automatically adjusts the time for daylight saving time. 4. Select one of these methods to set the time: Use NTP server Enter the server s IP address or name, and specify an update interval. Set Time Manually Enter values for the date and time. You can also click Get from Browser to fill in the Date and Time fields. (If you click Get from Browser, be sure to also get the time from the client when setting the date and time on the Infranet Enforcer.) 5. Click Save Changes. To set the time on the ScreenOS Enforcer: 1. In the Infranet Enforcer Web UI, select Configuration >Date/Time. 2. Select a method for setting the time, and then click Apply. Related Documentation Setting Up the Pulse Policy Secure Device Instance on the ScreenOS Enforcer on page 86 Configuring the Access Control Service to Connect to the ScreenOS Enforcer on page 57 Setting Up Certificates for the Pulse Policy Secure Device and Infranet Enforcer For the Pulse Policy Secure device to allow communications with the ScreenOS Enforcer, you must do all of the following steps: 1. If you do not have one already, create a CA certificate to load on the Infranet Enforcer. 2. Create a CSR for an Infranet Enforcer server certificate, and use the CA certificate to sign the server certificate. 3. Import the server certificate into the Pulse Policy Secure device. 4. Import the CA certificate into the ScreenOS Enforcer. If the server certificate or CA certificate is missing or expired, the ScreenOS Enforcer does not allow communications with the Pulse Policy Secure device. Note also that the ScreenOS Enforcer does not accept the temporary self-signed certificate that the Pulse Policy Secure device created during initialization by Pulse Secure, LLC. All rights reserved

80 Chapter 24: ScreenOS Enforcer To set up certificates for the ScreenOS Enforcer and Pulse Policy Secure device: 1. If you do not have a certificate authority, install and use OpenSSL to generate a CA certificate. 2. Create a CSR for a server certificate by selecting the System > Configuration > Certificates > Device Certificates in the Pulse Policy Secure device admin console. a. Click Create CSR. b. Enter the required information. NOTE: The organization name in the CSR must match the CA certificate's organization name. If the organization names do not match, you cannot sign the CSR. c. Click Create CSR. 3. Sign the CSR by using your either your CA OpenSSL. For information on using OpenSSL to sign the request 4. Select System > Configuration > Certificates > Device Certificates to import the signed server certificate created from the CSR into the Pulse Policy Secure device. a. Under Certificate Signing Requests, click the Pending CSR link that corresponds to the signed certificate. b. Under Step 2: Import signed certificate, browse to the certificate file you received from the CA. For example: c:\openssl\certs\ic.crt c. Click Import. 5. By default, the signed server certificate is automatically associated with the internal port on the Infranet Enforcer. To associate the certificate with an external or virtual port: a. Select System > Configuration > Certificates > Device Certificates, and click the link that corresponds to a certificate that you want to use. b. Under Present certificate on these ports, specify the ports that the Infranet Enforcer must associate with the certificate. You can choose internal or external ports and primary or virtual ports, but you cannot choose a port that is already associated with another certificate. c. Click Save Changes. 6. Import the certificate of the CA that signed the Pulse Policy Secure device s server certificate into the Infranet Enforcer: a. In the Infranet ScreenOS WebUI, select Objects > Certificates. b. Select CA from the Show menu by Pulse Secure, LLC. All rights reserved 69

81 Getting Started Guide c. Click Browse, browse and select the CA certificate (such as c:\openssl\certs\democa\cacert.pem), and then click Load. d. Select CA from the Show menu to display the CA certificate. e. To configure the CA certificate, click Server Settings next to the certificate. For information about the settings, see the Pulse Secure Access Control Administration Guide. NOTE: If you are not using CRL certificate checking, be sure to disable it on the CA Server Settings page. 7. Click OK to save the settings. NOTE: If you later import a different server certificate and CA certificate, you may need to initiate a new connection to use them by selecting Maintenance > System > Platform and then Restart Services in the Pulse Policy Secure device admin console. The Infranet Enforcer connects to the Pulse Policy Secure device and validates the new certificate. Related Setting Up and Using OpenSSL on page 70 Documentation Setting Up the Pulse Policy Secure Device Instance on the ScreenOS Enforcer on page 86 Configuring the Access Control Service to Connect to the ScreenOS Enforcer on page 57 Setting Up the Pulse Policy Secure Device Instance on the ScreenOS Enforcer To set up the Pulse Policy Secure device instance on the Infranet Enforcer: 1. If you have not already done so, select and load the CA on the Infranet Enforcer. 2. Create the Pulse Policy Secure device instance on the Infranet Enforcer: a. Select Configuration > Infranet Auth > Controllers, and click New. b. For Infranet Enforcer Instance, type: ic.xyz.com. c. For IP /Domain Name, type: d. For Port, type: The port number must be 11122, which is the default port for NACN. e. For Timeout, type: 60 f. For Source Interface, choose the interface to which the Infranet Enforcer is connected. For example, ethernet 1/ by Pulse Secure, LLC. All rights reserved

82 Chapter 24: ScreenOS Enforcer g. For Password, enter a Netscreen Address Change Notification (NACN) password; for example: xyz123. The Infranet Enforcer uses the NACN password when connecting to the Infranet Enforcer. You must specify the same NACN password on the Pulse Policy Secure device. h. From the Selected CA menu, select the CA certificate you loaded on the Infranet Enforcer. For example: =user@xyz.com,CN=ic.xyz.com,OU=IT,O=XYZ,L=Sun. i. Leave Full Subject Name of IC Cert blank. j. Click OK. 3. If you see a warning message that SSH is currently not enabled, click OK. This enables SSH so that the Pulse Policy Secure device can communicate with the Infranet Enforcer. Related Documentation Configuring the Access Control Service to Connect to the ScreenOS Enforcer on page by Pulse Secure, LLC. All rights reserved 71

83 Getting Started Guide PART 5 Troubleshooting Device Connection on page 91 Host Checker Policy on page by Pulse Secure, LLC. All rights reserved 72

84 CHAPTER 25 Device Connection Testing the Connection Testing the Connection on page 91 This topic describes how you can test that the configuration you have completed up to this point is working correctly. To check the connection between the Pulse Policy Secure device and the Infranet Enforcer, select System > Status > Overview in the admin console. If the connection is successful, a green dot appears next to the Infranet Enforcer icon under Enforcer Status. The Infranet Enforcer IP address also appears on the Connection page in the admin console. The instructions in this section describe how to verify that the Infranet Enforcer is protecting a resource, such as the Finance Server in the /24 network that you specified in the Infranet Enforcer resource access policy. To test the Infranet Enforcer resource access policy: 1. If you are signed in to the Pulse Policy Secure device through Odyssey Access Client or Pulse, exit the client. 2. Open a command prompt window and type the following command: ping This IP address is based on the example network configuration. Change the IP address to match your protected resource if it is different. You cannot ping this resource because you are not signed in, and because it is protected by the Infranet Enforcer. 4. Enter the Pulse Policy Secure device IP address in a Web browser. For example, 5. After Odyssey Access Client or Pulse installs (if they are not already installed) enter the test user credentials at the prompt. 6. In the command prompt window, type the ping command again: ping Notice that the first few ping requests time out, but after that the ping responses occur. This means that the IPsec connection is established between the endpoint and the Infranet Enforcer. When the IPsec connection occurs, you can ping the protected resource. If your protected resource is a Web server, you can also use a web browser to access it whenever you are logged in. Related Documentation Configuring the Access Control Service to Connect to the ScreenOS Enforcer on page by Pulse Secure, LLC. All rights reserved

85 CHAPTER 26 Host Checker Policy Test the Host Checker Policy and Remediation on page 93 Test the Host Checker Policy and Remediation This section describes how to verify that the Host Checker policy you configured is requiring users to run Notepad. To test the Host Checker security policy and remediation: 1. Make sure Notepad is not running on your endpoint computer. 2. Click the Odyssey Access Client icon in the system tray. 3. In the Odyssey Access Client window, select the entry for the Pulse Policy Secure device test site URL under the Pulse Policy Secure heading. 4. To display the remediation instructions, click How do I resolve this problem? under Connection Information. See Figure 9 on page 94. NOTE: When you click the link you will see a message like Figure 10 on page by Pulse Secure, LLC. All rights reserved 74

86 Getting Started Guide Figure 9: Odyssey Access Client Remediation Instructions Display The Odyssey Integrity Status remediation window appears with the custom instructions you configured earlier in the Host Checker policy by Pulse Secure, LLC. All rights reserved

87 Chapter 26: Host Checker Policy Figure 10: Odyssey Integrity Status Remediation Instructions 5. Start Notepad on your endpoint computer. 6. Click Try Again in the Odyssey Integrity Status remediation window. Odyssey Access Client evaluates the Host Checker policy again. Because you started Notepad, the message Your computer meets the security policies is displayed under Connection Information in the Odyssey Access Client Manager window. This message indicates that your computer meets the requirements of the Host Checker policy. You are now assigned the Full Access role. See Figure 11 on page by Pulse Secure, LLC. All rights reserved 76

88 Getting Started Guide Figure 11: Odyssey Access Client Connected by Pulse Secure, LLC. All rights reserved

89 Chapter 26: Host Checker Policy If you are using Pulse Policy Secure, the same behavior is exhibited by Pulse Secure, LLC. All rights reserved