Pulse Policy Secure. Access Control in the Federated Enterprise Using IF-MAP Network Configuration Example. Product Release 5.2

Transcription

1 Pulse Policy Secure Access Control in the Federated Enterprise Using IF-MAP Network Configuration Example Product Release 5.2 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 Access Control in the Federated Enterprise Using IF-MAP Network Configuration Example 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 by Pulse Secure, LLC. All rights reserved

3 Table of Contents About the Documentation... xiii Documentation and Release Notes... xiii Supported Platforms... xiii Documentation Conventions... xiii Documentation Feedback... xv Requesting Technical Support... xvi Self-Help Online Tools and Resources... xvi Opening a Case with PSGSC... xvi Part 1 Overview Chapter 1 Solution Components... 3 Solution Example Overview: User Experience and Security Objectives for a Federated Enterprise Network... 3 Local Access... 4 Remote Access... 5 Resource Access... 5 Federated Access... 5 Chapter 2 Component Versions... 7 Software Versions Used in this Example... 7 Chapter 3 Component Topology... 9 Solution Example Topology: Pulse Secure Access Solutions for a Federated Enterprise Network... 9 Component Topology... 9 Local Access: 802.1x Network Access Control Remote Access: Pulse Connect Secure SSL VPN Resource Access: Pulse Policy Secure Federation Odyssey Access Client Software Pulse Secure Client Software Part 2 Configuration Chapter 4 Local Network Access Policy Deployments Campus 802.1x and DHCP Deployment Deployment Diagram Layer 2 Switch Configuration Pulse Policy Secure Configuration by Pulse Secure, LLC. All rights reserved 1

4 DHCP Server Configuration Branch 802.1x and DHCP Deployment Deployment Diagram Layer 2 Switch Configuration Pulse Policy Secure Configuration DHCP Server Configuration Chapter 5 Remote Access Policy Deployment Pulse Connect Secure User Access Management Framework Overview User Roles Authentication Server User Authentication Realm Network Connect Connection Profile Sign-In Policy Complete Configuration Chapter 6 User Access Management Framework Campus Pulse Policy Secure User Access Management Framework Overview User Roles Authentication Server User Authentication Realm Sign-In Policy Complete Configuration Branch Pulse Policy Secure User Access Management Framework Overview User Roles Authentication Server User Authentication Realm Sign-In Policy Complete Configuration Chapter 7 Resource Access Policy Deployments Campus Resource Access Policy Enforcement Deployment Deployment Diagram SRX Series Configuration Pulse Policy Secure Configuration Branch Resource Access Policy Enforcement Deployment Deployment Diagram SSG Series Configuration Pulse Policy Secure Configuration Chapter 8 IF-Map Federation IF-MAP Deployment Overview Pulse Policy Secure IF-MAP Server Configuration Pulse Policy Secure IF-MAP Client Configuration Pulse Secure Access Service IF-MAP Client Configuration iv 2015 by Pulse Secure, LLC. All rights reserved

5 Table of Contents Part 3 Administration Chapter 9 Local Sessions Reviewing 802.1x Network Access Logs Chapter 10 Remote Sessions Reviewing SSL VPN Access Logs Chapter 11 Federated Sessions Reviewing IF-MAP Logs by Pulse Secure, LLC. All rights reserved v

6 List of Figures Part 1 Overview Chapter 1 Solution Components... 3 Figure 1: Federated Enterprise Network with Employees Located in Campus, Branch, and Home Offices... 4 Chapter 3 Component Topology... 9 Figure 2: Network Deployment Supporting Users in Campus, Branch, and Home Offices Part 2 Configuration Chapter 4 Local Network Access Policy Deployments Figure 3: Campus 802.1x Deployment Figure 4: HP Procurve Web UI: Configuration > VLAN Configuration Figure 5: Pulse Policy Secure: UAC > Network Access > Location Group Figure 6: Pulse Policy Secure: UAC > Network Access > RADIUS Client Figure 7: Pulse Policy Secure: UAC > Network Access > RADIUS Return Attributes Policies Figure 8: ScreenOS Web UI: Network > Interfaces Figure 9: ScreenOS Web UI: Network > DHCP Figure 10: ScreenOS Web UI: Network > DHCP > DHCP Server Address Edit Figure 11: Branch 802.1x Deployment Figure 12: J-Web UI: Point and Click CLI > protocols > dot1x Figure 13: J-Web UI: Point and Click CLI > access > dot1x > authenticator Figure 14: J-Web UI: Point and Click CLI > access > radius-server Figure 15: J-Web UI: Configure > Switching > VLAN Figure 16: Pulse Policy Secure: UAC > Network Access > Location Group Figure 17: Pulse Policy Secure: UAC > Network Access > RADIUS Client Figure 18: Pulse Policy Secure: UAC > Network Access > RADIUS Return Attributes Policies Figure 19: ScreenOS Web UI: Network > Interfaces Figure 20: ScreenOS Web UI: Network > DHCP Figure 21: ScreenOS Web UI: Network > DHCP > DHCP Server Address List Chapter 5 Remote Access Policy Deployment Figure 22: Pulse Connect Secure User Access Management Framework Figure 23: Pulse Connect Secure: Users > User Roles Figure 24: Pulse Connect Secure: Users > User Roles by Pulse Secure, LLC. All rights reserved vii

7 Figure 25: Pulse Connect Secure: Users > User Roles > Enterprise > Network Connect Figure 26: Pulse Connect Secure: Users >User Roles > Enterprise > Restrictions > Host Checker Figure 27: Pulse Connect Secure: Users > User Roles Figure 28: Pulse Connect Secure: Authentication > Auth Servers > AD Server Figure 29: Pulse Connect Secure: Users > User Realms Figure 30: Pulse Connect Secure: Users > User Authentication Realms Figure 31: Pulse Connect Secure SSL VPN Connection Figure 32: Pulse Connect Secure: Users > Resource Policies > Network Connect Connection Profiles Figure 33: Pulse Secure Access Service: Authentication > Signing In Chapter 6 User Access Management Framework Figure 34: Pulse Policy Secure User Access Management Framework Figure 35: Pulse Policy Secure: Users > User Roles Figure 36: Pulse Access Control Service: Users > User Roles > Enterprise > Restrictions > Host Checker Figure 37: Pulse Policy Secure: Authentication > Auth. Servers Figure 38: Pulse Policy Secure: Users > User Authentication Realms Figure 39: Pulse Policy Secure: Users > User Authentication Realms > Role Mapping Figure 40: Pulse Policy Secure: Authentication > Signing In > Sign-in Policies Figure 41: Pulse Policy Secure: Authentication > Signing In > Authentication Protocol Sets Figure 42: Pulse Policy Secure User Access Management Framework Figure 43: Pulse Policy Secure: Users > User Roles Figure 44: Pulse Policy Secure: Users > User Roles > Enterprise > General > Restrictions > Host Checker Figure 45: Pulse Policy Secure: Authentication > Auth. Servers > New Active Directory Server > AD Server Figure 46: Pulse Policy Secure: Users > User Authentication Realms Figure 47: Pulse Policy Secure: Users > User Authentication Realms > Role Mapping Figure 48: Pulse Policy Secure: Authentication > Signing In > Sign-In Policies Figure 49: Pulse Policy Secure: Authentication > Signing In > Authentication Protocol Sets Chapter 7 Resource Access Policy Deployments Figure 50: Campus Resource Access Policy Enforcement Deployment Figure 51: J-Web UI: Point and Click CLI > services > unified-access-control Figure 52: J-Web UI: Point and Click CLI > security > policies > policy > untrust-trust Figure 53: Pulse Policy Secure: UAC > Infranet Enforcer > Connection Figure 54: Pulse Policy Secure: UAC > System > Status Figure 55: Pulse Policy Secure: UAC > Infranet Enforcer > Resource Access Policies 68 viii 2015 by Pulse Secure, LLC. All rights reserved

8 List of Figures Figure 56: Branch Resource Access Policy Enforcement Deployment Figure 57: ScreenOS Web UI: Configuration > Infranet Auth > Controllers Figure 58: ScreenOS Web UI: Configuration > Infranet Auth > General Settings Figure 59: ScreenOS Web UI: Policy > Policies (From Untrust to Trust) > Advanced Policy Settings Figure 60: Pulse Policy Secure: UAC > Infranet Enforcer > Connection Figure 61: Pulse Policy Secure: UAC > Infranet Enforcer > Enforcer Policies Figure 62: Pulse Policy Secure: UAC > Infranet Enforcer > Resource Access Policies 74 Chapter 8 IF-Map Federation Figure 63: IF-MAP Deployment Figure 64: Federated Access Service Devices Figure 65: Pulse Policy Secure: System > IF-MAP Federation > Overview Figure 66: Pulse Policy Secure: System > IF-MAP Federation > This Server Figure 67: Pulse Policy Secure: System > IF-MAP Federation > IF-MAP Client Figure 68: Pulse Policy Secure: System > IF-MAP Federation > IF-MAP Client Figure 69: Pulse Policy Secure: System > IF-MAP Federation > Session-Export Policy Figure 70: Pulse Policy Secure: System > IF-MAP Federation > Session-Import Policy Figure 71: Pulse Policy Secure: System > IF-MAP Federation > Overview Figure 72: Pulse Policy Secure: System > IF-MAP Federation > Session-Export Policy Figure 73: Pulse Policy Secure: System > IF-MAP Federation > Session-Import Policy Figure 74: Pulse Secure Access Service: System > IF-MAP Federation > Overview 87 Figure 75: Pulse Secure Access Service: System > IF-MAP Federation > Session- Export Policy Part 3 Administration Chapter 9 Local Sessions Figure 76: Odyssey Access Client Figure 77: ipconfig Figure 78: Odyssey Access Client Figure 79: ipconfig Figure 80: Pulse Policy Secure: Status > Active Users Figure 81: Pulse Policy Secure: System > Log/Monitoring > User Access Figure 82: Pulse Policy Secure: System > IF-MAP Federation (Client) > Active Users > Exported by Pulse Secure, LLC. All rights reserved ix

9 Chapter 10 Remote Sessions Figure 83: Remote Host Computer: ipconfig Figure 84: Pulse Secure Client Figure 85: Remote Host Computer: ipconfig Figure 86: Pulse Connect Secure: System > Log/Monitoring > User Access Figure 87: Pulse Connect Secure: System > IF-MAP Federation (Client) > Active Users > Exported Chapter 11 Federated Sessions Figure 88: Pulse Access Control Service: System > IF-MAP Federation (Client) > Active Users > Exported Figure 89: Pulse Connect Secure: System > IF-MAP Federation (Client) > Active Users > Exported Figure 90: Web Server with IP Address Figure 91: Pulse Secure Access Control Service: System > IF-MAP Federation (Server) > Active Users > Imported Figure 92: Pulse Access Control Service: System > Log/Monitoring > User Access Figure 93: Web Server with IP Address Figure 94: Pulse Secure Access Control Service: System > IF-MAP Federation (Client) > Active Users > Imported Figure 95: Pulse Secure Access Control Service: System > Log/Monitoring > User Access Figure 96: Pulse Secure Access Control Service: System > Log/Monitoring > Events x 2015 by Pulse Secure, LLC. All rights reserved

10 List of Tables About the Documentation... xiii Table 1: Notice Icons... xiv Table 2: Text and Syntax Conventions... xiv Part 1 Overview Chapter 2 Component Versions... 7 Table 3: Software Versions Used in This Example... 7 Part 2 Configuration Chapter 4 Local Network Access Policy Deployments Table 4: Campus Switch 802.1x Configuration Table 5: Campus Policy Secure 802.1x Configuration Table 6: Campus DHCP Address Ranges Table 7: Branch Switch 802.1x Configuration Table 8: Branch Policy Secure 802.1x Configuration Table 9: Branch DHCP Address Ranges Chapter 7 Resource Access Policy Deployments Table 10: Campus UAC Enforcer Configuration Table 11: Campus Pulse Policy Secure Resource Access Policy Configuration Table 12: Branch UAC Enforcer Configuration Table 13: Branch Pulse Policy Secure Resource Access Policy Configuration Part 3 Administration Chapter 9 Local Sessions Table 14: User Access Logs Chapter 10 Remote Sessions Table 15: User Access Logs by Pulse Secure, LLC. All rights reserved xi

11 About the Documentation Documentation and Release Notes on page xiii Supported Platforms on page xiii Documentation Conventions on page xiii Documentation Feedback on page xv Requesting Technical Support on page xvi Documentation and Release Notes Supported Platforms 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. For the features described in this document, the following platforms are supported: IC Series SA Series EX Series SRX Series MAG Series Documentation Conventions Table 1 on page xiv defines notice icons used in this guide by Pulse Secure, LLC. All rights reserved xiii

12 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 xiv 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 xiv 2015 by Pulse Secure, LLC. All rights reserved

13 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 xv

14 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 2015 by Pulse Secure, LLC. All rights reserved

15 PART 1 Overview Solution Components on page 3 Component Versions on page 7 Component Topology on page by Pulse Secure, LLC. All rights reserved 1

16 CHAPTER 1 Solution Components Solution Example Overview: User Experience and Security Objectives for a Federated Enterprise Network on page 3 Solution Example Overview: User Experience and Security Objectives for a Federated Enterprise Network This example provides a concrete overview of the Pulse Secure network access services solution for the federated enterprise. The solution enforces identity-based security policies for LAN access, remote access, and resource access. In a federated enterprise, computing resources and data are located in multiple locations in large campus sites and in branch offices. Employees connect to the corporate network from campus, branch, or private home offices. Figure 1 on page 4 represents the federated enterprise network problem abstractly, showing many branches, many campuses, and many home users. The network operation center (NOC) handles the routing and data transport between sites by Pulse Secure, LLC. All rights reserved 3

17 Figure 1: Federated Enterprise Network with Employees Located in Campus, Branch, and Home Offices Branch Network Access Resource Access Home Network Access Branch Network Access Resource Access NOC Campus Network Access Resource Access Home Network Access Campus Network Access Resource Access g A federated solution is a coordinated solution, requiring not only compatible network equipment and cooperation among administrators, but also coordination of user experience and security objectives. In this example, the access solution serves the following goals: User Experience. Ensure that employees can access the corporate network and can access resources and data in both local and remote locations without having to specify their authentication credentials at each security policy enforcement point. Security. Enforce a simple employees only policy employees get access, nonemployees do not. The policy also requires endpoint host computers to run particular antivirus software. The following sections provide an overview of the user experience and security goals for enterprise scenarios: Local Access on page 4 Remote Access on page 5 Resource Access on page 5 Federated Access on page 5 Local Access In this example, Lisa is an employee who works at the branch work site. John is an employee who works at the campus work site. At company work sites, employee desktop computers are wired to LAN switches, but the users are not admitted to the LAN and do not have IP connectivity until they use their employee usernames and password for authentication by Pulse Secure, LLC. All rights reserved

18 Chapter 1: Solution Components The IT department has installed Pulse Secure Odyssey Access Client (OAC) software on office desktop computers and has configured OAC to perform the authentication and DHCP requests for the user. When Lisa starts her workday, for example, she enters her unique username and password to initiate the authentication and network admission request. If her request meets authentication and endpoint inspection requirements, she is admitted to the corporate network and assigned an IP address. This example provides details on the deployment components and configuration required to enable this local access scenario. Remote Access Remote employees, such as home office workers or sales workers who work from customer sites or hotels, use an ISP or private network to connect to the Internet and then use Pulse Secure client to create an SSL VPN connection to the corporate network. In this example, Bob is an employee who works from his home office. To connect to the corporate network, he opens the Junos Pulse client, selects the SSL VPN connection, types his employee username and password, and clicks Connect. Junos Pulse performs the authentication request. If his request meets authentication and endpoint inspection requirements, he is admitted to the corporate network and the Junos Pulse adapter is assigned an IP address. This example provides details on the deployment components and configuration required to enable this remote access scenario. Resource Access Admission to the corporate network, either through the local access or remote access mechanism, gives the user access to unprotected resources connected to the LAN. Identity-based resource access control is an additional security measure that is enforced when a user accesses protected resources. Protected resources are applications and files hosted on servers deployed behind a firewall that enforces both security rules and identity-based permissions. In this example, we deploy firewalls as an additional enforcement point. We want to perform the additional security check and collect logs that prove the identity-based enforcement, but we do not want to interrupt the user with a second authentication challenge. This example provides details on the deployment components and configuration required to enforce an additional identity-based resource access policy without requiring additional actions by users. Federated Access In a large network, you might implement resource access policies using many different network access services. In this example, we deploy the Pulse Policy Secure in the campus network and a second Policy Secure in the branch network. In the branch network, for example, the branch Policy Secure creates session entries for the user named Lisa when she logs in and is admitted to the local network. When Lisa accesses a resource associated with the branch Policy Secure, the service can refer to the existing session entry, so it does not need to prompt her for authentication credentials. But what happens when Lisa visits a URL associated with a different Policy Secure, such as one located in the campus network? If the campus Policy Secure cannot associate a request with an existing authenticated session entry, it prompts Lisa to provide her username and password by Pulse Secure, LLC. All rights reserved 5

19 In this example, we want to perform identity-based security checks throughout the network without requiring user action each time the user reaches a new enforcement point. In a federated deployment, the access services share information about authenticated user sessions. In this example, the Policy Secure and Connect Secure are deployed in a federation. When branch employees start their workday, log in, and are admitted to the branch network, the branch Policy Secure exports information about the sessions to the campus Policy Secure. When a user visits a URL associated with the campus Policy Secure, the campus service refers to the imported authenticated session entry and so does not need to prompt for username and password. It uses the imported session information to perform the security check and enforce the policy. This example provides details on how to deploy the Pulse Secure access devices in an Interface for Metadata Access Points (IF-MAP) federation, and it shows how you can use IF-MAP logs to verify that session information is being shared as expected. For information about the IF-MAP standard, go to the following location: Related Documentation Solution Example Topology: Pulse Secure Access Solutions for a Federated Enterprise Network on page by Pulse Secure, LLC. All rights reserved

20 CHAPTER 2 Component Versions Software Versions Used in this Example on page 7 Software Versions Used in this Example Table 3 on page 7 summarizes the software versions used in this example. Table 3: Software Versions Used in This Example Hardware Component Software Version Configuration File Download 3 NS5 GT ScreenOS 6.3 Campus DHCP server Branch DHCP server HP Campus 802.1x switch EX3200 Junos OS 10.1R2.8 Branch 802.1x switch SRX100 Junos OS 10.1R2.8 Campus Infranet Enforcer SSG20 ScreenOS 6.3 Branch Infranet Enforcer IC Series Pulse Secure Access Control Service 4.1r1 build Campus system.cfg, user.cfg Branch system.cfg, user.cfg SA Series Junos Pulse Secure Access Service 7.1r1 build system.cfg, user.cfg Client hosts Windows XP SP3 Client Odyssey Access Client 5.3 Client Junos Pulse by Pulse Secure, LLC. All rights reserved 7

21 Table 3: Software Versions Used in This Example (continued) Hardware Component Software Version Configuration File Download 3 1 Refer to product user documentation for information on loading configuration files. For Pulse Secure services products, we recommend you (1) Upgrade to the release version used in this example; (2) Import the configuration; (3) Modify network address configuration as necessary; (4) Upgrade to the release version you want to evaluate by Pulse Secure, LLC. All rights reserved

22 CHAPTER 3 Component Topology Solution Example Topology: Pulse Secure Access Solutions for a Federated Enterprise Network on page 9 Solution Example Topology: Pulse Secure Access Solutions for a Federated Enterprise Network This example scenario shows a simple federated network for a laboratory we use for evaluating new Pulse Secure client features. If you have not already built your own feature evaluation laboratory, you can make use of this example by emulating the network design, downloading the configuration files, and using them as a template for configuration of your own laboratory deployment. If you already have an evaluation laboratory in place, you can use this example to understand how to deploy the Pulse Secure services within your existing campus and branch network infrastructure. The following sections describe and illustrate the network topology and provide an overview of the access solutions implemented in this example: Component Topology on page 9 Local Access: 802.1x Network Access Control on page 10 Remote Access: Pulse Connect Secure SSL VPN on page 11 Resource Access: Pulse Policy Secure on page 11 Federation on page 11 Odyssey Access Client Software on page 12 Pulse Secure Client Software on page 12 Component Topology Figure 2 on page 10 shows the network components deployed in the campus and branch locations, as well as an SSL VPN SA Series device deployed to support users working from home offices. The sections that follow explain the solutions enabled by this deployment. ccess Control in the Federated Enterprise Using IF-MAP Network Configuration Example by Pulse Secure, LLC. All rights reserved

23 Figure 2: Network Deployment Supporting Users in Campus, Branch, and Home Offices Branch Management /24 Enterprise /24 Guest /24 Remediation /24 Lisa Web server Home L2 switch EX ScreenOS Enforcer SSG20 Bob DHCP server IF-MAP client IC series ICA ISP Branch NOC IF-MAP client SA series SA DHCP server Campus IF-MAP server IC Series ICB L2 switch HP Junos Enforcer SRX100 Campus Management /24 Enterprise /24 Guest /24 Remediation /24 John Web server AD/DNS Globalcorp.local Figure 2 on page 10 shows a network operation center (NOC) that handles the routing and data transport between sites. In our simple lab example, a branch gateway router and a campus gateway router are connected through NOC links. We do not provide details on the NOC in this example. In your network, you must use your routing infrastructure in such a way that the local and remote access services can reach each other. Local Access: 802.1x Network Access Control In this example, employee admission to the LAN is controlled by an IEEE 802.1x deployment. To implement 802.1x network access control, you configure three components to communicate using 802.1x protocols: Supplicant. A client application that uses an 802.1x protocol to broadcast its user credentials. In Figure 2 on page 10, the Odyssey Access Control (OAC) software installed on John s and Lisa s host computers acts as the 802.1x supplicant. Authenticator. An 802.1x-enabled switch that enforces the port-based network access control. In this deployment, the Layer 2 switches are configured as RADIUS clients. The Layer 2 switch uses results of the RADIUS server return attributes policy to determine the VLAN in which to place the user by Pulse Secure, LLC. All rights reserved

24 Chapter 3: Component Topology In Figure 2 on page 10, the campus Layer 2 switch and branch Layer 2 switch act as 802.1x authenticators. Authentication server. In Figure 2 on page 10, Pulse Policy Secure devices are deployed in campus and branch data centers. The IC Series devices run the Pulse Policy Secure, which is configured to act as a RADIUS server. It authenticates users against an Active Directory authentication source. It uses the authentication results and endpoint inspection results to determine the VLAN in which to place the user and sends those results to the switch. In this network, DHCP services are configured so that there is a one-to-one correspondence between VLANs and IP subnets. Users who pass authentication and endpoint inspection are placed in the Enterprise VLAN and receive an IP address that belongs to the Enterprise subnet. Users who pass authentication but fail endpoint inspection are placed in the Remediation VLAN and receive an IP address that belongs to the Remediation subnet. Users who fail authentication are placed in the Guest VLAN and receive an IP address that belongs to the Guest subnet. For information about the IEEE 802.1x standard, go to the following location: Remote Access: Pulse Connect Secure SSL VPN Resource Access: Pulse Policy Secure Federation In this example, home office employees like Bob use the Pulse Secure client to establish an SSL VPN connection to the corporate network. In Figure 2 on page 10, the SA Series device is deployed in a colocation center. The SA Series runs the Pulse Connect Secure, which performs authentication and endpoint inspection to determine whether to admit remote users to the corporate intranet. In this example, users who pass authentication against the Active Directory server and pass the endpoint inspection policy are mapped to the Enterprise role and are able to establish an SSL VPN connection to the corporate network. In Figure 2 on page 10, the SRX Series and SSG Series devices are deployed as enforcement points for the Pulse Policy Secure resource access policy. Users who map to the Enterprise role are permitted to access protected resources. Users who map to the Remediation role are denied access. In Figure 2 on page 10, the IC Series and SA Series devices are deployed to perform their core functions local access control for campus and branch users and secure access for remote users. The devices are also configured to participate in a federation that uses the Interface for Metadata Access Points (IF-MAP) standard protocol to share data about user sessions. For information about the IF-MAP standard, see The campus IC Series device runs the Pulse Policy Secure. In this deployment, the campus Policy Secure acts as the IF-MAP server. It collects session information exported by IF-MAP clients. As noted, the campus Policy Secure is used in the 802.1x deployment and resource access policy deployment, so it also maintains its own session table by Pulse Secure, LLC. All rights reserved 11

25 The SA Series device runs the Pulse Connect Secure. In this deployment, it acts as an IF-MAP client and exports its session information to the IF-MAP server. When Bob makes an SSL VPN connection to the corporate network through the Connect Secure, the session table entry is exported to the campus Policy Secure. When Bob tries to access a Web server protected by the campus firewall, the campus Policy Secure uses that information to determine whether Bob is permitted access. The Connect Secure does not import session information. The branch IC Series device runs the Policy Secure. In this deployment, it acts as an IF-MAP client and exports its session information to the IF-MAP server. It also imports session information from the IF-MAP server. The branch Policy Secure thereby has session information for Bob when he tries to access a Web server protected by the branch firewall, and it uses that information to determine whether Bob is permitted access. An IF-MAP client does not export session information that it has not obtained firsthand that is, it does not export Bob s session information back to the IF-MAP server. Odyssey Access Client Software Pulse Secure Client Software In this example, the IT department has installed Pulse Secure Odyssey Access Client (OAC) software on employee desktops. OAC is configured to use the 802.1x Extensible Authentication Protocol (EAP) to request to be authenticated and admitted to the LAN. OAC also performs endpoint inspection. The results of the authentication request and endpoint inspection determine whether the user is mapped to the Enterprise role or the Remediation role. In this example, remote users use Pulse Secure client software to initiate an SSL VPN connection to the corporate network. You can also deploy Junos Pulse clients on the office desktops. We show both clients for demonstration purposes. If the employees are laptop users who sometimes also work from home, you can use Junos Pulse as both a local access client when connected from the office and as an SSL VPN client when connected from home by Pulse Secure, LLC. All rights reserved

26 PART 2 Configuration Local Network Access Policy Deployments on page 15 Remote Access Policy Deployment on page 33 User Access Management Framework on page 47 Resource Access Policy Deployments on page 63 IF-Map Federation on page by Pulse Secure, LLC. All rights reserved 13

27 CHAPTER 4 Local Network Access Policy Deployments Campus 802.1x and DHCP Deployment Campus 802.1x and DHCP Deployment on page 15 Branch 802.1x and DHCP Deployment on page 24 The purpose of the 802.1x deployment in this example is to implement network access control (NAC) for the campus network that enforces the following objectives: Enforces a network admission control policy Allows employees, and only employees, to access the local network. Enforces endpoint inspection rules Allows connections from host computers that have the latest antivirus, but does not allow connections from noncompliant hosts. Places connections that fail the authentication check into the Guest VLAN, where they can access nothing and can do no harm. Places connections that pass authentication but fail endpoint inspection in the Remediation VLAN, where they can access remediation resources, such as the latest antivirus software, but nothing else, and so can do no harm. In the configuration pages of this example, we show the required or relevant parts of the configuration and provide a link for downloading the complete configuration for the lab device. Use the related documentation list to find more detailed information about the feature, including limitations and options we have not shown. The campus and branch configurations are similar. The notable difference is in equipment: the campus deployment uses an HP Procurve switch, and the branch deployment uses a Juniper Networks EX Series switch. The Pulse Secure 802.1x local access solution operates with your existing Layer 2 switch as long as the switch supports 802.1x. When you read this documentation, you may choose to focus on the deployment that more closely resembles your own infrastructure or to compare the deployments to see the areas of equivalent functionality and get a general understanding of communication among the 802.1x deployment components by Pulse Secure, LLC. All rights reserved 15

28 The following sections show deployment and configuration details for the campus 802.1x and DHCP deployment: Deployment Diagram on page 16 Layer 2 Switch Configuration on page 17 Pulse Policy Secure Configuration on page 20 DHCP Server Configuration on page 21 Deployment Diagram Figure 3 on page 17 shows the deployment diagram for the campus 802.1x and DHCP deployment. In this 802.1x deployment, John is an employee. When he turns on his computer to begin his workday, he does not have network connectivity. He has an OAC client installed on the desktop computer in his office. When John enters his username and password through the OAC client, the client initiates authentication to the network using EAP. In the 802.1x system, the OAC client is an 802.1x supplicant. The switch acts as the 802.1x authenticator. It sends a RADIUS client request to the RADIUS server in this case, to the Pulse Policy Secure running on the IC Series device. The Policy Secure authenticates users against its associated authentication source, the AD server named Globalcorp.local. It also sends a probe to OAC to perform endpoint inspection on John s desktop computer. Based on the authentication results and endpoint inspection results, the Policy Secure determines John s user role. The Policy Secure RADIUS return attributes policy uses the role information to send RADIUS return attributes, in particular the VLAN assignment, to the switch. In this example, John is authenticated and gains access to the enterprise VLAN. Next, OAC sends a request for a DHCP server to assign it an IP address. Because John is in the enterprise VLAN, the request is served by the corresponding DHCP server subinterface, and John obtains the next IP address belonging to the enterprise subnet by Pulse Secure, LLC. All rights reserved

29 Chapter 4: Local Network Access Policy Deployments Figure 3: Campus 802.1x Deployment NOC Branch Campus DHCP server IF-MAP server IC series ICB AD/DNS Globalcorp.local L2 switch HP2626 John g Layer 2 Switch Configuration Table 4 on page 17 describes the features we configured on the Layer 2 switch to enable 802.1x port-based network access. Table 4: Campus Switch 802.1x Configuration Feature Description 802.1x protocol We enable 802.1x authentication, the 802.1x authenticator service, and the ports that listen for 802.1x supplicant communication. RADIUS client-server communication We specify the IP address for the Pulse Policy Secure that acts as the RADIUS server and the shared secret used in secure communication between the client and server. The shared secret string configured for the RADIUS client and RADIUS server must match. In the HP switch configuration, the shared secret is called the key by Pulse Secure, LLC. All rights reserved 17

30 Table 4: Campus Switch 802.1x Configuration (continued) Feature Description VLAN tagged ports VLAN ID numbers are arbitrary. In this example, we provision and use the following VLAN tags: VLAN 36 is the Enterprise VLAN. Employees must map to the Enterprise role to be admitted to the Enterprise VLAN and have access to unprotected resources on the corporate network. VLAN 37 is the Guest VLAN. Failed authentication requests are resolved by placing the port in the Guest VLAN. VLAN 38 is the Remediation VLAN. Employees who pass authentication but fail endpoint inspection are mapped to the Remediation role and admitted to the Remediation VLAN instead of the Enterprise VLAN. VLAN 39 is the Management VLAN. The management VLAN is provisioned for device communication, such as RADIUS communication between the switch and the Policy Secure. Note that unlike the other ports, the management port has been assigned an IP address ( ). When you configure RADIUS client-server communication on the Policy Secure side of the communication, you specify IP address as the RADIUS client address. NOTE: Most switches have a default VLAN (usually VLAN 0 or 1). Do not use the default VLAN for the 802.1x implementation. Figure 4 on page 18 shows the VLAN settings for the HP Procurve switch. Figure 4: HP Procurve Web UI: Configuration > VLAN Configuration The 802.1x configuration settings are not readily available through the Web user interface. The following command-line sample shows the complete configuration of the HP Procurve switch. The relevant portions are shown in boldface text. ftghp01(config)# show config Startup configuration: ; J9021A Configuration Editor; Created on release #N hostname "ftghp01" by Pulse Secure, LLC. All rights reserved

31 Chapter 4: Local Network Access Policy Deployments snmp-server contact "FT admin" snmpserver location "Sunnyvale" maxvlans 256 ip default-gateway sntp server snmp-server community "public" Unrestricted vlan 1 name "DEFAULT_VLAN" untagged 1-24 no ip address jumbo exit vlan 10 name "VLAN10" ip address tagged 2 exit vlan 31 name "VLAN31" no ip address tagged 2 exit vlan 36 name "Enterprise" no ip address tagged 2 exit vlan 37 name "Guest" no ip address tagged 2 exit vlan 38 name "Remediation" no ip address tagged 2 exit vlan 39 name "Management" ip address tagged 2 exit fault-finder bad-driver sensitivity high fault-finder bad-transceiver sensitivity high fault-finder bad-cable sensitivity high fault-finder too-long-cable sensitivity high fault-finder over-bandwidth sensitivity high fault-finder broadcast-storm sensitivity high fault-finder loss-of-link sensitivity high fault-finder duplex-mismatch-hdx sensitivity high fault-finder duplex-mismatch-fdx sensitivity high aaa authentication port-access eap-radius radius-server host key juniper aaa port-access authenticator 3-6 aaa port-access authenticator active aaa port-access supplicant 3-6 spanning-tree Click here to download the complete configuration for this device by Pulse Secure, LLC. All rights reserved 19

32 Pulse Policy Secure Configuration Table 5 on page 20 describes the features we configured on the Pulse Policy Secure to enable 802.1x port-based network access. Table 5: Campus Policy Secure 802.1x Configuration Feature Description Location group The location group identifies the switch that is a RADIUS client and identifies the signin policy that associates the session with a user realm. RADIUS client-server communication We specify the IP address for the switch that is the RADIUS client and specify the shared secret used in secure communication with the switch. The shared secret strings configured for the RADIUS client and for the RADIUS server must match. In the HP switch configuration, the shared secret is called the key. RADIUS return attributes policy rules We configure two rules: The Enterprise-Access rule returns VLAN 36 for users who pass authentication and endpoint inspection. The Remediation-Access rule returns VLAN 38 for requests that do not pass both authentication and endpoint inspection. NOTE: We do not need rules to place requests in the Guest VLAN or management VLAN. The switch resolves failed authentication requests by placing them in the Guest VLAN. The management VLAN is not used for user access. Figure 5 on page 20, Figure 6 on page 21, and Figure 7 on page 21 show these settings. Figure 5: Pulse Policy Secure: Network Access > Location Group by Pulse Secure, LLC. All rights reserved

33 Chapter 4: Local Network Access Policy Deployments Figure 6: Pulse Policy Secure: Network Access > RADIUS Client Figure 7: Pulse Policy Secure: Network Access > RADIUS Return Attributes Policies Click the following links to download the complete configuration for this device: Part 1, Part 2. DHCP Server Configuration In this network, hosts are assigned IP addresses by a DHCP server. This example uses a Netscreen Series 5GT device to provide DHCP services. For the sake of completeness, we show the deployment and configuration details for this device. In your deployment, you can use any device that provides DHCP services. The DHCP server is deployed physically in the path of the switch to the gateway router. The interface configurations for the switch ports and the DHCP device are coordinated to provision IP addresses for four subnets, summarized in Table 6 on page 22. When a user accesses the network via the 802.1x deployment and is mapped to the enterprise VLAN, for example, the DHCP server assigns the endpoint the next available IP address from the address range configured for the enterprise subnet by Pulse Secure, LLC. All rights reserved 21

34 Table 6: Campus DHCP Address Ranges Purpose Switch Port VLAN DHCP Server Subinterface Subnet Address Address Range Management 1 39 Name: trust.5 IP address: / x No DHCP services Enterprise 2 36 Name: trust.2 IP address: / x Guest 3 37 Name: trust.3 IP address: / x Remediation 4 38 Name: trust.4 IP address: / x Figure 8 on page 22, Figure 9 on page 23, and Figure 10 on page 23 show the DHCP server settings. Figure 8: ScreenOS Web UI: Network > Interfaces by Pulse Secure, LLC. All rights reserved

35 Chapter 4: Local Network Access Policy Deployments Figure 9: ScreenOS Web UI: Network > DHCP Figure 10: ScreenOS Web UI: Network > DHCP > DHCP Server Address Edit Click here to download the complete set of commands used to configure this device. Related Documentation Understanding 802.1X Network Access Control Deployments ScreenOS Concepts and Examples Reference Guide > Dynamic Host Configuration Protocol 2015 by Pulse Secure, LLC. All rights reserved 23

36 Branch 802.1x and DHCP Deployment The purpose of the 802.1x deployment in this example is to implement network access control (NAC) for the branch network that enforces the following objectives: Enforces a network admission control policy Allows employees, and only employees, to access the local network. Enforces endpoint inspection rules Allows connections from host computers that have the latest antivirus, but does not allow connections from noncompliant hosts. Places connections that fail the authentication check into the Guest VLAN, where they can access nothing and therefore cannot do any harm. Places connections that pass authentication but fail endpoint inspection in the Remediation VLAN, where they can access only remediation resources, such as the latest antivirus software, but nothing else and so do no harm. In the configuration pages of this example, we show the required or relevant parts of the configuration and provide a link for downloading the complete configuration for the lab device. Use the related documentation list to find more detailed information about the feature, including limitations and options we have not shown. The campus and branch configurations are similar. The notable difference is in equipment: the campus deployment uses an HP Procurve switch, and the branch deployment uses a Juniper Networks EX Series switch. The Pulse Secure 802.1x local access solution operates with your existing Layer 2 switch as long as the switch supports 802.1x. When you read this documentation, you may choose to focus on the deployment that more closely resembles your own infrastructure or to compare the deployments to see the areas of equivalent functionality and get a general understanding of communication among the 802.1x deployment components. The following sections describe and show deployment and configuration details for the branch 802.1x and DHCP deployment: Deployment Diagram on page 24 Layer 2 Switch Configuration on page 25 Pulse Policy Secure Configuration on page 28 DHCP Server Configuration on page 30 Deployment Diagram Figure 11 on page 25 shows the deployment diagram for the branch 802.1x and DHCP deployment. In this 802.1x deployment, Lisa is an employee. When she turns on her computer in the morning, she does not have network connectivity. She has an OAC client installed on the desktop computer in her office. When Lisa enters her username and password through the OAC client, the client initiates authentication to the network using EAP. In the 802.1x system, the OAC client is an 802.1x supplicant. The switch acts as the 802.1x authenticator. It sends a RADIUS client request to the RADIUS server in this case, to the Pulse Policy Secure running on the IC Series device. The Policy Secure authenticates users against its associated authentication source, the Active Directory (AD) server named Globalcorp.local by Pulse Secure, LLC. All rights reserved

37 Chapter 4: Local Network Access Policy Deployments It also sends a probe to OAC to perform endpoint inspection on Lisa s desktop computer. Based on the authentication results and endpoint inspection results, the Policy Secure determines Lisa s user role. The Policy Secure RADIUS return attributes policy uses the role information to send RADIUS return attributes, in particular the VLAN assignment, to the switch. In this example, Lisa is authenticated and gains access to the enterprise VLAN. Next, OAC sends a request for a DHCP server to assign it an IP address. Because Lisa is in the enterprise VLAN, the request is served by the corresponding DHCP server subinterface, and Lisa obtains the next IP address belonging to the enterprise subnet. Figure 11: Branch 802.1x Deployment NOC Campus Branch DHCP server IF-MAP client IC series ICA AD/DNS Globalcorp.local L2 switch EX Lisa g Layer 2 Switch Configuration Table 7 on page 26 describes the features we configured on the switch to enable 802.1x port-based network access by Pulse Secure, LLC. All rights reserved 25

38 Table 7: Branch Switch 802.1x Configuration Feature Description 802.1x protocol We enable 802.1x authentication, the 802.1x authenticator service, and the ports that listen for 802.1x supplicant communication. RADIUS client-server communication We specify the IP address for the Pulse Policy Secure that acts as the RADIUS server and the shared secret used in secure communication between the client and server. The shared secret strings configured for the RADIUS client and for the RADIUS server must match. VLAN tagged ports VLAN ID numbers are arbitrary. In this example, we provision and use the following VLAN tags: VLAN 32 is the Enterprise VLAN. Employees must map to the Enterprise role to be admitted to the Enterprise VLAN and have access to unprotected resources on the corporate network. VLAN 33 is the Guest VLAN. Failed authentication requests are resolved by placing the port in the Guest VLAN. VLAN 34 is the Remediation VLAN. Employees who pass authentication but fail endpoint inspection are mapped to the Remediation role and admitted to the Remediation VLAN instead of the Enterprise VLAN. VLAN 35 is the Management VLAN. The management VLAN is provisioned for device communication, such as RADIUS communication between the switch and the Policy Secure. NOTE: Most switches have a default VLAN (usually VLAN 0 or 1). Do not use the default VLAN for the 802.1x implementation. Figure 12 on page 26, Figure 13 on page 27, Figure 14 on page 27, and Figure 15 on page 28 show these settings. Figure 12: J-Web UI: Point and Click CLI > protocols > dot1x by Pulse Secure, LLC. All rights reserved

39 Chapter 4: Local Network Access Policy Deployments Figure 13: J-Web UI: Point and Click CLI > access > dot1x > authenticator Figure 14: J-Web UI: Point and Click CLI > access > radius-server 2015 by Pulse Secure, LLC. All rights reserved 27

40 Figure 15: J-Web UI: Configure > Switching > VLAN Click here to see the complete configuration of this device. Pulse Policy Secure Configuration Table 8 on page 28 describes the features we configured on the Pulse Policy Secure to enable 802.1x port-based network access. Table 8: Branch Policy Secure 802.1x Configuration Feature Description Location group The location group identifies the switch that is a RADIUS client and identifies the signin policy that associates the session with a user realm. RADIUS client-server communication We specify the IP address for the switch that is the RADIUS client and specify the shared secret used in secure communication with the switch. The shared secret strings configured for the RADIUS client and that configured for the RADIUS server must match. RADIUS return attributes policy rules We configure two rules: The Enterprise-Access rule returns VLAN 32 for users who pass authentication and endpoint inspection. The Remediation-Access rule returns VLAN 34 for requests that pass authentication but do not pass endpoint inspection. NOTE: Rules are not needed to place requests in the guest VLAN or the management VLAN. The switch resolves failed authentication requests by placing them in the Guest VLAN. The management VLAN is not used for user access. Figure 16 on page 29, Figure 17 on page 29, and Figure 18 on page 30 show these settings by Pulse Secure, LLC. All rights reserved

41 Chapter 4: Local Network Access Policy Deployments Figure 16: Pulse Policy Secure: Network Access > Location Group Figure 17: Pulse Policy Secure: Network Access > RADIUS Client 2015 by Pulse Secure, LLC. All rights reserved 29

42 Figure 18: Pulse Policy Secure: Network Access > RADIUS Return Attributes Policies Click the following links to download the complete configuration for this device: Part 1, Part 2. DHCP Server Configuration In this network, hosts are assigned IP addresses by a DHCP server. This example uses a Netscreen Series 5GT device to provide DHCP services. For the sake of completeness, we show the deployment and configuration details for this device. In your deployment, you can use any device that provides DHCP services. In this example, the DHCP server is deployed physically in the path of the switch to the gateway router. The interface configuration for the switch ports and the DHCP device are coordinated to provision IP addresses for four subnets, summarized in Table 9 on page 30. When a user accesses the network via the 802.1x deployment and is mapped to the enterprise VLAN, for example, the DHCP server assigns the endpoint the next available IP address from the address range configured for the enterprise subnet. Table 9: Branch DHCP Address Ranges Purpose Subnet Address Address Range DHCP Server Sub-interface Switch Port VLAN Management x Name: trust.5 IP address: /24 ge-0/0/0 35 Enterprise x Name: trust.2 IP address: /24 ge-0/0/2 32 Guest x Name: trust.3 IP address: /24 ge-0/0/ by Pulse Secure, LLC. All rights reserved

43 Chapter 4: Local Network Access Policy Deployments Table 9: Branch DHCP Address Ranges (continued) Purpose Subnet Address Address Range DHCP Server Sub-interface Switch Port VLAN Remediation x Name: trust.4 IP address: /24 ge-0/0/4 34 Figure 19 on page 31, Figure 20 on page 31, and Figure 21 on page 32 show the DHCP server settings. Figure 19: ScreenOS Web UI: Network > Interfaces Figure 20: ScreenOS Web UI: Network > DHCP 2015 by Pulse Secure, LLC. All rights reserved 31

44 Figure 21: ScreenOS Web UI: Network > DHCP > DHCP Server Address List Click here to download the complete set of commands used to configure this device by Pulse Secure, LLC. All rights reserved

45 CHAPTER 5 Remote Access Policy Deployment Pulse Connect Secure User Access Management Framework on page 33 Pulse Connect Secure User Access Management Framework The purpose of the Pulse Connect Secure user access management framework configuration used in this example is simply to enable employees to use SSL VPN to connect to the corporate network from remote locations, such as home offices. In the configuration pages of this example, we show the required or relevant parts of the configuration and provide a link for downloading the complete configuration for the lab device. Use the related documentation list to find more detailed information about the feature, including limitations and options we have not shown. The following sections describe and show deployment and configuration details for the Connect Secure user access management framework: Overview on page 33 User Roles on page 34 Authentication Server on page 40 User Authentication Realm on page 41 Network Connect Connection Profile on page 43 Sign-In Policy on page 45 Complete Configuration on page 46 Overview The Pulse Connect Secure user access management framework is a set of configuration objects that you associate to implement identity-based connection and resource access policies. The modularity gives you flexibility to manage groups of users differently. Ultimately, rules match the user role associated with the session, so the purpose of the framework is to determine the session s user role. Figure 22 on page 34 shows how the framework components are associated to determine the user role. The user sign-in policy associates the session with an authentication realm. The authentication realm defines how authentication results and endpoint inspection results are used to determine the session user role. The role is used in network connection and resource access policy rules by Pulse Secure, LLC. All rights reserved 33

46 Figure 22: Pulse Connect Secure User Access Management Framework Sign-In Page/Sign-In Policy Auth Server Host Checker Authentication Realm Role Access Features Resource Profile Resource Policy In this example, all users found in the Active Directory server are mapped to enterprise and remediation roles. If the users then pass endpoint inspection requirements for the enterprise role, they are granted the enterprise role permissions and can complete an SSL VPN connection to the corporate network. If the users do not pass endpoint inspection requirements for the enterprise role, they are limited to remediation role permissions. User Roles The user role configuration establishes access mechanisms, session options, and UI options. In this example, users are mapped into two roles: Enterprise A designation for employees who should be allowed to make an SSL VPN connection to the corporate network. Remediation A designation for noncompliant hosts. Figure 23 on page 35 shows a summary of the user roles configured for this example by Pulse Secure, LLC. All rights reserved

47 Chapter 5: Remote Access Policy Deployment Figure 23: Pulse Connect Secure: Users > User Roles Figure 24 on page 36, Figure 25 on page 37, Figure 26 on page 38, and Figure 27 on page 39 show user role configuration details. The Enterprise role gives users access to the Web, the file system, and Network Connect, which is used to establish an SSL VPN connection. The Remediation rule gives users access only to the Web so that they can view a Web page with remediation instructions by Pulse Secure, LLC. All rights reserved 35

48 Figure 24: Pulse Connect Secure: Users > User Roles by Pulse Secure, LLC. All rights reserved

49 Chapter 5: Remote Access Policy Deployment Figure 25: Pulse Connect Secure: Users > User Roles > Enterprise > Network Connect Upon successful authentication, the host computer is probed to evaluate compliance with the endpoint inspection requirements. If the host passes the host check for the Enterprise role, the employee is granted the Enterprise role permissions. If the host does not pass endpoint inspection requirements for the Enterprise role, the employee is limited to Remediation role permissions. Figure 26 on page 38 shows the endpoint inspection rule for the Enterprise role, a predefined rule requiring Symantec antivirus software on the host computer by Pulse Secure, LLC. All rights reserved 37

50 Figure 26: Pulse Connect Secure: Users >User Roles > Enterprise > Restrictions > Host Checker Figure 27 on page 39 shows the Remediation role summary. This Remediation role is configured to allow access only to the Web so that the user can view a Web page with remediation instructions by Pulse Secure, LLC. All rights reserved

51 Chapter 5: Remote Access Policy Deployment Figure 27: Pulse Connect Secure: Users > User Roles 2015 by Pulse Secure, LLC. All rights reserved 39

52 Authentication Server The authentication server configuration is the connection information for the authentication servers you use in your enterprise. This example uses an Active Directory (AD) server. The AD domain in this example is named GLOBALCORP. If your AD server uses multiple domains, you would create a different Connect Secure configuration object for each. Figure 28 on page 41 shows the authentication server configured for this example by Pulse Secure, LLC. All rights reserved

53 Chapter 5: Remote Access Policy Deployment Figure 28: Pulse Connect Secure: Authentication > Auth Servers > AD Server User Authentication Realm The user authentication realm configuration references the authentication server and includes the rules that map users to user roles. The authentication realm in this example is named Users by Pulse Secure, LLC. All rights reserved 41

54 Figure 29 on page 42 shows the authentication realm configured for this example. Note that it uses the campus Active Directory server. Figure 29: Pulse Connect Secure: Users > User Realms Figure 30 on page 43 shows the role mapping rule. In effect, all users in the Active Directory server are mapped to Enterprise and Remediation roles. If they then pass endpoint inspection requirements for the Enterprise role, they are granted the Enterprise role permissions. If they do not pass endpoint inspection requirements for the Enterprise role, they are limited to Remediation role permissions by Pulse Secure, LLC. All rights reserved

55 Chapter 5: Remote Access Policy Deployment Figure 30: Pulse Connect Secure: Users > User Authentication Realms Network Connect Connection Profile The network connect connection profile configures connection settings for the SSL VPN connection to the corporate network. In Figure 31 on page 44, Bob s ISP determines the connection properties for the connection from his home to the Internet and the SA Series device. When Bob is authenticated and is mapped to the Enterprise role, the network connect connection profile determines the connection properties for Bob s connection to the Intranet by Pulse Secure, LLC. All rights reserved 43

56 Figure 31: Pulse Connect Secure SSL VPN Connection Intranet IF-MAP client SA series SA Internet Bob g Figure 32 on page 45 shows the network connect connection profile for this example. The network connect connection profile settings include the IP address range for assigning local IP addresses to SSL VPN clients by Pulse Secure, LLC. All rights reserved

57 Chapter 5: Remote Access Policy Deployment Figure 32: Pulse Connect Secure: Users > Resource Policies > Network Connect Connection Profiles Sign-In Policy The sign-in policy configuration associates the Connect Secure URL and Web-based sign-in page with an authentication realm. In this example, we associate the default URL and sign-in page with the realm we created that is named Users. Figure 33 on page 46 shows the sign-in page summary for this example by Pulse Secure, LLC. All rights reserved 45

58 Figure 33: Pulse Connect Secure: Authentication > Signing In Complete Configuration Click the following links to download the complete configuration for this device: Part 1, Part by Pulse Secure, LLC. All rights reserved

59 CHAPTER 6 User Access Management Framework Campus Pulse Policy Secure User Access Management Framework on page 47 Branch Pulse Policy Secure User Access Management Framework on page 54 Campus Pulse Policy Secure User Access Management Framework The Pulse Policy Secure user access management framework is a set of configuration objects that you associate to implement an identity-based security policy. The framework for this example is designed to enforce a simple employees only policy and to check for noncompliant host computers. In the configuration pages of this example, we show the required or relevant parts of the configuration and provide a link for downloading the complete configuration for the lab device. Use the related documentation list to find more detailed information about the feature, including limitations and options we have not shown. The campus and branch configurations are similar. There are no notable differences. We provide separate details for the sake of completeness. The following sections show deployment and configuration details for the campus user access management framework: Overview on page 47 User Roles on page 48 Authentication Server on page 50 User Authentication Realm on page 52 Sign-In Policy on page 53 Complete Configuration on page 54 Overview The Pulse Policy Secure user access management framework is a set of configuration objects that you associate to implement identity-based network access and resource access policies. The modularity gives you flexibility to manage groups of users differently. Ultimately, access policy rules match the user role associated with the session, so the purpose of framework is to determine the session s user role by Pulse Secure, LLC. All rights reserved 47

60 Figure 34 on page 48 shows how the framework components are associated to determine the user role. The user sign-in policy associates the session with an authentication realm. The authentication realm defines how authentication results and endpoint inspection results are used to determine the session user role. The role is used in network access rules and resource access policy rules. Figure 34: Pulse Policy Secure User Access Management Framework Sign-In Page/Sign-In Policy Authentication Realm Access Policies Auth Server Host Checker Role Network Access Resource Access In this example, all users found in the Active Directory server are mapped to enterprise and remediation roles. If the users then pass endpoint inspection requirements for the enterprise role, they are granted the enterprise role permissions. If the users do not pass endpoint inspection requirements for the enterprise role, they are limited to remediation role permissions. User Roles The user role configuration establishes access mechanisms, session options, and UI options. In this example, users are mapped into two roles: Enterprise A designation for employees who should have access to the corporate network and access to protected Web servers. Remediation A designation for users with noncompliant host computers. Figure 35 on page 49 shows a summary of the user roles configured for this example by Pulse Secure, LLC. All rights reserved

61 Chapter 6: User Access Management Framework Figure 35: Pulse Policy Secure: Users > User Roles Upon successful authentication, the host computer is probed to evaluate compliance with the endpoint inspection requirements. If the host passes the host check for the Enterprise role, the employee is granted the Enterprise role permissions. If the host does not pass endpoint inspection requirements for the Enterprise role, the employee is limited to Remediation role permissions. Figure 36 on page 49 shows the endpoint inspection rule for the Enterprise role, a predefined rule requiring Symantec antivirus software on the host computer. Figure 36: Pulse Connect Secure: Users > User Roles > Enterprise > Restrictions > Host Checker 2015 by Pulse Secure, LLC. All rights reserved 49

62 Authentication Server The authentication server configuration is the connection information for the authentication servers that you use in your enterprise. This example uses an Active Directory (AD) server. The AD domain in this example is named GLOBALCORP. If your AD server uses multiple domains, you would create a different Policy Secure configuration object for each. Figure 37 on page 51 shows the configuration for the authentication server by Pulse Secure, LLC. All rights reserved

63 Chapter 6: User Access Management Framework Figure 37: Pulse Policy Secure: Authentication > Auth. Servers 2015 by Pulse Secure, LLC. All rights reserved 51

64 User Authentication Realm The user authentication realm configuration: References the authentication server. Includes the rules that map users to roles. The authentication realm in this example is named Users. Figure 38 on page 52 and Figure 39 on page 52 show the configuration details. Figure 38: Pulse Policy Secure: Users > User Authentication Realms Figure 39: Pulse Policy Secure: Users > User Authentication Realms > Role Mapping by Pulse Secure, LLC. All rights reserved

65 Chapter 6: User Access Management Framework Sign-In Policy The sign-in policy configuration associates the Policy Secure URL and Web-based sign-in page with an authentication realm. In this example, we associate the default URL and sign-in page with the realm we created named Enterprise. Figure 40 on page 53 shows the sign-in page summary for this example. Figure 40: Pulse Policy Secure: Authentication > Signing In > Sign-in Policies Figure 41 on page 54 shows the default authentication protocol sets. These are the protocols used in 802.1x communication between supplicants (OAC or Pulse Secure client), the authenticator (Layer 2 switch), and the authentication server (Policy Secure RADIUS server) by Pulse Secure, LLC. All rights reserved 53

66 Figure 41: Pulse Policy Secure: Authentication > Signing In > Authentication Protocol Sets Complete Configuration Click the following links to download the complete configuration for this device: Part 1, Part 2. Branch Pulse Policy Secure User Access Management Framework The Pulse Policy Secure user access management framework is a set of configuration objects that you associate to implement an identity-based security policy. The framework for this example is designed to enforce a simple employees only policy and to check for noncompliant host computers. In the configuration pages of this example, we show the required or relevant parts of the configuration and provide a link for downloading the complete configuration for the lab device. Use the related documentation list to find more detailed information about the feature, including limitations and options we have not shown. The campus and branch configurations are similar. There are no notable differences. We provide separate details for the sake of completeness by Pulse Secure, LLC. All rights reserved

67 Chapter 6: User Access Management Framework The following sections show deployment and configuration details for the branch user access management framework: Overview on page 55 User Roles on page 56 Authentication Server on page 57 User Authentication Realm on page 59 Sign-In Policy on page 60 Complete Configuration on page 62 Overview The Pulse Policy Secure user access management framework is a set of configuration objects that you associate to implement identity-based network access and resource access policies. The modularity gives you flexibility to manage groups of users differently. Ultimately, access policy rules match the user role associated with the session, so the purpose of framework is to determine the session s user role. Figure 42 on page 55 shows how the framework components are associated to determine the user role. The user sign-in policy associates the session with an authentication realm. The authentication realm defines how authentication results and endpoint inspection results are used to determine the session user role. The role is used in network access rules and resource access policy rules. Figure 42: Pulse Policy Secure User Access Management Framework Sign-In Page/Sign-In Policy Authentication Realm Access Policies Auth Server Host Checker Role Network Access Resource Access In this example, all users found in the Active Directory server are mapped to enterprise and remediation roles. If the users then pass endpoint inspection requirements for the enterprise role, they are granted the enterprise role permissions. If the users do not pass endpoint inspection requirements for the enterprise role, they are limited to remediation role permissions by Pulse Secure, LLC. All rights reserved 55

68 User Roles The user role configuration establishes access mechanisms, session options, and UI options. In this example, users are mapped into two roles: Enterprise A designation for employees who should have access to the corporate network and access to protected Web servers. Remediation A designation for users with noncompliant host computers. Figure 43 on page 56 shows a summary of the user roles configured for this example. Figure 43: Pulse Policy Secure: Users > User Roles Upon successful authentication, the host computer is probed to evaluate compliance with the endpoint inspection requirements. If the host passes the host check for the Enterprise role, the employee is granted the Enterprise role permissions. If the host does not pass endpoint inspection requirements for the Enterprise role, the employee is limited to Remediation role permissions. Figure 44 on page 57 shows the endpoint inspection rule for the Enterprise role, a predefined rule requiring Symantec antivirus software on the host computer by Pulse Secure, LLC. All rights reserved

69 Chapter 6: User Access Management Framework Figure 44: Pulse Policy Secure: Users > User Roles > Enterprise > General > Restrictions > Host Checker Authentication Server The authentication server configuration is the connection information for the authentication servers that you use in your enterprise. This example uses an Active Directory (AD) server. The AD domain in this example is named GLOBALCORP. If your AD server uses multiple domains, you create a different Policy Secure configuration object for each. Figure 45 on page 58 shows the configuration for the authentication server. Note that it uses the campus Active Directory server by Pulse Secure, LLC. All rights reserved 57

70 Figure 45: Pulse Policy Secure: Authentication > Auth. Servers > New Active Directory Server > AD Server by Pulse Secure, LLC. All rights reserved

71 Chapter 6: User Access Management Framework User Authentication Realm The user authentication realm configuration: References the authentication server. Defines endpoint inspection requirements. Includes the rules that map users to roles. The authentication realm in this example is named Enterprise. Figure 46 on page 59 and Figure 47 on page 60 show the configuration details. Figure 46: Pulse Policy Secure: Users > User Authentication Realms 2015 by Pulse Secure, LLC. All rights reserved 59

72 Figure 47: Pulse Policy Secure: Users > User Authentication Realms > Role Mapping Sign-In Policy The sign-in policy configuration associates the Pulse Policy Secure URL and Web-based sign-in page with an authentication realm. In this example, we associate the default URL and sign-in page with the realm we created named Enterprise. Figure 48 on page 61 shows a summary of the sign-in page that is configured for this example by Pulse Secure, LLC. All rights reserved

73 Chapter 6: User Access Management Framework Figure 48: Pulse Policy Secure: Authentication > Signing In > Sign-In Policies Figure 49 on page 61 shows the default authentication protocol sets. These are the protocols used in 802.1x communication between supplicants (OAC or Pulse Secure clients), the authenticator (Layer 2 switch), and the authentication server (Policy Secure RADIUS server). Figure 49: Pulse Policy Secure: Authentication > Signing In > Authentication Protocol Sets 2015 by Pulse Secure, LLC. All rights reserved 61

74 Complete Configuration Click the following links to download the complete configuration for this device: Part 1, Part by Pulse Secure, LLC. All rights reserved

75 CHAPTER 7 Resource Access Policy Deployments Campus Resource Access Policy Enforcement Deployment on page 63 Branch Resource Access Policy Enforcement Deployment on page 68 Campus Resource Access Policy Enforcement Deployment The purpose of the identity-based resource access policy in this example is to enforce a simple employees only policy. If your business has more complex requirements, you can configure more roles and resource access policy rules to enforce more granular restrictions, such as allowing only HR employees access to HR databases or Finance employees access to the accounting side of a customer relationship management (CRM) database. In the configuration pages of this example, we show the required or relevant parts of the configuration and provide a link for downloading the complete configuration for the lab device. Use the related documentation list to find more detailed information about the feature, including limitations and options we have not shown. The campus and branch configurations are similar. The notable difference is that the campus deployment uses a Juniper Networks SRX Series device to enforce the identity-based resource access policy, while the branch deployment uses a Juniper Networks SSG Series device. With regard to the identity-based resource access policy objective, the SRX Series devices and the SSG Series devices are functionally equivalent: in addition to whatever other security features each might have, either product line can be configured to enforce the identity-based resource access policy. When you navigate this documentation, you may choose to focus on the deployment that more closely resembles your own infrastructure or to compare the deployments to see the areas of equivalent functionality. The following sections show deployment and configuration details for the campus resource access policy deployment: Deployment Diagram on page 64 SRX Series Configuration on page 64 Pulse Policy Secure Configuration on page by Pulse Secure, LLC. All rights reserved 63

76 Deployment Diagram Figure 50 on page 64 shows the deployment diagram for the campus resource access policy enforcement deployment. The campus uses an SRX100 device to protect Web server In addition to performing firewall security checks, we deploy the SRX100 to enforce the identity-based resource access policy. Only users mapped to the Enterprise role are allowed to access Web server When John attempts to access this Web server, the SRX100 performs a session lookup against the authentication table pushed to it by the campus Pulse Policy Secure. In this scenario, the authentication table has an entry for John because he gained access to the campus network through the 802.1x deployment associated with the campus Policy Secure. The authentication table entry shows that John belongs to the Enterprise role, so he is allowed to access Web server Figure 50: Campus Resource Access Policy Enforcement Deployment NOC Branch Campus DHCP server IF-MAP server IC series ICB SRX100 AD/DNS Globalcorp.local Unprotected server /32 Protected server g John SRX Series Configuration Table 10 on page 64 describes the features we configured on the SRX Series device to enable enforcement of Pulse Policy Secure resource policy rules. Table 10: Campus UAC Enforcer Configuration Junos OS Configuration Hierarchy Description services With the Junos OS services hierarchy, we configure communication with the Pulse Policy Secure. We specify the interface to use for communication, the Policy Secure IP address, and the Policy Secure administrator password by Pulse Secure, LLC. All rights reserved

77 Chapter 7: Resource Access Policy Deployments Table 10: Campus UAC Enforcer Configuration (continued) Junos OS Configuration Hierarchy Description security We add a security policy rule that directs the SRX device to enforce the Uac policy. Figure 51 on page 65 and Figure 52 on page 66 show these configurations. Figure 51: J-Web UI: Point and Click CLI > services > unified-access-control 2015 by Pulse Secure, LLC. All rights reserved 65

78 Figure 52: J-Web UI: Point and Click CLI > security > policies > policy > untrust-trust Click here to display the complete configuration for this device. Pulse Policy Secure Configuration Table 11 on page 66 describes the features we configured on the Pulse Policy Secure to enable enforcement of Policy Secure resource policy rules. Table 11: Campus Pulse Policy Secure Resource Access Policy Configuration Feature Description Infranet Enforcer Connection information for communication with the SRX Series: Specify the SRX Series device administrator password. Use the SRX J-Web UI to look up the SRX Series device serial number. The serial number is shown on the J-Web dashboard page. Location Group is not used in this example. Resource Access Policy The Enterprise-Access-Permitted rule allows Enterprise role users access to all ports on servers and Figure 53 on page 67, Figure 54 on page 67, and Figure 55 on page 68 show this configuration by Pulse Secure, LLC. All rights reserved

79 Chapter 7: Resource Access Policy Deployments Figure 53: Pulse Policy Secure: Infranet Enforcer > Connection When communication is established between the Pulse Policy Secure and the SRX Series device, the Enforcer Status shown on the system status page is green, as shown in Figure 54 on page 67. Figure 54: Pulse Policy Secure: System > Status Figure 55 on page 68 shows a summary of the resource access policy configured for this example by Pulse Secure, LLC. All rights reserved 67

80 Figure 55: Pulse Policy Secure: Infranet Enforcer > Resource Access Policies Click the following links to download the complete configuration for this device: Part 1, Part 2. Related Documentation Junos SRX Enforcer Feature Guide Branch Resource Access Policy Enforcement Deployment The purpose of the identity-based resource access policy in this example is to enforce a simple employees only policy. If your business has more complex requirements, you can configure more roles and resource access policy rules to enforce more granular restrictions, such as allowing only HR employees access to HR databases or Finance employees access to the accounting side of a customer relationship management (CRM) database. In the configuration pages of this example, we show the required or relevant parts of the configuration and provide a link for downloading the complete configuration for the lab device. Use the related documentation list to find more detailed information about the feature, including limitations and options we have not shown. The campus and branch configurations are similar. The notable difference is that the campus deployment uses a Juniper Networks SRX Series device to enforce the identity-based resource access policy, while the branch deployment uses a Juniper Networks SSG Series device. With regard to the identity-based resource access policy objective, the SRX Series devices and the SSG Series devices are functionally equivalent: in addition to whatever other security features each might have, either product line can be configured to enforce the identity-based resource access policy. When you navigate this documentation, you may choose to focus on the deployment that more closely resembles your own infrastructure or to compare the deployments to see the areas of equivalent functionality by Pulse Secure, LLC. All rights reserved

81 Chapter 7: Resource Access Policy Deployments Deployment Diagram The following sections show deployment and configuration details for the branch resource access policy deployment: Deployment Diagram on page 69 SSG Series Configuration on page 69 Pulse Policy Secure Configuration on page 72 Figure 56 on page 69 shows the deployment diagram for the branch resource access policy enforcement deployment. The campus uses an SSG20 device to protect Web server In addition to performing firewall security checks, we deploy the SSG20 to enforce the identity-based resource access policy. Only users mapped to the Enterprise role are allowed to access Web server When Lisa attempts to access this Web server, the SSG20 performs a session lookup against the authentication table (also called the auth table) that has been pushed to it by the branch Pulse Policy Secure. In this scenario, the auth table has an entry for Lisa because she gained access to the branch network through the 802.1x deployment associated with the branch Policy Secure. The auth table entry shows that Lisa belongs to the Enterprise role, so she is allowed to access Web server Figure 56: Branch Resource Access Policy Enforcement Deployment NOC Campus Branch DHCP server IF-MAP client IC series ICA SSG20 AD/DNS Globalcorp.local Unprotected server /32 Protected server Lisa g SSG Series Configuration Table 12 on page 70 describes the features we configured on the SSG Series device to enable enforcement of Pulse Policy Secure resource policy rules by Pulse Secure, LLC. All rights reserved 69

82 Table 12: Branch UAC Enforcer Configuration Feature Description Pulse Policy Secure Instance The Pulse Policy Secure Instance refers to the Policy Secure. NACN Parameters Communication between the SSG device and Policy Secure is secured by NetScreen Address Change Notification (NACN) conventions. Specify: Password. A one-time password. Certificate. Communication between the two components is secured using certificates. For information on importing the certificate, see the Unified Access Control Solution chapter in the ScreenOS Concepts and Examples Reference Guide. Pulse Policy Secure Connection Options Typically, you use the default settings related to communication with the Policy Secure. The settings are configurable to support troubleshooting. Security Policy > Advanced Settings A security policy rule that directs the SSG device to enforce the Policy Secure resource access policy (also called the Infranet Auth policy). If the policy lookup results in a deny action, you can specify a redirect URL, such as a remediation Web page. Figure 57 on page 70, Figure 58 on page 71, and Figure 59 on page 72 show these configurations. Figure 57: ScreenOS Web UI: Configuration > Infranet Auth > Controllers by Pulse Secure, LLC. All rights reserved

83 Chapter 7: Resource Access Policy Deployments Figure 58: ScreenOS Web UI: Configuration > Infranet Auth > General Settings 2015 by Pulse Secure, LLC. All rights reserved 71

84 Figure 59: ScreenOS Web UI: Policy > Policies (From Untrust to Trust) > Advanced Policy Settings Click here to display the complete configuration for this device. Pulse Policy Secure Configuration Table 13 on page 73 describes the features we configured on the Policy Secure to enable enforcement of resource policy rules by Pulse Secure, LLC. All rights reserved

85 Chapter 7: Resource Access Policy Deployments Table 13: Branch Pulse Policy Secure Resource Access Policy Configuration Feature Description Infranet Enforcer Connection information for communication with the SSG Series device: Specify the NACN password that you set on the SSG Series device. Specify the administrator username and password for the SSG Series device. Use the ScreenOS Web UI to look up the SSG Series device serial number. Location Group is not used in this example. Resource Access Policy The Enterprise-Access-Permitted rule allows Enterprise role users access to all ports on servers /24 and /24. Figure 60 on page 73, Figure 61 on page 74, and Figure 62 on page 74 show these configurations. Figure 60: Pulse Policy Secure: UAC > Infranet Enforcer > Connection The policy list on the Infranet Enforcer > Enforcer Policies tab, shown in Figure 61 on page 74, is populated by communication from the SSG Series device. If changes are required, we recommend that you make the changes on the SSG Series device by Pulse Secure, LLC. All rights reserved 73

86 Figure 61: Pulse Policy Secure: Infranet Enforcer > Enforcer Policies Figure 62 on page 74 shows the resource access policies summary for this example. Figure 62: Pulse Policy Secure: Infranet Enforcer > Resource Access Policies Click the following links to download the complete configuration for this device: Part 1, Part by Pulse Secure, LLC. All rights reserved

87 CHAPTER 8 IF-Map Federation IF-MAP Deployment IF-MAP Deployment on page 75 The purpose of the federated deployment is to enable the resource access policy to be enforced at each enforcement point without forcing the employees to enter authentication credentials at each enforcement point. To do this, you configure the Pulse Secure access services to share session information with each other. In the configuration pages of this example, we show the required or relevant parts of the configuration and provide a link for downloading the complete configuration for the lab device. Use the related documentation list to find more detailed information about the feature, including limitations and options we have not shown. The following sections describe and show deployment and configuration details for the federated deployment: Overview on page 75 Pulse Policy Secure IF-MAP Server Configuration on page 77 Pulse Policy Secure IF-MAP Client Configuration on page 84 Pulse Secure Access Service IF-MAP Client Configuration on page 86 Overview In this example, the Pulse Secure network access services are configured to participate in a federation that uses the IF-MAP (Interface for Metadata Access Point) standard protocol to share data about user sessions. The IF-MAP client-server model is similar to common client-server data synchronization models. Many clients report to one server, which is the common synchronization point. The server updates clients from its master data store. Figure 63 on page 76 shows the data synchronization operations between the IF-MAP server and IF-MAP clients. For export operations, session data is transformed to the IF-MAP data standard. For import operations, IF-MAP data is transformed into Pulse Secure client session information by Pulse Secure, LLC. All rights reserved 75

88 Figure 63: IF-MAP Deployment Figure 64 on page 76 shows the topology of our network. Figure 64: Federated Access Service Devices Branch Management /24 Enterprise /24 Guest /24 Remediation /24 Lisa Web server Home L2 switch EX ScreenOS Enforcer SSG20 Bob DHCP server IF-MAP client IC series ICA ISP Branch NOC IF-MAP client SA series SA DHCP server Campus IF-MAP server IC Series ICB L2 switch HP Junos Enforcer SRX100 Campus Management /24 Enterprise /24 Guest /24 Remediation /24 John Web server AD/DNS Globalcorp.local This example has three participants in the IF-MAP federation: The campus Pulse Policy Secure that runs on the campus IC Series device shown in Figure 63 on page 76 is the IF-MAP server. It collects session information exported by Pulse Secure, LLC. All rights reserved

89 Chapter 8: IF-Map Federation by IF-MAP clients. The campus Policy Secure is used in the 802.1x deployment and resource access policy deployment, so it also maintains its own session table. The Pulse Secure Access Service that runs on the SA Series device shown in Figure 63 on page 76 is an IF-MAP client that exports its session information to the IF-MAP server. The campus Policy Secure thereby knows about Bob s authenticated session when he tries to access a Web server protected by the campus firewall, and it uses that information to determine whether Bob is permitted access. Note that the Secure Access Service does not import session information. The branch Policy Secure that runs on the branch IC Series device shown in Figure 63 on page 76 is an IF-MAP client that exports its session information to the IF-MAP server and imports session information from the IF-MAP server. The branch Policy Secure thereby knows about Bob s authenticated session when he tries to access a Web server protected by the branch firewall, and uses that information to determine whether Bob is permitted access. Note that an IF-MAP client does not export session information that it has not learned firsthand that is, it does not export Bob s session information back to the IF-MAP server. Pulse Policy Secure IF-MAP Server Configuration You configure the following settings for the IF-MAP server: Communication with the IF-MAP clients. A session export policy. The session export policy specifies how to transform Pulse Secure session data into IF-MAP standard data. A session import policy. The session import policies select how to transform IF- MAP data into Pulse Secure client session data. Figure 65 on page 78 shows the IF-MAP server setting by Pulse Secure, LLC. All rights reserved 77

90 Figure 65: Pulse Policy Secure: System > IF-MAP Federation > Overview Figure 66 on page 79 through Figure 68 on page 81 show the IF-MAP server s client settings by Pulse Secure, LLC. All rights reserved

91 Chapter 8: IF-Map Federation Figure 66: Pulse Policy Secure: System > IF-MAP Federation > This Server 2015 by Pulse Secure, LLC. All rights reserved 79

92 Figure 67: Pulse Policy Secure: System > IF-MAP Federation > IF-MAP Client by Pulse Secure, LLC. All rights reserved

93 Chapter 8: IF-Map Federation Figure 68: Pulse Policy Secure: System > IF-MAP Federation > IF-MAP Client Figure 69 on page 82 shows the configuration for the IF-MAP server session export policy. The session export policy specifies how to transform Pulse Secure client session data into IF-MAP standard data. In this example, we specify that session data for sessions matching Enterprise and Remediation roles is to be exported as IF-MAP capability data by Pulse Secure, LLC. All rights reserved 81

94 Figure 69: Pulse Policy Secure: System > IF-MAP Federation > Session-Export Policy Figure 70 on page 83 shows the configuration for the IF-MAP server session import policy configured for this example. The session import policy specifies how to transform IF-MAP data into Pulse Secure client session data. In this example, we configure a policy that selects IF-MAP records based on identity (use of the * wildcard matches all) and imports a copy of session records related to all IF-MAP capabilities by Pulse Secure, LLC. All rights reserved

95 Chapter 8: IF-Map Federation Figure 70: Pulse Policy Secure: System > IF-MAP Federation > Session-Import Policy 2015 by Pulse Secure, LLC. All rights reserved 83

96 Click the following links to download the complete configuration for this device: Part 1, Part 2. Pulse Policy Secure IF-MAP Client Configuration You configure the following settings for the IF-MAP client: Communication with the IF-MAP server. A session export policy. The session export policy specifies how to transform Pulse Secure client session data into IF-MAP standard data. A session import policy. The session import policies select how to transform IF- MAP data into Pulse session data. Figure 71 on page 84 shows this configuration. Figure 71: Pulse Policy Secure: System > IF-MAP Federation > Overview Figure 72 on page 85 shows the configuration for the IF-MAP client session export policy configured for this example. The session export policy specifies how to transform Pulse Secure session data into IF-MAP standard data. In this example, we specify that session data for sessions matching Enterprise and Remediation roles is to be exported as IF-MAP capability data by Pulse Secure, LLC. All rights reserved 83

97 Figure 72: Pulse Policy Secure: System > IF-MAP Federation > Session-Export Policy Figure 73 on page 86 shows the configuration for the IF-MAP client session import policy configured for this example. The session import policy specifies how to transform IF-MAP data into Pulse Secure client session data. In this example, we configure a policy that selects IF-MAP records based on identity (use of the * wildcard matches all) and imports a copy of session records related to all IF-MAP capabilities by Pulse Secure, LLC. All rights reserved 85

98 Figure 73: Pulse Policy Secure: System > IF-MAP Federation > Session-Import Policy Click the following links to download the complete configuration for this device: Part 1, Part 2. Pulse Secure Access Service IF-MAP Client Configuration You configure the following settings for the IF-MAP client: Communication with the IF-MAP server. A session export policy. The session export policy specifies how to transform Pulse Secure session data into IF-MAP standard data by Pulse Secure, LLC. All rights reserved

99 Chapter 8: IF-Map Federation Figure 74 on page 87 shows the IF-MAP client configuration. Figure 74: Pulse Secure Access Service: System > IF-MAP Federation > Overview Figure 75 on page 88 shows the session export policy. The session export policy specifies how to transform Pulse Secure session data into IF-MAP standard data. In this example, we specify that session data for sessions matching Enterprise and Remediation roles is to be exported as IF-MAP capability data by Pulse Secure, LLC. All rights reserved 87

100 Figure 75: Pulse Secure Access Service: System > IF-MAP Federation > Session-Export Policy Click the following links to download the complete configuration for this device: Part 1, Part 2. Related Documentation IF-MAP Feature Guide by Pulse Secure, LLC. All rights reserved

101 PART 3 Administration Local Sessions on page 91 Remote Sessions on page 95 Federated Sessions on page by Pulse Secure, LLC. All rights reserved 89

102 CHAPTER 9 Local Sessions Reviewing 802.1x Network Access Logs Reviewing 802.1x Network Access Logs on page 91 You can use the Pulse Policy Secure logs to verify that the components that communicate in response to an 802.1x access request are functioning as expected. The following sequence of screens shows a client connection to the branch network. You can try something similar to observe the logs that are generated when a user connects to the network. Figure 76 on page 91 shows the state of Lisa s OAC client before she makes a connection. The client has no IP address. Figure 76: Odyssey Access Client 2015 by Pulse Secure, LLC. All rights reserved 91

103 Figure 77 on page 92 shows the results of the ipconfig command before Lisa makes a connection. The client has no IP address. Figure 77: ipconfig Figure 78 on page 92 shows the OAC Connect to the network option that Lisa selects to make a connection. Figure 78: Odyssey Access Client Figure 79 on page 93 shows the results of the ipconfig command after Lisa makes the connection. Her host computer is assigned an IP address by Pulse Secure, LLC. All rights reserved

104 Chapter 9: Local Sessions Figure 79: ipconfig Figure 80 on page 93 shows the branch Policy Secure active users table. It shows an entry for Lisa s connection. Figure 80: Pulse Policy Secure: Status > Active Users Figure 81 on page 93 shows the set of logs related to authentication that are written when the user attempts to log in. Figure 81: Pulse Policy Secure: System > Log/Monitoring > User Access 2015 by Pulse Secure, LLC. All rights reserved 93

105 Table 14: User Access Logs Table 14 on page 94 explains what the logs show, from the bottom up. Log ID Description AUT24326 Shows that Lisa was authenticated against the AD server. AUT24803 Shows that Lisa s host computer met the endpoint inspection policy. AUT24414 Shows that Lisa was mapped to the Enterprise and Remediation roles. EAM24459 Shows that Lisa, having passed the endpoint inspection policy, was assigned to the enterprise VLAN. EAM24805 Shows success of RADIUS authentication. Lisa sent an authentication request through the EX3200 switch, which is the RADIUS client. Finally, note that in this IF-MAP deployment, the user session is exported from the IF- MAP client to the IF-MAP server. Figure 82 on page 94 shows the exported session table. Figure 82: Pulse Policy Secure: System > IF-MAP Federation (Client) > Active Users > Exported by Pulse Secure, LLC. All rights reserved

106 CHAPTER 10 Remote Sessions Reviewing SSL VPN Access Logs Reviewing SSL VPN Access Logs on page 95 You can use the Pulse Connect Secure logs to verify the components that communicate in response to SSL VPN client connection request function as expected. The following sequence of screens show the remote client connection that happens in this example Bob s connection from home. Figure 83 on page 95 shows the results of the ipconfig command before Bob initiates a Pulse connection: his host computer shows the IP address for the physical Ethernet adapter. Figure 83: Remote Host Computer: ipconfig Figure 84 on page 96 shows the Pulse Secure client. In this sequence, Bob opens the Pulse Secure client and enters his credentials by Pulse Secure, LLC. All rights reserved 95

107 Figure 84: Pulse Secure Client Upon successful authentication, Bob s host computer now shows both the IP address for the physical Ethernet adapter and the IP address for the SSL VPN connection. Figure 85 on page 96 shows the results of the ipconfig command after Bob s Pulse Secure connection is completed. Figure 85: Remote Host Computer: ipconfig Figure 86 on page 97 shows the set of logs related to authentication that are written when the user attempts to log in by Pulse Secure, LLC. All rights reserved

108 Chapter 10: Remote Sessions Figure 86: Pulse Connect Secure: System > Log/Monitoring > User Access Table 15: User Access Logs Table 15 on page 97 explains what the logs show, starting from the bottom up. Log ID Description AUT24326 Shows that Bob was authenticated against the AD server. Note that it logs the IP address for Bob s host computer AUT24803 Shows that Bob s host computer met the endpoint inspection policy. AUT24414 Shows that Bob was identified as belonging to the Enterprise and Remediation Roles. ERR24670 Shows an attempt to make a network connect connection. FDU24754 Shows that the session information for Bob was exported to the IF-MAP server. NWC2364 Shows the network connect session was started and that the IP address for Bob s session is NWC30477 Shows the SSL VPN connection has been established. Finally, note that in this IF-MAP deployment, the user session is exported from the IF-MAP client to the IF-MAP server. Figure 87 on page 98 shows the exported session table by Pulse Secure, LLC. All rights reserved 97

109 Figure 87: Pulse Connect Secure: System > IF-MAP Federation (Client) > Active Users > Exported by Pulse Secure, LLC. All rights reserved

110 CHAPTER 11 Federated Sessions Reviewing IF-MAP Logs Reviewing IF-MAP Logs on page 99 You can use the Pulse Access Control Service IF-MAP server logs to verify session federation. When Lisa connects to the LAN through branch Pulse Access Control Service and Bob connects to the Pulse Connect Secure, those devices export the session information to the IF-MAP server. The export appears in their respective IF-MAP client export session lists. Figure 88 on page 99 shows the exported session table for the branch Access Control Service. Figure 88: Pulse Access Control Service: System > IF-MAP Federation (Client) > Active Users > Exported Figure 89 on page 100 shows the exported session table for the branch Connect Secure by Pulse Secure, LLC. All rights reserved 99

111 Figure 89: Pulse Connect Secure: System > IF-MAP Federation (Client) > Active Users > Exported Next, Lisa and Bob access a resource protected by the campus enforcer. Figure 90 on page 100 shows the website located behind the firewall. Figure 90: Web Server with IP Address The IF-MAP server imports the session information about Lisa and Bob. Figure 91 on page 100 shows the imported session table. Figure 91: Pulse Access Control Service: System > IF-MAP Federation (Server) > Active Users > Imported by Pulse Secure, LLC. All rights reserved

112 Chapter 11: Federated Sessions In addition, the IF-MAP server logs shown in Figure 92 on page 101 provide detailed information about the same operations. Note the entries that indicate when a session is removed from the IF-MAP server master session table. The IF-MAP server purges sessions a few minutes after the client disconnects. Figure 92: Pulse Access Control Service: System > Log/Monitoring > User Access Next, let s observe a client import policy operation. Let s have Bob access a resource protected by the branch enforcer. Figure 93 on page 101 shows the website located behind the firewall. Figure 93: Web Server with IP Address You can see the entry for Bob in the branch Pulse Secure Access Control Service IF-MAP imported active users table, shown in Figure 94 on page by Pulse Secure, LLC. All rights reserved 101

113 Figure 94: Pulse Access Control Service: System > IF-MAP Federation (Client) > Active Users > Imported Figure 95 on page 102 shows the logs that indicate the session import operation. Figure 95: Pulse Access Control Service: System > Log/Monitoring > User Access Figure 96 on page 103 shows the more verbose event logs. Use the event logs if you need to troubleshoot by Pulse Secure, LLC. All rights reserved

114 Chapter 11: Federated Sessions Figure 96: Pulse Secure Access Control Service: System > Log/Monitoring > Events 2015 by Pulse Secure, LLC. All rights reserved 103