Pan Os 50 Cli Reference Guide

Pulse Policy Secure
Administration Guide
Product Release 5.0
Document Revision 1.0
Published: 2015-05-29
© 2015 by Pulse Secure, LLC. All rights reserved.

Pulse Secure, LLC
2700 Zanker Road, Suite 200
San Jose, CA 95134
http://www.pulsesecure.net
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 Administration Guide
The information in this document is current as of the date on the title page.
END USER LICENSE AGREEMENT
The Pulse Secure product that is the subject of this technical documentation consists of (or is intended for use with) P ulse Secure software.
Use of such software is subject to the terms and conditions of the End User License Agreement (“EULA”) posted at
http://www.pulsesecure.net/support/eula. By downloading, installing or using such software, you agree to the terms and conditions of that
EULA.”
© 2015 by Pulse Secure, LLC. All rights reserved
ii © 2015 by Pulse Secure, LLC. All rights reserved.

Abbreviated Table of Contents
About This Guide .........................................................................................................xxxv
Part 1 Getting Started

Chapter 1 Pulse Policy Secure ............................................................................................................... 3
Chapter 2 Initial Configuration ................................................................................................................. 9
Chapter 3 Deployments with ScreenOS and Junos OS Infranet Enforcers ........................... 77
Chapter 4 Deployments with EX Series Ethernet Switches...................................................... 157
Chapter 5 Layer 2 Network Access Control Policies ...............................................................165
Chapter 6 Deployments with Network and Security Manager ............................................... 209
Chapter 7 User Role Access with the SRX Series Firewall ......................................................... 215
Part 2 Access Management Framework

Chapter 8 General Access Management .....................................................................................231
Chapter 9 User Roles ............................................................................................................................... 261
Chapter 10 AAA Servers............................................................................................................................ 279
Chapter 11 Authentication Realms .........................................................................................................425
Chapter 12 IF-MAP Federation ..........................................................................................................443
Chapter 13 Sign-in Policies .................................................................................................................. 471
Part 3 Endpoint Defense

Chapter 14 Host Checker ......................................................................................................................... 489
Part 4 System Management

Chapter 15 Network and Host Administration ................................................................................ 547
Chapter 16 Certificate Security Administration .............................................................................. 593
Chapter 17 FIPS Level 1 Support (Software FIPS).............................................................. 637
Chapter 18 Configuration File Administration ................................................................................ 657
Chapter 19 System Maintenance ......................................................................................................699
Chapter 20 Logging and Monitoring .................................................................................................. 715
Chapter 21 Troubleshooting Tools............................................................................................................... 751
Chapter 22 Clustering .......................................................................................................................... 773
Chapter 23 Customizable Admin and End-User UIs ..................................................................801
Chapter 24 Delegating Administrator Roles ..................................................................................... 803
© 2015 by Pulse Secure, LLC. All rights reserved. iii

Chapter 25 Deployments with IDP ................................................................................................. 813
Part 5 Appendix
Chapter 26 Policy Secure gateway 4500 and 6500 ...................................................................829
Chapter 27 Using the IC6500 FIPS Appliance (Hardware FIPS) ..................................... 835
Chapter 28 Custom Expressions and System Variables Reference......................................... 843
Part 6 Index
Index ......................................................................................................................................... 865
iv © 2015 by Pulse Secure, LLC. All rights reserved.

Table of Contents
About This Guide ......................................................................................................... xxxv
Objectives ......................................................................................................................... xxxv
Audience ........................................................................................................................... xxxv
Documentation Conventions ....................................................................................... xxxv
Documentation.............................................................................................................. xxxvii
Obtaining Documentation ......................................................................................... xxxvii
Documentation Feedback........................................................................................... xxxvii
Requesting Technical Support .................................................................................. xxxvii
Self-Help Online Tools and Resources............................................................ xxxviii
Opening a Case with PSGSC ........................................................................................... xxxviii

Understanding the Pulse Policy Secure Solution ................................................................. 3
Pulse Policy Secure Solution Overview........................................................................... 3
Pulse Policy Secure Components ........................................................................................ 4
The Pulse Policy Secure Solution in the Network ............................................................5
How the Pulse Policy Secure Determines User Access and Protects Resources .. 7
Chapter 2 Initial Configuration .................................................................................................................9
Understanding Pulse Policy Secure Deployment Options ............................................... 10
Pulse Policy Secure Solution Configuration Overview .........................................................11
Before You Configure the Pulse Policy Secure...................................................................... 12
Using Task Guidance .................................................................................................................. 12
Configuring the Pulse Policy Secure Solution ....................................................................... 13
Deploying the Pulse Policy Secure Solution to Users ......................................................... 16
Pulse Policy Secure Deployment Summary ....................................................................... 19
Understanding the Initial Pulse Policy Secure Deployment User
Experience ............................................................................................................................ 19
Specifying the Client that Endpoints Use for Access ................................................................21
Creating an Initial Configuration of OAC for Windows Endpoints ................................ 22
Understanding OAC Configuration Settings for Windows Endpoints ......................... 23
Defining the Initial Configuration for OAC for Windows ..................................................... 24
Using the Preconfigured Installer for OAC on Windows Endpoints............................. 29
Preconfiguring OAC Using the Custom Installer ............................................................... 29
Validating the IC Series Certificate ............................................................................................30
Using OAC Licenses with the IC Series .................................................................................. 31
Manually Installing OAC......................................................................................................................... 31
Manually Configuring OAC for 802.1X (Windows or Macintosh) .................................. 32
© 2015 by Pulse Secure, LLC. All rights reserved. v

Provisioning Detailed Configuration Profiles for Macintosh OAC Endpoints ............. 34

Understanding Deployments with Pulse Secure Clients .................................................34
Pulse Overview .................................................................................................................. 34
Session Migration ...............................................................................................................35
Location Awareness ...............................................................................................................35
Security Certificates on Pulse ..............................................................................................35
User Experience .................................................................................................................35
Platform Support .....................................................................................................................36
Downloading Pulse to Endpoints with Security Software Installed ......................36
Configuring the Pulse Client for a Role...................................................................................... 36
Pulse Client Configuration Overview ......................................................................................37
Deploying Pulse Client Software to Users ....................................................................37
Pulse Components ..................................................................................................................38
Pulse Client Connections .....................................................................................................39
Default Configuration .............................................................................................................. 40
Understanding Client Connection Set Options .............................................................. 40
Creating a Client Connection Set ..............................................................................................46
Configuring Location Awareness Rules for Pulse Secure Client ....................................49
Understanding Pulse Component Set Options ................................................................ 52
Creating a Client Component Set .............................................................................................53
Installing the Pulse Secure Client on Windows Endpoints Using a Preconfiguration
File..................................................................................................................................................54
Installing the Pulse Client Using Advanced Command-Line Options .............. 56
Examples ............................................................................................................................. 57
Repairing a Pulse Installation on a Windows Endpoint .......................................... 58
Installing the Pulse Secure Client on OS X Endpoints Using a Preconfiguration
File..................................................................................................................................................59
Installing the Pulse Client on OS X Endpoints Using Command-Line
Options ....................................................................................................................... 59
Pulse Secure Client Command-line Launcher ......................................................................60
Using jamCommand to Import Pulse Secure Connections ............................................63
Configuring Machine-Only Machine Authentication for a Pulse Secure
Connection .................................................................................................................................64
Configuring User-After-Desktop Machine Authentication for a Pulse Secure
Connection .................................................................................................................................65
Machine and User Authentication Through a Pulse Connection for Pulse Policy
Secure ................................................................................................................................... 66
Preferred Realm and Role for Pulse Secure Client Machine Authentication ............67
Remote Desktop Protocol Compatibility with Pulse Secure 802.1X Machine
Authentication Connection.................................................................................................69
Credential Provider Authentication for Pulse Policy Secure
Overview .............................................................................................................................. 69
Machine Authentication for Pulse Policy Secure Overview ...............................................71
Additional Methods for Accessing Protected Resources Behind the IC Series
Device............................................................................................................................................ 72
Configuring Agentless Access to Protected Resources.......................................................... 73
Using the Java Agent ........................................................................................................................ 74
Configuring the Java Agent .........................................................................................................74
vi © 2015 by Pulse Secure, LLC. All rights reserved.

Table of Contents
Chapter 3 Deployments with ScreenOS and Junos OS Infranet Enforcers ......................... 77

Using the Infranet Enforcer as a Policy Enforcement Point .............................................79
Understanding Deployments with Junos Infranet Enforcers.............................................. 79
Communication Summary ............................................................................................. 80
Configuration Summary....................................................................................................81
Version Requirements ............................................................................................................. 81
Using Certificate-Based Security with Junos Enforcer Deployments ............................82
Binding an Interface to a Security Zone on a Junos Enforcer ..........................................83
Binding the Physical Interface on the Junos Enforcer ........................................................85
Configuring the Junos Enforcer to Communicate with the Access Control
Service .................................................................................................................................. 86
Setting Up the Junos Enforcer to Work with Pulse Policy Secure……………………..87
Connecting with the Junos Enforcer ........................................................................................88
The IC Series and the Infranet Enforcer..................................................................................89
Understanding Deployments with ScreenOS Infranet Enforcers .................................90
Deployment Summary .................................................................................................... 90
Communication Summary ............................................................................................. 90
Configuration Summary....................................................................................................91
Version Requirements .............................................................................................................. 92
Using Certificate-Based Security with Infranet Enforcer Deployments .......................92
Task Summary: Setting Up Certificates for the IC Series and Infranet
Enforcer ........................................................................................................................................ 93
Setting Up Certificates for the IC Series and Infranet Enforcer .....................................94
Using OpenSSL to Create a CA and Sign the Server Certificate ....................................95
Creating a CA and Signing the Server Certificate Using OpenSSL .............................. 95
Importing the Certificate Into the Infranet Enforcer ............................................................. 97
Configuring Certificate Authority Server Settings .................................................................. 97
Binding an Interface to a Security Zone on a ScreenOS Enforcer ..................................99
Binding the Physical Interface.................................................................................................. 100
ScreenOS Enforcer Configuration Overview ....................................................................... 100
Configuring the ScreenOS Connection................................................................................ 101
Setting Up an Infranet Enforcer in Route Mode ................................................................. 102
Create a Route Mode Interface with the ScreenOS Enforcer ........................................ 103
Setting Up an Infranet Enforcer in Transparent Mode .................................................... 106
Creating a Transparent Mode Instance on the ScreenOS Enforcer ........................... 107
Viewing the Configuration of a Policy Secure gateway on the ScreenOS Enforcer . . .
108 Configuration Details Displayed............................................................................. 108
Web UI ................................................................................................................................ 108
CLI........................................................................................................................................ 109
Understanding the Infranet Enforcer Captive Portal Feature ........................................... 109
Before Configuring Captive Portal............................................................................................ 110
Creating a Redirect Policy on the Infranet Enforcer ............................................................... 111
Overriding the Default Redirection Destination for Captive Portal ............................... 112
Creating a Redirect Policy on the Junos Enforcer ................................................................. 113
Creating a Redirect Policy on the ScreenOS Enforcer ..................................................... 114
Understanding Deployments with ScreenOS Enforcer Virtual Systems........................ 116
ScreenOS Virtual Systems Overview .......................................................................... 116
Overlapping IP Addresses.................................................................................................... 117
© 2015 by Pulse Secure, LLC. All rights reserved. vii

Deployment Example ............................................................................................................ 118

Deployment with IF-MAP Federation Example .......................................................... 119
Configuring the Policy Secure gateway for Overlapping IP Addresses ....................... 120
IPsec Policies ............................................................................................................................. 121
Using IPsec with the Infranet Enforcer..................................................................................... 122
Understanding Pulse Policy Secure Support for IPsec Routing Policies ...................... 123
About IPsec .............................................................................................................................. 123
Access Solution Service Client Support for IPsec Routing Policies ...................... 123
Infranet Enforcer Support for IPsec Routing Policies ............................................... 124
Infranet Enforcer IPsec Policy Features .......................................................................... 124
Dynamic IPsec Routing Policies with ScreenOS Enforcers ...................................... 125
Refreshing IPsec Policies on the IC Series ................................................................... 125
Understanding IPsec Routing Policy Configuration Options .......................................... 126
Configuration Overview .................................................................................................. 126
Configuration Summary................................................................................................. 126
Advanced Configuration Options................................................................................ 127
IPsec Routing Policies .............................................................................................................. 128
Before you Begin ............................................................................................................................ 128
Configuring IPsec Routing Policies ...................................................................................... 129
Using IP Address Pool Policies for IPsec in a NAT Environment .................................... 130
Understanding IP Address Pool Policies ............................................................................ 132
Configuring an IP Address Pool Policy..................................................................................... 133
Understanding ScreenOS Enforcer Source Interface Policies ......................................... 135
Configuring Source Interface Policies .................................................................................. 135
Using the Pulse Policy Secure User Interface to Create Basic ScreenOS
Enforcer IPsec Policies ................................................................................................... 136
Setting Up ScreenOS Enforcer IPsec Routing Policies ....................................................... 137
Configuring ScreenOS Enforcer IPsec Encryption Settings ................................................ 138
Using ScreenOS Enforcer Bidirectional VPN Policies ....................................................... 139
Creating a ScreenOS Bidirectional VPN Policy....................................................................... 139
Configuring Junos Enforcer IPsec Routing Policies .......................................................... 140
Configuration Summary ................................................................................................. 140
Configuration Example......................................................................................................... 141
Infranet Enforcer Policies Overview ..................................................................................... 144
About Resource Access Policies ............................................................................................. 145
Using the Juniper Networks EX Series Ethernet Switch as an Enforcer with
a Resource Access Policy ........................................................................................... 146
Configuring Resource Access Policies ................................................................................ 147
User Role Policies on the Junos Enforcer ................................................................................. 148
Understanding Infranet Enforcer Source IP Security Policies ......................................... 148
Source IP Security Policy Overview ........................................................................... 149
ScreenOS Infranet Enforcer Configuration Summary .............................................. 150
Junos Infranet Enforcer Configuration Summary...................................................... 150
Understanding Infranet Enforcer Auth Tables ........................................................................... 150
Understanding Dynamic Auth Table Allocation ................................................................... 151
Configuring Dynamic Auth Table Allocation ........................................................................ 152
Configuring Auth Table Mapping Policies for Source IP Enforcement ......................... 152
Configuring Auth Table Mapping Policies ......................................................................... 154
viii © 2015 by Pulse Secure, LLC. All rights reserved.

Table of Contents
Chapter 4 Deployments with EX Series Ethernet Switches .................................................... 157

Pulse Policy Secure and Using the EX Series Switch as an Infranet Enforcer ............. 157
Using the EX Series Switch as an Infranet Enforcer ............................................................ 158
Pulse Policy Secure and EX Series Switch Configuration Task Summary ................. 159
Connecting Pulse Policy Secure and the EX Series Switch................................................ 160
Understanding Captive Portal with Pulse Policy Secure and the
EX Series Switch .................................................................................................................... 160
Understanding Auth Tables with the EX Series Switch ...................................................... 161
Using Resource Access Policies with the EX Series Switch ............................................ 161
Using the Pulse Policy Secure RADIUS Server ..................................................................... 166
Understanding Pulse Policy Secure RADIUS Server Features ............................................ 167
Understanding Pulse Policy Secure Authentication Protocols ......................................... 168
Using Pulse Policy Secure Authentication Protocol Sets..................................................... 170
Using an 802.1X IP Phone with the IC Series ............................................................. 173
Configuring Authentication Protocol Sets ............................................................................. 173
Using RADIUS Proxy ...................................................................................................................... 174
Understanding RADIUS Authentication and Accounting Time Limits ........................ 176
Understanding 802.1X Network Access Control Deployments..................................... 178
Task Summary: Configuring the Policy Secure gateway as a RADIUS Server for an
802.1X Network Access Device ......................................................................................... 180
Using Location Groups with Network Access Devices ................................................... 180
Configuring a Location Group ............................................................................................... 182
Understanding the RADIUS Client Configuration................................................................ 183
RADIUS Client Configuration Overview ..................................................................... 183
Sending Disconnect Requests to NADs (Dynamic Authorization Support)
Using a RADIUS Client Policy ................................................................................... 184
Before Configuring a RADIUS Client ................................................................................ 184
Configuring a RADIUS Client ................................................................................................ 185
Using RADIUS Client Dictionary Files ....................................................................................... 186
Uploading a New RADIUS Client Dictionary ...................................................................... 187
Creating a RADIUS Dictionary Based on an Existing Model .......................................... 187
Creating RADIUS Dictionary Files ............................................................................................... 188
Understanding RADIUS Attributes Policies ........................................................................ 190
RADIUS Attributes Policy Configuration Guidelines ......................................................... 191
Creating a RADIUS Attributes Policy ........................................................................................ 192
Understanding RADIUS Request Attribute Policies ......................................................... 194
Configuring a RADIUS Request Attribute Policy................................................................... 195
Understanding RADIUS Attribute Logging.............................................................................. 195
Configuring RADIUS Attribute Logging .................................................................................. 196
Using RADIUS Attributes in Access Policies ...................................................................... 196
Use Case 1: Configuring VLAN Assignment by Returning RADIUS Tunnel
Attributes ......................................................................................................................... 196
Use Case 2: Configuring VLAN Assignment Along with Other Attributes . . . 197
Use Case 3: Configuring VLAN Assignment or Policies by using the Filter-ID
Return Attribute ............................................................................................................ 197
© 2015 by Pulse Secure, LLC. All rights reserved. ix

Use Case 4: Configuring VLAN Assignment in a Heterogeneous

Environment............................................................................................................... 197
Use Case 5: Using RADIUS Attributes with OAC to Avoid Disconnecting
Concurrent Network Connections.......................................................................198
Use Case: Using an EX Series Ethernet Switch as a RADIUS Client ...........................199
Associating an Infranet Enforcer with the Pulse Policy Secure RADIUS
Server.......................................................................................................................................... 202
Use Case: Using a Non-Pulse Secure 802.1X Supplicant ............................................ 203
Before Configuring a Non-Pulse Secure Supplicant .................................................... 204
Configuring a Non-Pulse Secure Supplicant for 802.1X .............................................. 205
Configuring Access to Switches and Access Points from a Browser .......................... 206
Authenticating Users with Non-Tunneled Protocols ....................................................... 206
Enabling Endpoints to Connect to VLANs behind the Policy Secure gateway ........ 207
Chapter 6 Deployments with Network and Security Manager ............................................. 209
Understanding Network and Security Manager Support for Policy Secure gateways .
. 209 How the IC Series and NSM Communicate................................................... 209
Available Services and Configuration Options......................................................... 211
DMI Communication with the IC Series ...................................................................... 211
Configuring the Policy Secure gateway for the Initial DMI Connection ..................... 212
General NSM Operations....................................................................................................... 214
Using NSM with the IC Series and the Infranet Enforcer........................................ 214
Managing IPsec with the Infranet Enforcer Through NSM .................................... 214
Adding IC Series Clusters..................................................................................................... 214
Chapter 7 User Role Access with the SRX Series Firewall .......................................................215
User Role Firewall Policies .................................................................................................... 215
Licensing Restrictions and Disabled Features ..................................................................... 216
Terminology for Active Directory SPNEGO Authentication with User Role
Policies ................................................................................................................................. 217
User Authentication Sequence for Active Directory.......................................................... 219
Supported Versions ...................................................................................................................... 220
Configuration Summary .......................................................................................................... 221
Configure an Active Directory Instance on Pulse Policy Secure……………………..222
Active Directory Integration Notes ............................................................................................ 223
Sample Active Directory Commands......................................................................... 224
Additional Information .................................................................................................. 224
User Log Messages on the MAG Series Device ..........................................................225
Create the Keytab File and Enable Single Sign-on ............................................................225
Configuring SPNEGO Authentication in Browsers ............................................................ 226
Browser Configuration.......................................................................................................... 226

Chapter 8 General Access Management .................................................................................... 231
Access Management Overview .............................................................................................. 231
Understanding Realm and Role Restrictions ................................................................. 232
Restrictions Overview .................................................................................................... 232
Accessing Authentication Realms .................................................................................. 233
x © 2015 by Pulse Secure, LLC. All rights reserved.

Table of Contents
Accessing User Roles ........................................................................................................... 233

Realm and Role Restrictions Sequence ........................................................................ 234
Understanding the Evaluation Process for Policies, Rules, Restrictions, and
Conditions ......................................................................................................................... 234
Using the Dynamic Policy Evaluation Feature .................................................................. 239
Dynamic Policy Evaluation Overview ........................................................................ 239
Understanding Dynamic Policy Evaluation ................................................................ 240
Understanding Standard Policy Evaluation ................................................................. 240
Enabling Dynamic Policy Evaluation ............................................................................ 240
Using Source IP Access Restrictions ................................................................................... 241
Source IP Access Restriction Overview ..................................................................... 241
Specifying Source IP Restrictions ................................................................................... 242
Specifying Browser Access Restrictions ............................................................................. 243
Specifying Certificate Access Restrictions .......................................................................... 244
Specifying Password Access Restrictions............................................................................. 245
Specifying Host Checker Access Restrictions .................................................................... 246
Specifying RADIUS Request Attributes ................................................................................. 247
Selecting Single Sign-on ............................................................................................................. 247
Specifying Session Limits .......................................................................................................... 248
Specifying Resources for User Access Control .................................................................. 249
Using Host Enforcer Policies .................................................................................................. 251
Understanding Session Migration ....................................................................................... 255
Session Migration Overview .......................................................................................... 255
Session Migration and Session Timeout ................................................................... 257
How Session Migration Works .......................................................................................... 257
Session Migration and Session Lifetime.................................................................... 258
Session Migration and Load Balancers........................................................................ 258
Authentication Server Support ....................................................................................... 258
Task Summary: Configuring Session Migration................................................................. 259
Configuring Session Migration for the Pulse Client ........................................................ 260
Understanding User Roles........................................................................................................... 261
User Roles Overview ...................................................................................................... 261
User Role Evaluation ............................................................................................................ 262
Permissive Merge Guidelines ....................................................................................... 265
Configuration of User Roles ............................................................................................... 265
Defining Default Options for User Roles................................................................................. 266
Configuring General Role Options ....................................................................................... 267
Configuring a Guest User Account Management Role ................................................... 267
Using Role Restrictions .............................................................................................................. 268
Specifying Session Options ................................................................................................. 268
Specifying UI Options for Agentless Access ........................................................................... 271
Setting Up E-mail for Guest User Accounts........................................................................ 272
Creating a MAC Address Authentication Role ....................................................................... 274
Specifying Role Access Options ........................................................................................ 274
Use Case: Using a Host Checker Policy with the Host Enforcer ...................................... 276
© 2015 by Pulse Secure, LLC. All rights reserved. xi

Chapter 10 AAA Servers ............................................................................................................................279

AAA Server Overview ............................................................................................................. 279
Understanding the Role of AAA Servers in the Pulse Secure Access
Management Framework ......................................................................................... 280
Authentication Protocols Used by AAA Servers ........................................................... 281
AAA Server Configuration Task Summary ................................................................. 281
Using the Local Authentication Server ................................................................................. 282
Local Authentication Server Overview ...................................................................... 282
Understanding the Local Authentication Server ............................................ 282
Requirements and Limitations............................................................................. 282
Configuring the Local Authentication Server................................................................ 283
Creating User Accounts....................................................................................................... 285
Managing User Accounts .................................................................................................... 287
Creating Administrator User Accounts .......................................................................... 289
Using Active Directory .................................................................................................................. 290
Microsoft Windows Platform Active Directory Service Overview ...................... 290
Understanding Active Directory ............................................................................... 291
Active Directory Feature Support ......................................................................... 291
Interoperability Requirements and Limitations................................................ 291
Understanding the Active Directory Standard Configuration and Active
Directory Legacy Mode Configuration........................................................... 292
Configuring Authentication and Authorization with Active Directory Service
(Standard Mode) ..................................................................................................... 292
Configuring Authentication and Authorization with Active Directory Service
(Legacy Mode)........................................................................................................... 297
Displaying the User Accounts Table ........................................................................................ 302
Using Kerberos SSO ...................................................................................................................... 303
Kerberos SSO Support Overview ................................................................................ 303
Requirements and Limitations ........................................................................................ 303
Enabling Kerberos SSO ............................................................................................. 304
Understanding Multi-Domain User Authentication ........................................................ 304
Multi-Domain User Authentication Overview ........................................................ 305
Windows NT User Normalization .................................................................................... 305
Kerberos Support ................................................................................................................. 305
Windows NT4 Support ....................................................................................................... 306
Understanding Active Directory and Windows NT Group Information
Support ..................................................................................................................................... 306
Active Directory Group Information Overview .......................................................... 306
Windows NT4 Group Information Overview ............................................................. 307
Importing and Exporting an Active Directory Mode Configuration................................ 307
Using the Anonymous Server .................................................................................................. 308
Anonymous Server Overview ...................................................................................... 308
Understanding the Anonymous Server .............................................................. 308
Anonymous Server Feature Support ................................................................... 308
Interoperability Requirements and Limitations .............................................. 309
Configuring Authentication with the Anonymous Server ........................................ 309
Monitoring Anonymous User Sessions ...................................................................... 311
xii © 2015 by Pulse Secure, LLC. All rights reserved.

Table of Contents
Using the Certificate Server ........................................................................................................312

Certificate Server Overview............................................................................................ 312
Understanding the Certificate Server ...................................................................... 312
Feature Support ....................................................................................................... 312
Interoperability Requirements and Limitations ............................................... 312
Configuring Authentication with the Certificate Server ........................................... 313
Displaying the User Accounts Table ...........................................................................................315
Using an LDAP Server .................................................................................................................... 316
LDAP Server Overview ................................................................................................... 316
Understanding LDAP Server...................................................................................... 316
LDAP Feature Support ............................................................................................ 317
Interoperability Requirements and Limitations ............................................... 317
Configuring Authentication with an LDAP Server ....................................................... 317
Displaying the User Accounts Table ............................................................................................322
Using the LDAP Password Management Feature .............................................................. 323
LDAP Password Management Feature Overview .................................................. 323
Enabling LDAP Password Management .................................................................. 324
LDAP Password Management Support......................................................................... 324
LDAP Password Management for Windows AD Versions ...................................... 326
Troubleshooting LDAP Password Management .................................................... 328
Using the MAC Address Authentication Server ..................................................................... 328
MAC Address Authentication Server Overview ..................................................... 328
Understanding MAC Address Authentication ................................................... 328
MAC Address Authentication Server Feature Support................................... 329
Interoperability Requirements and Limitations............................................... 329
Licensing ................................................................................................................... 329
MAC Address Authentication Framework Configuration Overview............. 329
802.1x Framework Configuration Overview..................................................... 330
Ethernet Switch MAC Address Authentication Configuration
Overview ........................................................................................................... 330
Configuring the MAC Address Authentication Server ............................................... 330
Example: Using Endpoint Discovery and Profiling for MAC Address
Authentication .................................................................................................................. 334
About Endpoint Discovery and Profiling ....................................................................... 334
Obtaining the MAG-SM360-PROFILER Service Module ................................... 335
Installing the MAG-SM360-PROFILER Service Module ................................... 335
Getting Started with Endpoint Profiler on the MAG-SM360-PROFILER
Service Module ....................................................................................................... 336
Licensing the Beacon Endpoint Profiler Software ....................................................... 337
Using the Beacon Endpoint Profiler to Discover Devices in Your Network . . 338
Configuring the Beacon Endpoint Profiler LDAP Features ...................................... 338
Configuring the Pulse Policy Secure MAC Address Authentication Framework
............................................................................................................................................. 344
Configuring the Authentication Protocol Set ................................................... 345
Configuring the Authentication Servers ............................................................... 346
Configuring User Roles for the MAC Address Authentication Realm . . . 353
Configuring the MAC Address Authentication Realm and Role Mapping
Rules ......................................................................................................................... 354
© 2015 by Pulse Secure, LLC. All rights reserved. xiii

Configuring the RADIUS Framework ...................................................................... 357

Configuring the EX Series Switch ................................................................................... 360
Using an NIS Server ...................................................................................................................... 367
NIS Server Overview ....................................................................................................... 367
Understanding NIS Server .......................................................................................... 367
Feature Support ........................................................................................................... 368
Configuring Authentication with an NIS Server ........................................................... 368
Displaying the User Accounts Table ...........................................................................................371
Using a RADIUS Server ................................................................................................................. 372
RADIUS Server Overview .............................................................................................. 372
Understanding RADIUS Server ................................................................................. 372
Feature Support ............................................................................................................ 372
Using Challenge Expressions ............................................................................... 373
Using RADIUS Attributes ............................................................................................ 373
Understanding RADIUS Accounting ..................................................................... 380
Configuring Authentication with a RADIUS Server .................................................... 383
Displaying the User Accounts Table ...................................................................................... 389
Using an ACE Server .................................................................................................................... 390
RSA Authentication Manager Overview ...................................................................... 391
Understanding RSA Authentication Manager ................................................... 391
Feature Support ............................................................................................................ 392
Configuring Authentication with RSA Authentication Manager ........................ 393
Displaying the User Accounts Table ........................................................................................ 395
Using a SiteMinder Server .......................................................................................................... 396
SiteMinder Server Overview ......................................................................................... 396
Understanding SiteMinder Server.......................................................................... 396
Feature Support ............................................................................................................ 397
Configuring the Back-End SiteMinder Server ........................................................... 399
Configuring the SiteMinder Agent ....................................................................... 400
Configuring the Authentication Scheme ........................................................... 400
Configuring the SiteMinder Domain................................................................... 402
Configuring the SiteMinder Realm ....................................................................... 402
Configuring a Rule or Response Pair to Pass Usernames............................ 402
Configuring Authentication with a SiteMinder Server ........................................... 403
Displaying the User Accounts Table............................................................................................414
Troubleshooting the SiteMinder Server Configuration...................................................... 415
Using an SQL Server ..................................................................................................................... 416
SQL Server Overview ...................................................................................................... 416
Understanding SQL Server ........................................................................................ 416
Feature Support ............................................................................................................ 416
Interoperability Requirements and Limitations ................................................ 419
Configuring Authentication with an Oracle SQL Server............................................. 419
Troubleshooting Oracle Error Codes ....................................................................................... 423
xiv © 2015 by Pulse Secure, LLC. All rights reserved.

Table of Contents
Chapter 11 Authentication Realms ........................................................................................................ 425

Understanding Authentication Realms ................................................................................... 425
Before Configuring a Realm ...................................................................................................... 426
Creating an Authentication Realm............................................................................................. 427
Configuring a MAC Address Authentication Realm ........................................................ 429
Defining Authentication Access Policies ............................................................................ 432
Understanding Role Mapping Rules ........................................................................................ 432
Specifying Role Mapping Rules for an Authentication Realm ..................................... 433
Using the LDAP Server Catalog ................................................................................................ 435
Customizing User Realm UI Views ......................................................................................... 440
Understanding Federated Deployments .............................................................................. 443
IF-MAP Federation Overview ....................................................................................... 444
Example Topology ...................................................................................................................... 445
IF-MAP Federation Configuration Overview ........................................................... 447
Supported IF-MAP Clients ................................................................................................. 448
IF-MAP and Session Migration ......................................................................................... 448
IF-MAP Federation Licensing ............................................................................................ 448
IF-MAP Logging..................................................................................................................... 449
IF-MAP Federation Network Timing Considerations ................................................ 449
About IF-MAP Federation Performance ....................................................................... 449
IF-MAP Federation Quick Start ................................................................................................. 450
Task Summary: Configuring IF-MAP Federation................................................................... 451
Configuring IF-MAP Server Settings ...................................................................................... 453
Configuring IF-MAP Client Settings ...................................................................................... 454
Understanding Session-Export and Session-Import Policies ...................................... 455
Session-Export and Session-Import Policies Overview....................................... 455
Default Session-Export and Session-Import Policy Action ................................... 457
Advanced Session-Export and Session-Import Policies ........................................ 457
Administrative Domains in Session-Export Policies ............................................... 457
Configuring Session-Export Policies ..................................................................................... 458
Configuring Session-Import Policies .................................................................................... 460
Modifying Session-Export and Session-Import Policies ................................................ 461
Troubleshooting the IF-MAP Federation Network ............................................................... 462
Viewing Active Federated Session Tables....................................................................................... 462
Viewing Active Users on the IF-MAP Client ............................................................. 462
Viewing Active Users on the IF-MAP Server .............................................................. 463
Understanding IF-MAP Server Replicas ................................................................................ 463
Configuring IF-MAP Server Replicas ...................................................................................... 465
Understanding Clustering in a Federated Deployment.................................................. 465
IF-MAP Server Clustering ..................................................................................................... 465
IF-MAP Client Clustering .................................................................................................... 467
Understanding Coordinated Threat Control in an Federated Deployment ............... 467
Using IDP Devices in a Federated Deployment ............................................................. 469
Using IF-MAP Enabled Network Equipment .................................................................. 469
© 2015 by Pulse Secure, LLC. All rights reserved. xv


About Sign-In Policies.............................................................................................................. 471
Task Summary: Configuring Sign-In Policies...................................................................... 472
About Configuring Sign-In Policies ..................................................................................... 473
Configuring Administrator Sign-In Policies ....................................................................... 474
Associating Authentication Realms and Protocols with User Sign-in Policies . . 475
Before Configuring Sign-In Policies ..................................................................................... 479
Configuring and Managing Sign-In Policies ....................................................................... 480
Configuring User Sign-In Policies ................................................................................... 480
Enabling and Disabling Sign-in Policies ..................................................................... 481
Specifying the Order of Evaluation ................................................................................ 481
Using Sign-In Notifications ................................................................................................... 482
Configuring and Implementing Sign-In Notifications...................................................... 483
Configuring Sign-In Pages ................................................................................................................ 485
Sign-In Page Options ..................................................................................................... 485
Configuring Standard Sign-In Pages .................................................................................. 486

Host Checker and Trusted Network Computing.............................................................. 490
Host Checker Compatibility ......................................................................................... 491
Host Checker Overview ........................................................................................................ 492
Upgrading the Software Version ............................................................................................ 492
Creating Global Host Checker Policies ................................................................................. 493
Task Summary: Configuring Host Checker ......................................................................... 494
Using Host Checker for Machine Account Logins ............................................................ 495
Using the Predefined Enhanced Endpoint Security Option ........................................ 496
Enhanced Endpoint Security Option Overview ...................................................... 496
Enhanced Endpoint Security User Experience ....................................................... 497
Enabling the Enhanced Endpoint Security Option ............................................... 498
Checking for Third-Party Applications Using Predefined Rules....................................... 498
Configuring a Predefined Antivirus Rule with Remediation Options (Windows
and Macintosh) ............................................................................................................... 500
Configuring a Predefined Firewall Rule with Remediation Options (Windows
and Macintosh)............................................................................................................... 502
Configuring a Predefined AntiSpyware Rule (Windows and Macintosh) ................ 504
Specifying Customized Requirements Using Custom Rules ....................................... 505
Using a Wildcard or Environment Variable in a Host Checker Rule................................ 511
Patch Management Info Monitoring and Patch Deployment ..................................... 512
Additional Functionality with Pulse 2.0......................................................................... 513
User Experience ............................................................................................................... 514
Using a System Management Server ............................................................................... 514
Configuring Virus Signature Version Monitoring and Patch Assessment Info
Monitoring and Patch Deployment ........................................................................... 515
Configuring Patch Remediation Options ............................................................................ 518
Configuring Host Checker Patch Assessment Rules ........................................................... 518
Using Third-Party Integrity Measurement Verifiers.............................................................. 520
xvi © 2015 by Pulse Secure, LLC. All rights reserved.

Table of Contents
Configuring a Remote IMV Server ..............................................................................................521

Implementing a Third-Party IMV Policy................................................................................ 526
Using Statement of Health Integration Host Checker Policies....................................... 527
Configuring a Statement of Health Host Checker Policy ............................................... 529
Implementing Host Checker Policies .................................................................................. 531
Executing Host Checker Policies ................................................................................. 532
Configuring Host Checker Restrictions.............................................................................. 533
Understanding Host Checker Policy Remediation ........................................................... 535
Remediation Options...................................................................................................... 535
Remediation User Experience .................................................................................... 536
Configuring General Host Checker Remediation ................................................................. 537
Upgrading the Endpoint Security Assessment Plug-In ............................................... 538
Specifying General Host Checker Options ..................................................................... 540
Specifying Host Checker Installation Options ................................................................. 542
Installing Host Checker Automatically or Manually ........................................................ 543
Using Host Checker Logs ............................................................................................................. 544

Network and Host Administration Overview ...................................................................... 547
Configuring the Internal Port ...................................................................................................... 548
Configuring the External Port.................................................................................................... 553
Using the Management Port .................................................................................................... 557
Management Port Overview ........................................................................................ 557
Supported Platforms .................................................................................................................. 558
Configuring the Management Port .............................................................................. 558
Using the Serial Console to Configure the Management Port ........................... 562
Importing Configurations that Include a Management Port
Configuration .................................................................................................................. 562
Configuring Administrator Access................................................................................... 563
Configuring VLAN Ports.............................................................................................................. 563
Using Virtual Ports ........................................................................................................................ 566
Configuring Virtual Ports.................................................................................................... 566
Using Device Certificates with Virtual Ports.............................................................. 568
Configuring the System Date and Time .............................................................................. 571
Configuring Network Services.................................................................................................... 574
Managing the Routes Table........................................................................................................................577
Managing the Hosts Table...........................................................................................................................579
Managing the ARP Table ........................................................................................................................... 580
Managing the Neighbor Discovery Table ...........................................................................................581
Configuring SSL Options ...................................................................................................... 582
Configuring Miscellaneous Security Options ................................................................... 587
Using the Serial Port .................................................................................................................... 589
Connecting to the Serial Port Console .......................................................................... 589
Using the Serial Console to Roll Back to a Previous OS Version ......................... 590
Using the Serial Console to Reset the System to the Factory Image................ 591
© 2015 by Pulse Secure, LLC. All rights reserved. xvii

Chapter 16 Certificate Security Administration ............................................................................. 593

Understanding Digital Certificate Security............................................................................. 593
Using Device Certificates.............................................................................................................. 595
Understanding Device Certificates ................................................................................. 595
Understanding Self-Signed Certificates ...................................................................... 595
Importing a Device Certificate and Private Key ............................................................ 596
Creating a Certificate Signing Request ....................................................................... 599
Importing a Signed Certificate Created from a CSR................................................ 600
Understanding Intermediate Certificates....................................................................... 601
Importing Intermediate CA Certificates ...................................................................... 602
Importing a Renewed Certificate That Uses the Existing Private Key .............. 603
Downloading a Device Certificate .................................................................................. 604
Using Device Certificates With Virtual Ports .............................................................. 604
Using Trusted Client CAs............................................................................................................ 608
Understanding Trusted Client CAs............................................................................... 608
Trusted Client CA Implementation Notes .................................................................. 609
Understanding CRLs ..................................................................................................... 609
Understanding OCSP....................................................................................................... 611
Importing a Trusted Client CA Certificate ..................................................................... 611
Renewing a Certificate......................................................................................................... 613
Configuring Auto-Importing of Client Certificates .................................................... 613
Configuring Options for Trusted Client CA Certificates ........................................... 615
Configuring a Proxy Server for CRL Downloads and OCSP Status Checks . . 621
Using Trusted Server CAs ............................................................................................................. 622
Understanding Trusted Server CAs ................................................................................. 623
Uploading Trusted Server CA Certificates ..................................................................... 623
Restoring the Prepopulated Group of Trusted Server CA Certificates ............. 625
Renewing a Trusted Server CA Certificate................................................................... 625
Deleting a Trusted Server CA Certificate ..................................................................... 626
Understanding ECC Certificates ............................................................................................. 626
About Suite B .................................................................................................................. 627
Using ECC Certificates with Pulse Connect Secure and Access Control
Service ........................................................................................................................ 627
Example: Assigning an ECC P-256 Certificate to an External Virtual Port and
Giving Preference to Suite B Ciphers ............................................................................ 628
Configuring the External Port .......................................................................................... 628
(optional) Configuring the Virtual Ports ..................................................................... 629
Creating the Certificate Signing Request for a New Certificate ......................... 630
Importing the Signed Certificate Created from a CSR ............................................ 632
Presenting the Certificate on the Network ..................................................................... 632
Setting the Security Options ...................................................................................... 633
Understanding Pulse Secure FIPS Level 1 Support ......................................................... 637
What Is FIPS? .................................................................................................................. 637
What Is FIPS Level 1 Support? ...................................................................................... 638
FIPS Supported Platforms ................................................................................................................ 638
Enabling FIPS Level 1 Support ............................................................................................... 638
Verifying the Certificate on the Client ................................................................................. 642
xviii © 2015 by Pulse Secure, LLC. All rights reserved.

Table of Contents
Using TCP Dump to View Cipher Information ................................................................644

Turning Off FIPS Level 1 Support from the Serial Console ................................................ 647
Installing a Self-Signed Certificate From the Serial Console ........................................ 647
Supported Cipher Suites when FIPS Level 1 Support is Enabled and Disabled . . 648
Supported Cipher Suites When FIPS Level 1 Support is Disabled......................... 648
Supported Cipher Suites When FIPS Level 1 Support is Enabled ......................... 652
Configuration File Administration Overview ..................................................................... 657
Configuring Archiving for System Logs, Configuration Files, and Snapshots . . . 658
Using the Configuration Backup and Restore Feature........................................................ 664
Using the Import/Export Feature for Binary System Configuration Files ................... 665
Binary System Configuration File Overview ............................................................. 666
Exporting a Binary System Configuration File .............................................................. 667
Importing a Binary System Configuration File .............................................................. 668
Using the Import/Export Feature for Binary User Configuration Files ......................... 670
Binary User Configuration File Overview.................................................................... 670
Exporting a Binary User Configuration File ................................................................... 671
Importing a Binary User Configuration File ................................................................. 673
Using the Import/Export Feature for XML Configuration Files ........................................ 674
XML Configuration File Overview ................................................................................. 674
Guidelines and Limitations............................................................................................ 674
Exporting an XML Configuration File .............................................................................. 675
Importing an XML Configuration File.............................................................................. 679
Guidelines for Modifying Configuration XML Files.............................................................. 680
Preparing to Modify a Configuration XML File .............................................................. 680
Understanding the XML Export File ................................................................................ 681
Comparing Configuration Settings and Values Shown in the User Interface
with the Ones in the XML File ................................................................................. 684
Understanding Referential Integrity Constraints...................................................... 684
Using Operation Attributes ............................................................................................. 686
Example: Using the Configuration XML File Import/Export Feature to Add Multiple
Users ................................................................................................................................... 688
Using the Push Configuration Feature .................................................................................... 690
Push Configuration Overview .................................................................................... 690
Guidelines and Limitations .............................................................................................. 690
Configuring Targets ..................................................................................................................... 691
Configuring Push Settings................................................................................................ 693
Viewing Configuration Push Results ................................................................................. 696
Using the System Maintenance Pages ....................................................................................... 699
Configuring System Maintenance Options ..................................................................... 700
Upgrading the System Software................................................................................................. 703
Downloading a Software Package .................................................................................. 703
Uploading a Software Package........................................................................................ 704
Upgrading the System Software .................................................................................... 705
Downgrading the System Software .................................................................................. 707
Rolling Back the System Software .................................................................................. 707
Downloading Client Installer Files............................................................................................. 708
© 2015 by Pulse Secure, LLC. All rights reserved. xix

Restarting, Rebooting, and Shutting Down the System..................................................... 711

Testing Network Connectivity ............................................................................................... 712
Logging Overview .................................................................................................................... 715
Configuring Events to Log............................................................................................................ 716
Configuring SNMP .................................................................................................................... 719
Configuring Syslog......................................................................................................................... 728
Enabling Client-Side Logging ..................................................................................................... 731
Displaying System Status ............................................................................................................. 731
Displaying Hardware Status ...................................................................................................... 735
Displaying Active Users ......................................................................................................... 738
Displaying System Logs ................................................................................................................ 739
Displaying Events Logs ........................................................................................................ 740
Displaying User Access Logs .............................................................................................. 742
Displaying Admin Access Logs ......................................................................................... 743
Displaying Sensor Logs........................................................................................................ 743
Using Log Filters.............................................................................................................................. 744
Reviewing the Configuration of Predefined Log Format Filters .............................. 744
Creating a Custom Log Collection Filter ......................................................................... 745
Example: Using the Source IP Address Filter............................................................. 747
Displaying User Access Statistics ........................................................................................... 748
Using the Admin Console Troubleshooting Tools .................................................................. 751
Using Policy Tracing .............................................................................................................................. 752
Using the Debug Log ..................................................................................................................... 757
Using the RADIUS Diagnostic Log ............................................................................................. 759
Using the tcpdump Utility ..................................................................................................... 760
Using Network Troubleshooting Commands ................................................................... 762
Troubleshooting TCP and UDP Port Status ........................................................................ 765
Running NSLookup to Test Name Server Connectivity.................................................. 768
Using the Kerberos Debugging Utility................................................................................ 770
Using Remote Debugging ........................................................................................................... 771
About Clustering............................................................................................................................. 773
About Cluster Licensing ......................................................................................................... 775
Task Summary: Deploying a Cluster ........................................................................................ 776
Defining and Initializing a Cluster ............................................................................................ 777
Joining an Existing Cluster.......................................................................................................... 778
Before You Begin ................................................................................................................... 778
Specifying a Policy Secure gateway to Join to a Cluster ....................................... 778
Adding a Policy Secure gateway to a Cluster Through the Admin Console.. 779
Re-Adding a Node to a Cluster................................................................................................ 779
Deploying Two Nodes in an Active/Passive Cluster ........................................................ 780
Failing Over the VIP to Another Node ................................................................................. 782
Deploying Two or More Units in an Active/Active Cluster ................................................. 782
Synchronizing the Cluster State................................................................................................ 784
Specifying Active/Passive, Active/Active, and Other Cluster Settings ...................... 787
xx © 2015 by Pulse Secure, LLC. All rights reserved.

Table of Contents
Adding Multiple Cluster Nodes ........................................................................................... 788

Managing Network Settings for Cluster Nodes .................................................................. 789
Changing the IP Address of a Cluster Node ...................................................................... 789
Deleting a Cluster............................................................................................................................ 790
Restarting or Rebooting Cluster Nodes ............................................................................... 790
Summary: Admin Console Cluster Procedures ................................................................. 791
Monitoring Clusters....................................................................................................................... 793
NSRP Clustering Considerations with the ScreenOS Enforcer ................................... 794
Using the Policy Secure gateway with an SRX Series Cluster .......................................... 795
Troubleshooting Cluster Communication Problems ......................................................... 795
Summary: Serial Console Cluster Procedures .................................................................... 797
Joining a Policy Secure gateway to a Cluster Through Its Serial Console.................... 798
Disabling a Clustered Policy Secure gateway Using Its Serial Console......................... 799
Chapter 23 Customizable Admin and End-User UIs ..................................................................801
Customizable Admin Console and End User Elements Overview ................................ 801
Customizable End-User Interface Elements Overview ......................................... 802
Chapter 24 Delegating Administrator Roles ..................................................................................... 803
About Delegating Administrator Roles...................................................................................... 803
Creating Administrator Roles ..................................................................................................... 804
Specifying Management Tasks to Delegate ........................................................................ 805
Delegating System Management Tasks ............................................................................... 805
Delegating User and Role Management .................................................................. 806
Delegating User Realm Management ....................................................................... 806
Delegating Administrative Management ................................................................. 806
Delegating Resource Policy Management ............................................................... 807
Defining Role Management Privileges for an Administrative Role ................................. 807
Defining Realm Management Privileges for an Administrative Role ............................. 808
Defining Security Administrator Privileges............................................................................. 809
Defining General System Administrator Role Settings ....................................................... 810
Chapter 25 Deployments with IDP ..................................................................................................813
About IDP Technology ......................................................................................................................... 813
IDP Deployment Scenarios Overview ............................................................................... 815
Understanding Pulse Policy Secure Deployments with IDP
Devices....................................................................................................................................... 817
About IDP Devices ................................................................................................................. 817
Coordinated Threat Control Overview ....................................................................... 817
Deployments with IDP Series Devices ......................................................................... 818
Deployments with IDP-Enabled Infranet Enforcers ................................................. 818
Monitoring IDP-Reported Events ................................................................................... 819
Activating IDP for the ScreenOS or Junos Enforcer ............................................................. 820
Managing Interoperation with IDP Devices ......................................................................... 820
Configuring Communication with an IDP Device ...................................................... 820
Enabling or Disabling IDP Sensors.............................................................................. 821
Reconnecting to an IDP Sensor ...................................................................................... 822
Refreshing and Displaying the Connection Status .................................................... 822
Deleting an IDP Sensor Entry ........................................................................................ 822
Defining Automatic Response Sensor Event Policies ...................................................... 823
© 2015 by Pulse Secure, LLC. All rights reserved. xxi

Identifying and Managing Quarantined Users Manually ............................................. 824

Using Role-Based Policies to Monitor User Activity ......................................................... 825
Part 5 Appendix
IC Series 4500 and 6500 Overview ................................................................................... 829
Standard Hardware .............................................................................................................. 829
IC Series 6500 Field-Replaceable Units....................................................................... 829
Understanding Device Status LED Behavior ...................................................................... 830
Understanding Ethernet Port LED Behavior .......................................................................... 831
Replacing a Cooling Fan ............................................................................................................ 832
Replacing a Hard Drive .......................................................................................................... 833
Replacing a Power Supply ........................................................................................................... 834
FIPS Overview .......................................................................................................................... 835
Understanding Name and Password Restrictions ........................................................... 836
Initializing a Keystore ................................................................................................................. 837
Reinitializing the Keystore .......................................................................................................... 837
Joining a Cluster............................................................................................................................. 838
Changing the Security Officer Password ................................................................................. 839
Changing the Web User Password ............................................................................................... 839
Upgrading the Sun HSM Firmware ......................................................................................... 840
Importing and Exporting Keystore Binary Files ................................................................. 840
Understanding FIPS Device Status LED Behavior .............................................................. 841
Using Custom Expressions in Rule Configuration ............................................................... 843
Custom Expressions ....................................................................................................... 843
Custom Expression Elements ......................................................................................... 844
Wildcard Matching ............................................................................................................... 847
Using Multi-Valued Attributes........................................................................................... 847
Specifying Multivalued Attributes in a Bookmark Name ................................... 848
Distinguished Name Variables........................................................................................... 849
System Variables .......................................................................................................................... 849
Custom Variables and Macros ......................................................................................... 858
append ............................................................................................................................... 859
daysdiff ..................................................................................................................................... 860
regmatch ................................................................................................................................... 861
Specifying Fetch Attributes in a Realm ....................................................................... 861
Specifying the homeDirectory Attribute for LDAP .................................................... 862
Part 6 Index
Index ................................................................................................................................................... 865
xxii © 2015 by Pulse Secure, LLC. All rights reserved.

List of Figures
Figure 1: 802.1X Layer 2 with the Infranet Enforcer ................................................................ 6
Figure 2: Layer 3 with the Infranet Enforcer ............................................................................... 6
Figure 3: 802.1X Layer 2 without the Infranet Enforcer ......................................................... 6
Chapter 2 Initial Configuration .................................................................................................................9
Figure 4: Configuration and Installation Overview ........................................................... 38
Figure 5: Junos Pulse Role Mapping Rule ............................................................................... 68
Chapter 3 Deployments with ScreenOS and Junos OS Infranet Enforcers ......................... 77
Figure 6: Binding the Interfaces ...................................................................................................85
Figure 7: Binding a Physical Interface to a Security Zone ................................................100
Figure 8: Captive Portal Event Flow ......................................................................................... 109
Figure 9: Multiple vsys in Shared and Unshared Zones ..................................................... 117
Figure 10: Layer 3 Authentication with Overlapping IP Addresses ................................. 119
Figure 11: IF-MAP Authentication with Overlapping IP Addresses ................................. 120
Figure 12: Using an IP Address Pool in a NAT Environment ........................................... 131
Figure 13: Policy Interaction ........................................................................................................ 145
Figure 14: Using Auth Table Mapping Policies.................................................................. 153
Chapter 5 Layer 2 Network Access Control Policies .............................................................. 165
Figure 15: Policy Secure gateway as a RADIUS Server for an 802.1X Network Access
Device...........................................................................................................................................179
Figure 16: Using Location Groups to Group Network Access Devices .......................... 182
Figure 17: 802.1X Deployment with the EX4200 Switch .................................................. 201
Figure 18: Using a RADIUS Attributes Policy to Specify VLANs for Endpoints . . 208
Chapter 7 User Role Access with the SRX Series Firewall .......................................................215
Figure 19: Example Configuration .............................................................................................. 219

Chapter 8 General Access Management .................................................................................... 231
Figure 20: Access Management Sequence for Realm and Role Restrictions . . . 234
Figure 21: IC Series Authenticates User Against Realm and Primary Server 235
Figure 22: IC Series Authorizes User .................................................................................. 236
Figure 23: IC Series Maps User to One or More User Roles and Pushes
Policies ............................................................................................................................... 236
Figure 24: OAC and Infranet Enforcer Evaluate Policies Based on User Roles . . . 237
Figure 25: Infranet Enforcer Allows or Denies Access Based on Policy Match . . . 239
Figure 26: Requirements for Pulse Session Migration ....................................................257
© 2015 by Pulse Secure, LLC. All rights reserved. xxiii


Figure 27: Security Checks Performed by the IC Series to Create a Session
Role ............................................................................................................................................. 263
Figure 28: Local Authentication Server Configuration Page ................................................ 283
Figure 29: User Account Configuration Page ............................................................................ 286
Figure 30: User Accounts Table ............................................................................................................ 288
Figure 31: Update User Account Configuration Page ............................................................ 289
Figure 32: Admin Users Configuration Page.............................................................................. 290
Figure 33: New Active Directory/Windows NT Server Configuration Page ............. 293
Figure 34: New Active Directory Legacy Mode Configuration Page ................................. 298
Figure 35: User Accounts Table ...............................................................................................................303
Figure 36: Anonymous Server Configuration Page – Pulse Policy Secure . . . 310
Figure 37: Anonymous Server Configuration Page – Pulse Connect Secure.............. 310
Figure 38: User Access Log ......................................................................................................... 311
Figure 39: Certificate Server Configuration Page – Pulse Policy Secure ................... 313
Figure 40: Certificate Server Configuration Page – Pulse Connect Secure ............ 314
Figure 41: User Accounts Table ................................................................................................................316
Figure 42: LDAP Server Configuration Page – Pulse Policy Secure ............................ 318
Figure 43: LDAP Server Configuration Page – Pulse Connect Secure ...................... 319
Figure 45: New MAC Address Authentication Server Configuration Page ................... 331
Figure 47: Endpoint Profiler and Pulse Policy Secure Deployment ............................... 335
Figure 48: Beacon System Login Prompt......................................................................... 336
Figure 49: Beacon Setup Dialog Box ........................................................................................ 337
Figure 50: License Key Page During Validation ................................................................. 338
Figure 51: License Key Page After Validation ......................................................................... 338
Figure 52: Endpoint Profiles Management Page ................................................................... 339
Figure 53: Endpoint Profiles Listing ......................................................................................... 339
Figure 54: Endpoint Profiles VoIP Phone Listing ................................................................... 340
Figure 55: PolyComVOIP Profile Configuration Page ............................................................... 341
Figure 56: Selecting and Enabling LDAP for All Profiles .................................................... 342
Figure 57: Integrations Management Page................................................................................. 342
Figure 58: Update Beacon Modules Page ................................................................................. 343
Figure 59: Configure Beacon Modules Page .............................................................................. 343
Figure 60: Modules Stopped ..................................................................................................... 344
Figure 61: Modules Running ....................................................................................................... 344
Figure 62: Authentication Protocol Sets ................................................................................. 345
Figure 63: Authentication Protocol Sets............................................................................... 346
Figure 64: Selecting a New LDAP Authentication Server ............................................... 346
Figure 65: LDAP Authentication Server Settings .............................................................. 348
Figure 66: LDAP Authentication Server Settings with LDAPS Option and Port
636 Enabled ........................................................................................................................... 350
Figure 67: LDAP Server Catalog ............................................................................................... 350
Figure 68: LDAP Server Query Results ..................................................................................... 351
Figure 69: Selecting a New MAC Address Authentication Server .............................. 352
Figure 70: MAC Address Authentication Server Settings .................................................. 352
xxiv © 2015 by Pulse Secure, LLC. All rights reserved.

List of Figures
Figure 71: User Role General Configuration .......................................................................... 353

Figure 72: User Role Agent Configuration ............................................................................. 354
Figure 73: User Role Agentless Configuration ...................................................................... 354
Figure 74: MAC Address Authentication Realm Settings .................................................. 355
Figure 75: MAC Address Authentication Realm Role Mapping Settings..................... 356
Figure 76: MAC Address Authentication Realm Role Mapping Rule Summary . . 357
Figure 77: Location Group Settings.......................................................................................... 358
Figure 78: RADIUS Client Settings .......................................................................................... 358
Figure 79: RADIUS Return Attribute Policy Settings ............................................................ 359
Figure 80: NIS Server Configuration Page – Pulse Policy Secure ........................... 369
Figure 81: NIS Server Configuration Page – Pulse Connect Secure .......................... 370
Figure 82: User Accounts Table ..............................................................................................................371
Figure 83: RADIUS Server Configuration Page – Pulse Policy Secure .................. 384
Figure 84: RADIUS Server Configuration Page – Pulse Connect Secure ............ 385
Figure 85: User Accounts Table ............................................................................................................ 390
Figure 86: ACE Server Configuration Page – Pulse Policy Secure ......................... 393
Figure 87: ACE Server Configuration Page – Pulse Connect Secure ................... 394
Figure 88: User Accounts Table .......................................................................................................... 396
Figure 89: SiteMinder Server Configuration Page – Pulse Policy Secure ............. 405
Figure 90: SiteMinder Server Configuration Page – Pulse Connect Secure ...... 406
Figure 91: SiteMinder Advanced Settings – Pulse Policy Secure ................................... 411
Figure 92: SiteMinder Advanced Settings – Pulse Connect Secure .......................... 412
Figure 93: User Accounts Table...............................................................................................................415
Figure 94: SQL Server Configuration Page .................................................................................. 420
Figure 96: MAC Address Authentication Realm Configuration Page............................... 430
Figure 97: Adding an Attribute for LDAP in the Server Catalog ....................................... 437
Figure 98: Adding LDAP Groups .......................................................................................... 438
Figure 99: Adding Active Directory Groups ....................................................................... 440
Figure 100: IF-MAP Overview ............................................................................................. 445
Figure 101: Federation IF-MAP Topology ..................................................................................... 446
Figure 102: Session-Import and Session-Export Policies ............................................... 456
Figure 103: Replication of IF-MAP Servers............................................................................. 464
Figure 104: IF-MAP Server Clustering................................................................................... 466
Figure 105: IF-MAP Federation in a Heterogeneous Network with IDP ...................... 468
Figure 106: Realm Selection, Phase 1 .................................................................................. 477
Figure 107: Realm Selection, Phase 2 ................................................................................. 478
Figure 108: Realm Selection, Phase 3 .............................................................................. 479

Figure 109: SOH Integration with a Network Policy Server ................................................ 528
© 2015 by Pulse Secure, LLC. All rights reserved. xxv


Chapter 15 Network and Host Administration ................................................................................547
Figure 110: Internal Port Configuration Page ............................................................................. 550
Figure 111: Internal Port SAS Configuration Page ..................................................................... 551
Figure 112: External Port Configuration Page............................................................................. 554
Figure 113: External Port SAS Configuration Page .................................................................. 555
Figure 114: Management Port Configuration Page – Pulse Policy Secure . . . 559
Figure 115: Management Port Configuration Page – Pulse Connect Secure ........... 560
Figure 116: VLAN Port Configuration Page................................................................................ 564
Figure 117: VLAN Port SAS Configuration Page........................................................................ 565
Figure 118: Virtual Port Configuration Page ................................................................................567
Figure 119: Virtual Port SAS Configuration Page ......................................................................567
Figure 120: Certificate Details Page ............................................................................................... 569
Figure 121: Date and Time Configuration Page – Pulse Policy Secure .........................572
Figure 122: Date and Time Configuration Page – Pulse Connect Secure ..................573
Figure 123: Network Services Configuration Page ................................................................... 575
Figure 124: Network Services SAS Configuration Page .........................................................576
Figure 125: Routes Table ..............................................................................................................................578
Figure 126: Routes Table for SAS ....................................................................................................578
Figure 127: Hosts Table – Pulse Policy Secure .................................................................. 579
Figure 128: Hosts Table – Pulse Connect Secure .......................................................... 579
Figure 129: ARP Table .................................................................................................................................580
Figure 130: ARP Cache Table .................................................................................................................. 581
Figure 131: Neighbor Discovery Table .................................................................................................. 582
Figure 132: Neighbor Discovery Table for SAS .......................................................................... 582
Figure 133: SSL Options Configuration Page............................................................................. 584
Figure 134: Miscellaneous Security Options Configuration Page ....................................587
Figure 135: Serial Console Menu .........................................................................................589
Chapter 16 Certificate Security Administration ............................................................................. 593
Figure 136: Security Alert When the Device Certificate Is Not Issued by a Trusted
CA ................................................................................................................................................ 596
Figure 137: Device Certificates Management Page – Pulse Policy Secure – Pulse
Policy Secure...................................................................................................................... 597
Figure 138: Device Certificates Management Page – Pulse Connect Secure . . . 597
Figure 139: Import Certificate and Key Page ............................................................................. 598
Figure 140: New Certificate Signing Request ...................................................................... 600
Figure 141: Pending Certificate Signing Request ................................................................. 601
Figure 142: Intermediate CAs Management Page .................................................................. 602
Figure 143: Renew Certificate Page ...............................................................................................604
Figure 144: Certificate Details Page ............................................................................................ 606
Figure 145: Trusted Client CA Management Page – Pulse Policy Secure.................. 612
Figure 146: Trusted Client CA Management Page – Pulse Connect Secure ............ 612
Figure 147: Import Trusted Client CA Page ................................................................................. 612
Figure 148: Trusted Client CA Details Page ............................................................................... 613
Figure 149: Auto-Import Options Page ....................................................................................... 614
Figure 150: Trusted Client CA Details Page ............................................................................... 616
Figure 151: CRL Checking Options .......................................................................................618
Figure 152: OCSP Options Page ...................................................................................................... 619
xxvi © 2015 by Pulse Secure, LLC. All rights reserved.

List of Figures
Figure 153: Responder Signer Certificate Page........................................................................ 620

Figure 154: Proxy Settings Page ....................................................................................................... 622
Figure 155: Trusted Server CA Management Page – Pulse Policy Secure . . . 624
Figure 156: Trusted Server CA Management Page – Pulse Connect Secure .............. 624
Figure 157: Import Trusted Server CA Page................................................................................ 624
Figure 158: Trusted Server CA Details Page .............................................................................. 626
Figure 159: Configuring the External Port for IPv4 ......................................................... 629
Figure 160: Creating the Virtual Port on the External Port ............................................... 630
Figure 161: Creating an ECC P-256 Certificate Signing Request .................................... 631
Figure 162: CSR Successfully Created ..................................................................................... 631
Figure 163: Pending CSR ............................................................................................................. 632
Figure 164: Associating the ECC P-256 With The External Virtual Port
p_ecdsa256 ....................................................................................................................... 633
Figure 165: Setting Custom SSL Cipher Selections ........................................................ 634
Figure 166: Confirming Custom Ciphers .......................................................................... 635
Figure 167: Enabling FIPS Level 1 Support.......................................................................... 640
Figure 168: Example of Allowed Encryption Strengths................................................... 641
Figure 169: Events Log Entries for FIPS Level 1................................................................. 642
Figure 170: Admin Access Logs for FIPS Level 1 Encryption Strength Changes . . 642
Figure 171: Connecting to a Port Using an ECC Curve P-256 Certificate ...................... 642
Figure 172: Viewing the Connection Certificate Information ........................................ 643
Figure 173: Certificate Public Key.................................................................................................... 643
Figure 174: Viewing the TCP Dump Output ....................................................................... 644
Figure 175: Issued to Certificate on the Device Certificates Pages ................................ 644
Figure 176: Archiving Configuration Page – Pulse Policy Secure .............................. 660
Figure 177: Archiving Configuration Page – Pulse Connect Secure .............................. 661
Figure 178: Local Backups Management Page – Pulse Policy Secure ...................... 664
Figure 179: Local Backups Management Page – Pulse Connect Secure ................. 665
Figure 180: Export Binary System Configuration File Configuration Page – Pulse
Policy Secure .................................................................................................................... 667
Figure 181: Export Binary System Configuration File Configuration Page – Pulse
Connect Secure............................................................................................................... 668
Figure 182: Import Binary System Configuration File Configuration Page ................... 669
Figure 183: Binary Export User Configuration File Configuration Page – Pulse Policy
Secure ................................................................................................................................. 672
Figure 184: Binary Export User Configuration File Configuration Page – Pulse
Connect Secure .............................................................................................................. 672
Figure 185: Import User Configuration Binary File Configuration Page ......................... 673
Figure 186: Export XML File Configuration Page – Pulse Policy Secure ................... 676
Figure 187: Export XML File Configuration Page – Pulse Connect Secure ........... 677
Figure 188: Import XML File Configuration Page...................................................................... 679
Figure 189: Object Referential Integrity Constraints ....................................................... 685
Figure 190: Push Configuration Target List and Source Device Settings Page – Pulse
Policy Secure .................................................................................................................... 692
Figure 191: Push Configuration Target List and Source Device Settings Page – Pulse
Connect Secure............................................................................................................... 692
© 2015 by Pulse Secure, LLC. All rights reserved. xxvii

Figure 192: Push Configuration Targets Configuration Page .............................................. 693

Figure 193: Push Configuration Selected Settings Page .................................................... 694
Figure 194: Push Configuration Results Page ........................................................................... 697
Figure 195: System Maintenance Options Configuration Page ......................................... 701
Figure 196: Software Upgrade Page .............................................................................................. 705
Figure 197: Software Upgrade Status Page.................................................................................. 706
Figure 198: System Maintenance Platform Page .................................................................. 708
Figure 199: System Maintenance Client Installers Page – Access Control
Service ................................................................................................................................ 709
Figure 200: System Maintenance Client Installers Page – Pulse Connect
Secure ................................................................................................................................. 710
Figure 201: System Maintenance Platform Page ...................................................................... 712
Figure 202: System Maintenance Platform Page ....................................................................... 713
Figure 203: Log Events Settings Configuration Page.............................................................. 717
Figure 204: SNMP Configuration Page – Pulse Policy Secure ............................... 720
Figure 205: SNMP Configuration Page – Pulse Connect Secure ................................ 721
Figure 206: Syslog Server Configuration Page – Pulse Policy Secure ................... 729
Figure 207: Syslog Server Configuration Page – Pulse Connect Secure ............ 730
Figure 208: Client Logs Configuration Page ............................................................................... 731
Figure 209: System Status Page – Pulse Policy Secure ................................................ 732
Figure 210: System Status Page – Pulse Connect Secure ........................................... 733
Figure 211: System Status Settings Configuration Page....................................................... 734
Figure 212: System Maintenance Page – Pulse Policy Secure ..................................... 736
Figure 213: System Maintenance Page – Pulse Connect Secure .............................. 736
Figure 214: System Active Users Page – Pulse Policy Secure ..................................... 738
Figure 215: System Active Users Page – Pulse Connect Secure................................. 738
Figure 216: Events Logs Page – Pulse Policy Secure ..................................................... 740
Figure 217: Events Logs Page – Pulse Connect Secure.................................................... 741
Figure 218: Log Filters Page .............................................................................................................. 744
Figure 219: Log Filters Page – Pulse Connect Secure ................................................... 745
Figure 220: New Filter Page – Pulse Policy Secure ........................................................ 746
Figure 221: Using IP Address Filters ........................................................................................ 748
Figure 222: User Statistics Page – Pulse Policy Secure ................................................. 749
Figure 223: User Statistics Page – Pulse Connect Secure ........................................... 749
Figure 224: Policy Tracing Configuration Page – Pulse Policy Secure ....................... 753
Figure 225: Policy Tracing Page During Recording .............................................................. 755
Figure 226: Policy Tracing Results Page ...................................................................................... 756
Figure 227: Debug Logging Configuration Page – Pulse Policy Secure .................... 758
Figure 228: Debug Logging Configuration Page – Pulse Connect Secure ........... 758
Figure 229: RADIUS Diagnostic Logging Configuration Page............................................. 760
Figure 230: TCP Dump Configuration Page – Pulse Policy Secure ........................... 761
Figure 231: TCP Dump Configuration Page – Pulse Connect Secure .................... 761
Figure 232: Network Troubleshooting Commands Configuration Page – Pulse
Policy Secure.................................................................................................................... 763
xxviii © 2015 by Pulse Secure, LLC. All rights reserved.

List of Figures

Connect Secure .............................................................................................................. 764
Figure 234: Successful TCP Port Probe ................................................................................. 767
Figure 235: Unsuccessful UDP Port Probe.......................................................................... 768
Policy Secure .................................................................................................................. 769
Connect Secure .............................................................................................................. 769
Figure 238: Kerberos Debugging Utility Configuration Page.............................................. 770
Figure 239: Remote Debugging Configuration Page – Pulse Policy Secure . . . 771
Figure 240: Remote Debugging Configuration Page – Pulse Connect Secure. . 772
Figure 241: Active/Passive Clustering ..................................................................................... 781
Figure 242: Active/Active Clustering....................................................................................... 783
Chapter 25 Deployments with IDP ..................................................................................................813
Figure 243: IC Series and Standalone IDP Topology ............................................................... 815
Figure 244: IC Series and ISG-IDP Topology............................................................................... 816
Figure 245: IDP in a Layer 2 Deployment ........................................................................... 816
© 2015 by Pulse Secure, LLC. All rights reserved. xxix

xxx © 2015 by Pulse Secure, LLC. All rights reserved.

List of Tables
About This Guide .........................................................................................................xxxv
Table 1: Notice Icons ............................................................................................................ xxxvi
Table 2: Text Conventions .................................................................................................. xxxvi

Chapter 2 Initial Configuration ................................................................................................................. 9
Table 3: Summary of Actions Required to Configure the Pulse Policy Secure Solution
.................................................................................................................................................11
Table 4: Configuration Topics .............................................................................................................. 12
Table 5: Scenarios and Methods of Deployment ............................................................. 19
Table 6: Initial OAC Configuration Settings............................................................................... 23
Table 7: Configurable Parameters for Pulse Connection Sets............................................. 40
Table 8: Pulse Components ..........................................................................................................52
Table 9: Pulse Launcher Arguments ......................................................................................61
Table 10: Pulse Launcher Return Codes .................................................................................62
Chapter 3 Deployments with ScreenOS and Junos OS Infranet Enforcers ........................... 77
Table 11: Junos Enforcer Features ................................................................................................ 82
Table 12: ScreenOS Options......................................................................................................92
Table 13: Configuration Topics........................................................................................................ 126
Table 14: Syntax for IP Address Pools ....................................................................................... 133
Chapter 4 Deployments with EX Series Ethernet Switches...................................................... 157
Table 15: EX Series Switches and Filter Term Limitations .............................................. 161
Table 16: Authentication Protocols ......................................................................................... 170
Table 17: Authentication Protocol Set Configuration Guidelines .................................. 172
Table 18: RADIUS Event Time Limits ................................................................................... 176
Table 19: Valid Data Types ................................................................................................................. 188
Chapter 7 User Role Access with the SRX Series Firewall ......................................................... 215
Table 20: Understanding Log Messages Related to Active Directory and
SPNEGO .............................................................................................................................. 225

Chapter 8 General Access Management .....................................................................................231
Table 21: DNS Hostname Special Characters ........................................................................ 250
Table 22: Port Possible Values......................................................................................................... 250
Table 23: Before you Configure a Host Enforcer Policy................................................... 252
© 2015 by Pulse Secure, LLC. All rights reserved. xxxi

Table 24: Examples of Specifying Resources in a Host Enforcer Policy ..................... 254
Table 25: Supported AAA Servers ........................................................................................... 280
Table 26: Local Authentication Server Settings................................................................. 284
Table 27: User Account Configuration Settings ................................................................... 286
Table 28: Active Directory Mode Settings ............................................................................... 294
Table 29: Active Directory Legacy Mode Settings.............................................................. 299
Table 30: Anonymous Server Settings ...................................................................................... 310
Table 31: Certificate Server Settings ......................................................................................... 314
Table 32: LDAP Server Settings ................................................................................................ 320
Table 33: Supported Password Management Functions ............................................... 325
Table 34: AD/NT Password Management Matrix ............................................................. 327
Table 35: MAC Address Authentication Server Settings .................................................... 331
Table 36: Key LDAP Authentication Server Settings ......................................................... 347
Table 37: Key MAC Address Authentication Realm Settings ........................................... 355
Table 38: Key MAC Address Authentication Realm Role Mapping Settings........... 356
Table 39: NIS Server Settings ................................................................................................... 370
Table 40: RADIUS Attributes ....................................................................................................... 374
Table 41: Attributes Common to Start and Stop Messages ............................................. 381
Table 42: Start Attributes .............................................................................................................. 382
Table 43: Stop Attributes .............................................................................................................. 382
Table 44: RADIUS Server Settings .......................................................................................... 386
Table 45: Sign-in Methods ..................................................................................................... 391
Table 46: ACE Server Settings ................................................................................................... 394
Table 47: SiteMinder Server Settings .................................................................................... 407
Table 48: SiteMinder Advanced Configuration Options ................................................. 413
Table 49: SQL Statement Format Specifiers ...................................................................... 418
Table 50: SQL Statement Parameter Names and Types .................................................... 418
Table 51: Password Hash Format .......................................................................................... 419
Table 52: SQL Server Settings ................................................................................................... 420
Table 53: Oracle Error Codes .................................................................................................... 424
Table 54: MAC Address Authentication Realm Configuration Guidelines ................. 431
Table 55: RADIUS Sub-Protocols and Compatible Authentication Servers............ 475

Table 56: Wildcard Characters for Specifying a File Name or Process Name............. 511
Table 57: Environment Variables for Specifying a Directory Path on Windows . . . 511
Table 58: Environment Variables for Specifying a Directory Path on Macintosh,
Linux and Solaris ............................................................................................................ 511

Table 59: Internal Port Configuration Guidelines .............................................................. 551
xxxii © 2015 by Pulse Secure, LLC. All rights reserved.

List of Tables
Table 60: External Port Configuration Guidelines............................................................... 555

Table 61: Management Port Configuration Guidelines .................................................... 560
Table 62: VLAN Port Configuration Guidelines.................................................................. 565
Table 63: Virtual Port Configuration Guidelines ............................................................... 567
Table 64: Date and Time Configuration Guidelines ........................................................ 573
Table 65: Network Services Configuration Guidelines .................................................... 576
Table 66: Routes Table Controls ................................................................................................ 578
Table 67: Hosts Table Controls .................................................................................................. 579
Table 68: ARP Table Controls................................................................................................... 581
Table 69: Neighbor Discovery Table Controls ....................................................................... 582
Table 70: SSL Options Configuration Guidelines ............................................................. 586
Table 71: Miscellaneous Security Options Configuration Guidelines ......................... 587
Table 72: Serial Console Menu Options ............................................................................. 590
Chapter 16 Certificate Security Administration .............................................................................. 593
Table 73: Auto-Import Options Settings................................................................................. 614
Table 74: Trusted Client CA Settings ....................................................................................... 617
Table 75: OCSP Options Settings.............................................................................................. 619
Table 76: Responder Signer Certificate Settings ................................................................. 620
Table 77: Proxy Settings ............................................................................................................... 622
Table 78: Supported Cipher Suites With FIPS Level 1 Support Off, Hardware
Acceleration Enabled and RSA Server Certificates In Use ................................... 648
Acceleration Enabled and ECC Server Certificates In Use .................................. 649
Acceleration Enabled and RSA Server Certificates In Use ................................... 650
Acceleration Disabled and ECC Server Certificates In Use ................................... 651
Table 82: Supported Cipher Suites With FIPS Level 1 Support On and ECC Server
Certificates In Use ........................................................................................................... 653
Table 83: Supported Cipher Suites With FIPS Level 1 Support On and RSA Server
Certificates In Use ........................................................................................................... 654
Table 84: Utilities for Configuration File Administration ................................................... 657
Table 85: Archiving Configuration Guidelines................................................................... 662
Table 86: Local Backups Management Guidelines.......................................................... 665
Table 87: Export Binary System Configuration File Configuration and Action
Guidelines .......................................................................................................................... 668
Table 88: Import Binary System Configuration File Configuration and Action
Guidelines .......................................................................................................................... 669
Table 89: Binary Export User Configuration File Configuration and Action
Guidelines .......................................................................................................................... 673
Table 90: Import Binary User Configuration File Configuration and Action
Guidelines .......................................................................................................................... 673
Table 91: XML Import/Export Guidelines and Limitations ............................................ 675
Table 92: Export XML File Configuration and Action Guidelines .................................. 678
Table 93: Import XML File Configuration and Action Guidelines.................................. 679
© 2015 by Pulse Secure, LLC. All rights reserved. xxxiii

Table 94: Structured XML Files: Basic Information and Guidelines............................681

Table 95: Legal Operator Attribute Relationships ........................................................... 687
Table 96: Push Configuration Guidelines and Limitations............................................. 691
Table 97: Push Configuration Target Source Device Configuration Options ............. 692
Table 98: Push Configuration Targets Configuration Guidelines .................................. 693
Table 99: Push Configuration Selected Settings and Action Guidelines................... 694
Table 100: System Maintenance Options Configuration Guidelines ............................ 701
Table 101: Event Log Severity Levels......................................................................................... 715
Table 102: Log Events Settings .................................................................................................. 717
Table 103: SNMP Configuration Settings ................................................................................ 721
Table 104: MIB Objects ........................................................................................................... 724
Table 105: Syslog Server Configuration Guidelines .......................................................... 730
Table 106: Hardware Status Information ............................................................................ 736
Table 107: RAID and Hard Drive Status for Policy Secure gateways............................. 737
Table 108: RAID and Hard Drive Status for the MAG-SM360 ..................................... 737
Table 109: Active Users Page .......................................................................................................... 739
Table 110: Log Management Features.................................................................................... 741
Table 111: Filter Settings.............................................................................................................. 746
Table 112: Policy Trace Configuration Guidelines............................................................. 753
Table 113: Post-Trace Options .............................................................................................. 756
Table 114: Debug Log Configuration Guidelines............................................................... 758
Table 115: RADIUS Debug Log Configuration Guidelines.............................................. 760
Table 116: Debug Log Configuration Guidelines.............................................................. 761
Table 117: Network Troubleshooting Commands Configuration Guidelines ............. 765
Table 118: Kerberos Debugging Utility Configuration Guidelines............................... 770
Table 119: Remote Debugging Configuration and Action Guidelines ........................ 772
Table 120: License Distribution Examples............................................................................. 775
Table 121: Cluster Status Page Information ...................................................................... 791
Table 122: IP Address and Serial Number Combinations .............................................. 794
Table 123: Cluster Status ............................................................................................................. 795
Part 5 Appendix
Table 124: Device Status LEDs .............................................................................................. 831
Table 125: 4-Port Copper Gigabit Ethernet LEDs (available on IC4500 and
IC6500)............................................................................................................................... 831
Table 126: FIPS Device Status LEDs ................................................................................... 841
Table 127: Custom Expression Elements ............................................................................ 844
Table 128: System Variables and Examples ....................................................................... 849
xxxiv © 2015 by Pulse Secure, LLC. All rights reserved.

About This Guide
 Objectives on page xxxv

 Audience on page xxxv
 Documentation Conventions on page xxxv
 Documentation on page xxxvii
 Obtaining Documentation on page xxxvii
 Documentation Feedback on page xxxvii
 Requesting Technical Support on page xxxvii
Objectives
This guide describes basic configuration procedures for Pulse Policy Secure, formerly
known as Unified Access Control or Access Control Service. This document is part of the
Pulse Secure documentation set. Pulse Policy Secure is supported on the IC Series and
MAG Series platforms.
Audience
This guide is designed for network administrators who are configuring and maintaining
the Policy Secure. To use this guide, you need a broad understanding of networks in
general and the Internet in particular, networking principles, and network configuration.
Any detailed discussion of these concepts is beyond the scope of this guide.
Documentation Conventions
Table 1 on page xxxvi defines the notice icons used in this guide. Table 2 on page xxxvi defines
text conventions used throughout this documentation.
© 2015 by Pulse Secure, LLC. All rights reserved. xxxv

Table 1: Notice Icons

Icon Meaning Description
Informational note Indicates important features or instructions.
Caution Indicates a situation that might result in loss of data or hardware damage.
Warning Alerts you to the risk of personal injury or death.
Laser warning Alerts you to the risk of personal injury from a laser.
Table 2: Text Conventions
Convention Description Examples

Bold text like this  Represents keywords, scripts, and tools in  Specify the keyword exp-msg.
text.  Run the install.sh script.
 Represents a GUI element that the user  Use the pkgadd tool.
selects, clicks, checks, or clears.
 To cancel the configuration, click Cancel.
Bold text like this Represents text that the user must type. user@host# set cache-entry-age
cache-entry-age
Fixed-width text like this Represents information as displayed on your nic-locators {

terminal’s screen, such as CLI commands in login {
output displays. resolution {
resolver-name /realms/
login/A1;
key-type LoginName;
value-type SaeId;
}
Regular sans serif typeface  Represents configuration statements.  system ldap server{
 Indicates SRC CLI commands and options stand-alone;
in text.  Use the request sae modify device failover
 Represents examples in procedures. command with the force option
 Represents URLs.  user@host# . . .
 http://www.juniper.net/techpubs/software/
management/sdx/api-index.html
Italic sans serif typeface Represents variables in SRC CLI commands. user@host# set local-address
local-address
Angle brackets In text descriptions, indicate optional Another runtime variable is <gfwif>.
keywords or variables.
Key name Indicates the name of a key on the keyboard. Press Enter.
xxxvi © 2015 by Pulse Secure, LLC. All rights reserved.

About This Guide
Table 2: Text Conventions (continued)

Key names linked with a plus sign Indicates that you must press two or more Press Ctrl + b.
(+) keys simultaneously.
Italic typeface  Emphasizes words.  There are two levels of access: user and
 Identifies book names. privileged.
 Identifies distinguished names.  SRC-PE Getting Started Guide.
 Identifies files, directories, and paths in  o=Users, o=UMC

text but not in command examples.  The /etc/default.properties file.
Backslash At the end of a line, indicates that the text Plugin.radiusAcct-1.class=\

wraps to the next line. net.juniper.smgt.sae.plugin\
RadiusTrackingPluginEvent
Words separated by the | symbol Represent a choice to select one keyword or diagnostic | line
variable to the left or right of this symbol.
(The keyword or variable may be either
optional or required.)
Documentation
For a list of related Pulse Secure documentation, see

http://www.pulsesecure.net/support. If the information in the latest Pulse Secure
Release Notes differs from the information in the documentation, follow the Pulse
Secure Release Notes.
Obtaining Documentation
To obtain the most current version of all Pulse Policy Secure technical documentation,
see the products documentation page at http://www.juniper.net/techpubs.
Documentation Feedback
We encourage you to provide feedback, comments, and suggestions so that we can improve
the documentation. You can provide feedback by using one of the following methods:
 Document name
 Page number
 Software release version
Requesting Technical Support
Technical product support is available through the Pulse Secure Global Support
Center (PSGSC). If you have a support contract, then file a ticket with PSGSC.
© 2015 by Pulse Secure, LLC. All rights reserved. xxxvii

 Product warranties—For product warranty information, visit

http://www.pulsesecure.net/support.
Self-Help Online Tools and Resources
For quick and easy problem resolution, Pulse Secure, LLC has designed an online self-
service portal called the Customer Support Center (CSC) that provides you with the
following features:
 Find CSC offerings: http://www.pulsesecure.net/support
 Search for known bugs: http://www.pulsesecure.net/support
 Find product documentation: http://www.juniper.net/techpubs/
 Find solutions and answer questions using our Knowledge Base:

http://www.pulsesecure.net/support
 Download the latest versions of software and review release notes:

 Search technical bulletins for relevant hardware and software notifications:

 Join and participate in the Pulse Secure, LLC Community Forum:

 Open a case online in the CSC Case Management tool: http://www.pulsesecure.net/support
To verify service entitlement by product serial number, use our Serial Number Entitlement
(SNE) Tool: http://www.pulsesecure.net/support
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 PSGSC at http://www.pulsesecure.net/support.
 Call 1-888-314-5822 (toll-free in the USA, Canada, and Mexico).

For international or direct-dial options in countries without toll-free numbers, see
http://www.pulsesecure.net/support.
xxxviii © 2015 by Pulse Secure, LLC. All rights reserved.

PART 1
Getting Started
 Pulse Policy Secure on page 3
 Initial Configuration on page 9
 Deployments with ScreenOS and Junos OS Infranet Enforcers on page 77
 Deployments with EX Series Ethernet Switches on page 157
 Layer 2 Network Access Control Policies on page 165
 Deployments with Network and Security Manager on page 209
 User Role Access with the SRX Series Firewall on page 215
© 2015 by Pulse Secure, LLC. All rights reserved. 1

2 © 2015 by Pulse Secure, LLC. All rights reserved.

CHAPTER 1
Pulse Policy Secure
 Understanding the Pulse Policy Secure Solution on page 3
Understanding the Pulse Policy Secure Solution
This topic provides an overview of the Pulse Policy Secure solution. It includes the
following information:
 Pulse Policy Secure Solution Overview on page 3

 Pulse Policy Secure Components on page 4
 The Pulse Policy Secure Solution in the Network on page 5
 How the Pulse Policy Secure Determines User Access and Protects
Resources on page 7
Pulse Policy Secure Solution Overview

The Pulse Policy Secure solution provides a mechanism for authenticating users and
assessing the health of their host machines to control network access.
The Pulse Policy Secure solution coordinates network security compliance and provides
the control required to support network applications, manage network use, and reduce
threats from unauthorized users and compromised host machines attempting
to access the network.
Youconfigure rules in Host Checker policies to specify the minimum criteria for the security
compliance of host machines that are allowed to enter the network.
The policies that you create control access for users, the client or agent that users access
the network with, and the host machine or endpoint on which the clients run.
Policy enforcement is through Juniper Networks firewalls (the ScreenOS Enforcer or the
Junos Enforcer, collectively named Infranet Enforcers), 802.1X enabled switches, wireless
access points, and/or packet filters configured on the endpoints. Additionally, you can
deploy Juniper Networks Intrusion Detection and Prevention (IDP) as an enforcement
point.
The Pulse Policy Secure solution can also provide access control for unmanageable
devices like printers or IP phones using MAC address authentication.

Pulse Policy Secure Components

The Pulse Policy Secure solution consists of these Pulse Secure components:
 Pulse Policy Secure—A central policy management server that validates the user’s
identity, determines the endpoint’s security compliance, and manages network policies.
The Pulse Policy Secure pushes the policies to the endpoint and optionally, to the
Infranet Enforcer.
 UAC agent—The Pulse Policy Secure solution uses a UAC agent to connect with
endpoints. The UAC agent is client software that runs on the endpoint and determines
the endpoint’s compliance to the enterprise security policies you specify. The UAC
agent communicates with the Pulse Policy Secure to verify the endpoint’s continued
compliance with the policies using the built-in Host Checker.
NOTE: You can also deploy the Pulse Policy Secure solution to endpoints
with a subset of features using a non-UAC agent such as a non-Pulse
Secure 802.1X supplicant. This overview focuses on using a UAC agent.
You can use the following UAC agents:
 Odyssey Access Client (OAC)—You can configure the Policy Secure gateway to
automatically install OAC on supported Windows endpoints. You can manually
install OAC on Macintosh endpoints. OAC includes built-in components (including
Host Checker) to provide maximum protection and functionality.
 Pulse Secure Client—UAC provides a single, dynamic, integrated multiservice client

for Windows. Pulse is an intelligent, location-aware network access and
acceleration client. Pulse delivers identity-enabled network security and access
control, providing comprehensive endpoint security. Host Checker is integrated
into Pulse.
In addition to using the client with a Pulse Policy Secure deployment, Pulse
supports the Pulse Connect Secure platform, WAN acceleration (WX), and Juniper
Networks SRX Series devices as a dynamic virtual private network (VPN) client.
 Java agent—For Linux endpoints, you can install a lightweight Java agent. With the
Java agent, Host Checker is downloaded automatically to assess and monitor
endpoint security.
 Host Checker (agentless)—You can configure the Policy Secure gateway to

automatically install Host Checker for agentless access deployments on
Windows, Macintosh, Linux or Solaris endpoint platforms. You use agentless
access for endpoints onto which you do not want to download OAC, Pulse, or the
Java agent.
NOTE: In this guide and other Pulse Policy Secure documentation, the
names OAC, Pulse, Java agent, and agentless Host Checker access
refer to the specific type of UAC agent.

Chapter 1: Pulse Policy Secure
 Enforcement points—Devices that dynamically enforce access policies for protected

resources. You can control user access with Layer 2 or Layer 3 enforcement. The
following types of devices can be used as UAC enforcement points:
 Infranet Enforcer—A Juniper Networks security device is an optional component that

operates with the Policy Secure gateway to enforce access policies. You can use the
ScreenOS Enforcer in Layer 2 and Layer 3 deployments. An SRX series services
gateway can be used in Layer 3 deployments. The Infranet Enforcer is deployed in
front of servers and resources that you want to protect, and serves as a firewall to
enforce the security policies that you configure to control access to protected
resources.
 802.1X devices—You can use IEEE 802.1X-enabled switches or access points with
Pulse Policy Secure solution components to control access to the network using
Layer 2 authentication. The 802.1X protocol provides port-based authenticated
access to a LAN. This standard applies to both wireless and wired networks. In a
wireless network, the 802.1X authentication occurs after the client has associated
to an access point using an 802.11 association method. Wired networks use the
802.1X standard without 802.11 association.
You can use 802.1X enabled switches or access points with or without the Infranet
Enforcer as part of the solution. If you do not deploy the Infranet Enforcer, the 802.1X
enabled switch or access point functions as the enforcement point. You can create
different security zones by configuring VLANs on the network and assigning different
roles to the appropriate VLAN.
The Pulse Policy Secure Solution in the Network

The Pulse Policy Secure solution is extremely flexible and offers numerous options for
integration into your existing network.
Figure 1 on page 6 illustrates a deployment using 802.1X with a switch or access point
for Layer 2 connectivity.Figure 2 on page 6 illustrates a network deployment using Layer
3. These examples take advantage of the Infranet Enforcer to protect network resources.
You can also deploy the Pulse Policy Secure without the Infranet Enforcer by using
VLANs to segregate unauthenticated or unauthorized traffic.Figure 3 on page 6 illustrates
this kind of deployment.

Figure 1: 802.1X Layer 2 with the Infranet Enforcer
Figure 2: Layer 3 with the Infranet Enforcer
Figure 3: 802.1X Layer 2 without the Infranet Enforcer

Chapter 1: Pulse Policy Secure
How the Pulse Policy Secure Determines User Access and Protects Resources
You create policies on the Policy Secure gateway’s admin interface to control access to
resources and services. Access is based on successful authentication, the user’s
assigned role, and the security compliance of the endpoint device. For example, you can
provide full access to protected resources for an employee’s role, and limited access for
a contractor role.
You can create Host Checker policies that require endpoints to meet security requirements.
For example, you can require an endpoint to use a minimum version of an antivirus
application with up-to-date antivirus definitions. If the endpoint does not meet the security
requirements, you can configure the Host Checker policy to display instructions that tell
the user how to bring the endpoint into compliance.
After you populate the system with users, policies, and authentication services, you
determine how users gain access to network resources.
The Pulse Policy Secure and Infranet Enforcer can work together to provide granular
endpoint security and firewall services to control access to protected resources for
qualified users. If you are using the Infranet Enforcer, the Pulse Policy Secure pushes
policies to the Infranet Enforcer when the two devices connect.
Based on user identity and endpoint status, the system assigns the user a set of roles
that specify which resources the user can access. The system pushes the set of roles
associated with each endpoint’s source IP address (called “auth table” entries) to the
Infranet Enforcer. The Infranet Enforcer allows traffic between the endpoint and the
protected resources based on resource access policies that you create.
For 802.1X Layer 2 deployments in which you are not using the Infranet Enforcer, you can
set up network VLANs and direct endpoints that do not meet security requirements to a
quarantine VLAN.
The user accesses a switch or access point to be authenticated through the Pulse Policy
Secure. The user's identity and the endpoint health assessment are used to determine
which VLAN or other RADIUS attribute to use. The quarantine VLAN can limit access to
remediation servers that provide users with instructions and the software they need for
bringing their endpoint into compliance with security policies.
Related Understanding Pulse Policy Secure Deployment Options on page 10

Documentation



CHAPTER 2
Initial Configuration
 Understanding Pulse Policy Secure Deployment Options on page 10

 Pulse Policy Secure Solution Configuration Overview on page 11
 Before You Configure the Pulse Policy Secure on page 12
 Using Task Guidance on page 12
 Configuring the Pulse Policy Secure Solution on page 13
 Deploying the Pulse Policy Secure Solution to Users on page 16
 Pulse Policy Secure Deployment Summary on page 19
 Understanding the Initial Pulse Policy Secure Deployment User
Experience on page 19
 Specifying the Client that Endpoints Use for Access on page 21
 Creating an Initial Configuration of OAC for Windows Endpoints on page 22
 Understanding OAC Configuration Settings for Windows Endpoints on page 23
 Defining the Initial Configuration for OAC for Windows on page 24
 Using the Preconfigured Installer for OAC on Windows Endpoints on page 29
 Preconfiguring OAC Using the Custom Installer on page 29
 Validating the IC Series Certificate on page 30
 Using OAC Licenses with the IC Series on page 31
 Manually Installing OAC on page 31
 Manually Configuring OAC for 802.1X (Windows or Macintosh) on page 32
 Provisioning Detailed Configuration Profiles for Macintosh OAC Endpoints on page 34
 Understanding Deployments with Pulse Secure Clients on page 34
 Configuring the Pulse Client for a Role on page 36
 Pulse Client Configuration Overview on page 37
 Understanding Client Connection Set Options on page 40
 Creating a Client Connection Set on page 46
 Configuring Location Awareness Rules for Pulse Secure Client on page 49
 Understanding Pulse Component Set Options on page 52
 Creating a Client Component Set on page 53

 Installing the Pulse Secure Client on Windows Endpoints Using a

Preconfiguration File on page 54
 Installing the Pulse Secure Client on OS X Endpoints Using a
Preconfiguration File on page 59
 Pulse Secure Command-line Launcher on page 60
 Using jamCommand to Import Pulse Secure Connections on page 63
 Configuring Machine-Only Machine Authentication for a Pulse
Secure Connection on page 64
 Configuring User-After-Desktop Machine Authentication for a Pulse
Secure Connection on page 65
 Machine and User Authentication Through a Pulse Connection for Pulse Policy Secure
on page 66
 Preferred Realm and Role for Pulse Secure Machine Authentication on page 67
 Remote Desktop Protocol Compatibility with Pulse Secure 802.1X
Machine Authentication Connection on page 69
 Credential Provider Authentication for Pulse Policy Secure
Overview on page 69
 Machine Authentication for Pulse Policy Secure Overview on page 71
 Additional Methods for Accessing Protected Resources Behind the IC Series
Device on page 72
 Configuring Agentless Access to Protected Resources on page 73
 Using the Java Agent on page 74
 Configuring the Java Agent on page 74
Understanding Pulse Policy Secure Deployment Options
You can deploy the Pulse Policy Secure in several ways to provide access control for
network assets. You can use Layer 2 or Layer 3 authentication with the Infranet Enforcer,
or you can use Layer 2 802.1X without the Infranet Enforcer to direct users to different
VLANs. Both the ScreenOS Enforcer and the SRX Series Services Gateway (Junos
Enforcer) are supported as the policy decision point. You can use the built-in UAC agents,
OAC for Windows or Macintosh endpoints, the Java agent for Linux, or agentless access.
Alternately, you can deploy the solution with the Windows or Macintosh native 802.1X
supplicant (a non-UAC agent). With UAC 4.0 you can use the Juniper Networks Pulse
client.
NOTE: Deployment Scenario describes the basic steps for configuring the
Pulse Policy Secure and the Infranet Enforcer in an example of a server
front-end deployment scenario. You can adapt the information in that guide
to your specific deployment.
Related Pulse Policy Secure Solution Configuration Overview on page 11

Documentation


Chapter 2: Initial Configuration
 Before You Configure the Pulse Policy Secure on page 12
 Understanding the Pulse Policy Secure Solution on page 3
Pulse Policy Secure Solution Configuration Overview
Table 3 on page 11 outlines the general steps for installing and configuring the Pulse
Policy Secure solution. Variables to be considered depend on the specific network
topology and the nature of your access control needs. Use this table as a general guide,
and read the product documentation for complete information of all of the network
access control options available with the Pulse Policy Secure solution.
Your access control needs are complex, and the Pulse Policy Secure solution is versatile.
Please take the time to thoroughly understand the required actions.
Table 3: Summary of Actions Required to Configure the Pulse Policy

Secure Solution
Action Required or Optional
Install the hardware Required
Upgrade and license the Pulse Policy Secure software Required
Install the Infranet Enforcer Or use 802.1X
Install Certificates Only with Infranet Enforcer
Connect the Policy Secure gateway and the Infranet Only with Infranet Enforcer
Enforcer
Configure authentication server(s) (or use the local server) Required
Configure Roles and Realms Required
Configure OAC or Pulse options Or third-party client
Configure Infranet Enforcer Resource Access policies Only with Infranet Enforcer
Configure IPsec and/or Source IP enforcement Only with Infranet Enforcer
Configure Sign-in policies, add realms and authentication protocols Required
Configure third-party agent Or OAC or Pulse
Configure Host Enforcer policies Optional

Table 3: Summary of Actions Required to Configure the Pulse Policy

Secure Solution (continued)
Action Required or Optional
Configure Host Checker policies Required
Configure 802.1X for Layer 2 access Or use Infranet Enforcer
Related Configuring the Pulse Policy Secure Solution on page 13

Documentation

Before You Configure the Pulse Policy Secure
The following table summarizes the steps required to completely configure the Pulse
Policy Secure solution.
Table 4: Configuration Topics
Topic Details
Date and Time of the Infranet Enforcer and the Be sure to set the date and time of the Infranet Enforcer to match the
Pulse Policy Secure date set for the Pulse Policy Secure. If possible, use a Network Time
Protocol (NTP) server to set the date and time for both appliances.
Kerberos If you configure the Pulse Policy Secure to use Active Directory for
user authentication, Windows endpoint users can automatically sign in
to the Pulse Policy Secure using the same credentials they use to
access their Windows desktops.
Non-Pulse Secure If you are connecting with 802.1X, and you are using a non-Juniper
supplicants Networks supplicant (a non-UAC agent), the Infranet Enforcer is not
supported, unless you are using an IF-MAP Federation network with a
DHCP server.

Related
Documentation
 Using Kerberos SSO on page 303
Using Task Guidance
With UAC 4.1, the Pulse Policy Secure features Task Guidance. Task Guidance provides a
graphical interface to make configuring the device simpler.

When you initially log in to the Pulse Policy Secure, the main Task Guidance page is
displayed on screen.
If you close Task Guidance, you can access the feature by selecting Guidance in the upper
right corner of the screen. The console is displayed with labels for different configuration
options that you perform to configure the device. When you click on a label, that section
expands to display individual tasks.
When you navigate to a page with configuration tasks, a new console pops up to provide
instruction. You can scroll the Instruction console up and down, allowing you to view the
configuration page, or you can close the console. If you close the console, an Instruction
link is displayed in the upper right corner of the screen.
If you click the Instruction link, specific information about the current configuration page
is displayed.
After you complete a task, you are prompted to go to the next task.
Task Guidance is available with standard UAC, the RADIUS license, and the Enterprise
Guest Access (EGA) license.
Configuring the Pulse Policy Secure Solution
To configure the Pulse Policy Secure solution:
1. If you have not already done so, install the hardware.
2. If you have not already done so, upgrade and license the software.
3. If you are using the Infranet Enforcer, install the device.
4. If you are using the Infranet Enforcer, perform both of the following steps to set up
certificates on the and Infranet Enforcer:
 Import a signed server certificate into the Pulse Policy Secure.
 Import the certificate of the certificate authority (CA) that signed the Pulse Policy
Secure server certificate into the Infranet Enforcer.
5. If you are using the Infranet Enforcer, configure the connection to the Infranet Enforcer.
To determine compatible devices, see 4.3R1 Supported Platforms.
NOTE: With Pulse Policy Secure Release 4.2 and Junos OS Release 12.2,
you can use the Juniper Networks EX Ethernet Switch as an Enforcer.
As with the ScreenOS Enforcer and Junos Enforcer, you create a connection
between the two devices, and then configure resource access policies to
determine access. See “Pulse Policy Secure and EX Series Switch
Configuration Task Summary” on page 159.

6. Configure user authentication and authorization by setting up roles, authentication

and authorization servers, and authentication realms:
a. Define user and administrator roles. Roles define user session parameters and
OAC, Pulse, or agent/agentless options. The system is preconfigured with one user
role (Users) and two administrator roles (Administrators and Read-Only).
b. Define authentication and authorization servers. Authentication and authorization

servers authenticate user credentials and determine user privileges within the
system. The system is preconfigured with one local authentication server (System
Local) to authenticate users and one local authentication server (Administrators)
to authenticate administrators. You must add users to either the local
authentication server or the external authentication servers.
c. Define authentication realms. Authentication realms contain policies specifying

conditions the user or administrator must meet to sign in to the system. For example,
you can use an authentication policy to specify that users can access protected
resources only if they are signing in from a particular location. When configuring
an authentication realm, you must create rules to map users to roles and specify
which server (or servers) the should use to authenticate and authorize realm
members.
The system is preconfigured with one realm (Users) that maps all users
authenticated through the System Local server to the Users role. The system is
also preconfigured with one realm (Admin Users) that maps all users authenticated
through the Administrators server to the .Administrators role.
NOTE: The system modifies usernames that contain spaces or

characters that are not valid on the Infranet Enforcer. For example,
usernames with spaces appear in auth table entries as one word, and
quotes in usernames appear without the quotes.
7. (Optionall) Select and configure OAC options (such as timeout values and restrictions),
or create Pulse configuration parameters.
Macintosh endpoints can use the Macintosh version of OAC. To configure client-side
settings on the Macintosh version, you can create a script from the Windows version
of Odyssey Client Administrator and import it to the Macintosh to populate agent
settings.
Alternately, you can configure endpoints to connect with agentless access, or you can
configure the lightweight Java agent for access with Linux endpoints. In an 802.1X
deployment, you can also use a non-Pulse Secure supplicant.
8. If you are using the Infranet Enforcer, configure resource access policies to specify
which roles are allowed or denied access to resources.
9. If you are using the Infranet Enforcer, do one of the following to set up source IP
enforcement and/or IPsec enforcement:

 Set up source IP enforcement by configuring an infranet auth policy on the Infranet

Enforcer. Source IP enforcement allows the Infranet Enforcer to control which zones
use resource access policies to allow or deny traffic.
 Set up IPsec enforcement on Windows endpoints that OAC supports. You can use
IPsec enforcement between the endpoint and the Infranet Enforcer instead of source
IP enforcement. To use IPsec, you must set up a VPN tunnel for a dial-up user with
IKE on the Infranet Enforcer.
10. In a Layer 2 environment without the Infranet Enforcer, configure OAC, Pulse, or a
non-Juniper Networks 802.1X supplicant for endpoints. You must also configure
policies to allow the Policy Secure gateway RADIUS server to work with the NAD
(NAD).
 If you have not already done so, install and configure the 802.1X NADs on the
network. See the documentation provided with the NAD.
 If you have not already done so, configure VLANs within the network for deployments
that are not using the Infranet Enforcer. The simplest scenario is to configure two
VLANs: one for authenticated users and a remediation VLAN for users who do not
meet authentication requirements.
11. Optionally, configure Host Enforcer policies to protect endpoints that use OAC and
enforce policies on the endpoint itself by allowing only the traffic you specify in the
Host Enforcer policies for the role. While this is not a substitute for a firewall, Host
Enforcer policies can add another layer of access control. Host Enforcer is not
supported on Pulse.
12. Create Host Checker policies and set remediation options.
13. Determine at which levels within the access management framework to enforce the
Host Checker policies:
 To enforce Host Checker policies when the user first accesses the , implement the
policies at the realm level.
 To allow or deny users access to roles based on their compliance with Host Checker
policies, implement the policies at the role level.
 To map users to roles based on their compliance with Host Checker policies, use
custom expressions.
14. If necessary, configure agentless access to protected resources for endpoint platforms
that OAC or Pulse do not support, including Linux and Solaris.
15. If necessary, configure the Java agent for access to protected endpoints for Linux.
16. Deploy the UAC solution to users.
TIP: Be sure to set the date and time of the Infranet Enforcer to match the
date set for the Pulse Policy Secure. If possible, use a Network Time
Protocol (NTP) server to set the date and time for both appliances.
Related Deploying the Pulse Policy Secure Solution to Users on page 16

Documentation


 Understanding Licensing
 Installing a Software Service Package
 Using Certificate-Based Security with Infranet Enforcer Deployments on page 92
 Understanding User Roles on page 261
 AAA Server Overview on page 279
 Understanding Authentication Realms on page 425
 About Resource Access Policies on page 145
 Understanding Infranet Enforcer Source IP Security Policies on page 148
 Understanding Pulse Policy Secure Support for IPsec Routing Policies on page 123
 Understanding 802.1X Network Access Control Deployments on page 178
 Using Host Enforcer Policies on page 251
 Creating Global Host Checker Policies on page 493
 Additional Methods for Accessing Protected Resources Behind the Policy Secure
gateway on page 72
Deploying the Pulse Policy Secure Solution to Users
When you deploy the Pulse Policy Secure and Infranet Enforcer, users must connect to
the Pulse Policy Secure for authentication and endpoint security checking before they
are allowed to access protected resources.
NOTE: The Pulse Policy Secure runs Host Checker endpoint assessments
before users are allowed to access the network. This is accomplished inside
a Trusted Network Connect (TNC) handshake. The TNC component is
downloaded through a Network Control Protocol (NCP) connection at Layer
3, once an IP connection has been established.
With Layer 2 authentication, the initial authentication always fails, because

without an IP address the endpoint cannot download the TNC component.
You can create a special remediation role with no access restrictions to allow
endpoints to authenticate and download the required components.

The following methods can be used to provision access to users:
 Install OAC on Windows or Macintosh endpoints— OAC provides support for user
authentication and endpoint security checking on both wired and wireless networks.
It also includes an 802.1X supplicant for authentication on 802.1X networks. You can
preconfigure the Windows version of OAC with the appropriate settings for your
environment.
For Windows endpoints, the easiest way to install OAC is by having users browse to
the sign-in URL. OAC is then automatically installed on the user’s endpoint as the
default behavior.
On the Macintosh version, the client is not automatically installed. Users navigate to
a sign-in URL that redirects them to the Macintosh landing page from there, they can
manually download and install the .dmg file.
You can also manually install OAC and Pulse (Windows only) on endpoints by
downloading the installer package and providing the package to endpoint users.
If you are using 802.1X NADs that support a preconfigured VLAN that allows limited
unauthenticated network access, users can browse to the 802.1X supplicant included
in OAC or Pulse.
 Install Pulse on Windows or Macintosh endpoints—Pulse supports all of the

connection methods that can be used with OAC (Layer 2 and Layer 3 connectivity, and
wired or wireless connections). Pulse also supports static and dynamic IPsec and
Source IP enforcement as a UAC agent. Pulse supports SSL transport for SSL VPN
tunnels to SA Series SSL VPN Appliance. 802.1X with UAC is available on Windows
XP SP3, Windows Vista, and Windows 7 by leveraging components from the native
Windows supplicant.
The easiest way to install Pulse is for users to browse to the sign-in URL to a role for
which Pulse is chosen as the agent. Pulse is then automatically installed on the user’s
endpoint as the default behavior.
You can manually install Pulse on endpoints by downloading the default installer
package, or you can create a custom installer and distribute it to users via a systems
management server (SMS). For more information see the Pulse Secure
documentation.
NOTE: The Pulse Policy Secure solution supports Kerberos single

sign-on. If you use Active Directory for user authentication, Windows
endpoint users can automatically sign in using the same credentials they
use to access their Windows desktops.
 Direct endpoints that use the Java agent to a Web site to download the agent—If
you select the Java agent for access on Linux platforms, the system automatically
downloads the Java agent to the client machine after the user is authenticated.

 Instruct users how to use agentless access—Users can connect using a browser on
Windows, Macintosh, Linux, and Solaris endpoints.
 Ensure that a non-Pulse Secure supplicant is installed—Endpoints that do not have

OAC or Pulse installed can be authenticated with 802.1X through the Policy Secure
gateway with a non-Juniper Networks supplicant.
NOTE: A non-Juniper Networks 802.1X supplicant is also termed a non-UAC

agent. A non-UAC agent is any client that connects using non-Juniper
Networks protocols (JUAC, for example) for authentication.
NOTE: If you are connecting with 802.1X, and you are using a non-Juniper
Networks supplicant (a non-UAC agent), the Infranet Enforcer is not
supported, unless you are using an IF-MAP Federation network with a DHCP
server.
You can use the following methods to help users in your deployment:
 Redirect HTTP traffic destined for protected resources to the sign-in page—To direct
users to the Pulse Policy Secure, you can configure the Infranet Enforcer to
automatically redirect HTTP traffic destined for protected resources. This Infranet
Enforcer feature is called captive portal.
 Instruct users to access the sign-in page using a browser at the URL you specify—Use
this method if you do not configure a captive portal, or if users access protected
resources using non-HTTP methods. (The captive portal feature redirects HTTP traffic
only).
 Preinstall OAC or Pulse—You can use this method if you are using 802.1X NADs that
do not allow users to connect to the Pulse Policy Secure without a client installed.
This method is also necessary for users who do not have the required administrator
rights on their endpoints to install OAC or Pulse. In these cases, you must use some
other method to preinstall OAC or Pulse on these endpoints, such as SMS (for Windows
only), remote login, or manual preinstallation.
Since the Macintosh version of OAC is not automatically installed on client machines,
preinstalling is an effective way to install OAC on the Macintosh to simplify the user
experience.
 Install and configure a non-Pulse Secure 802.1X supplicant—If endpoints connect

using a supplicant other than OAC, ensure that the authentication protocols that the
supplicant uses for authentication are compatible with the protocols used in your
access management framework configuration.
Related Creating Global Host Checker Policies on page 493

Documentation
 Creating an Initial Configuration of OAC for Windows Endpoints on page 22

 Understanding the Initial Pulse Policy Secure Deployment User Experience on
page 19

gateway on page 72
 Understanding the Infranet Enforcer Captive Portal Feature on page 109
 Understanding Pulse Policy Secure Authentication Protocols on page 168
Pulse Policy Secure Deployment Summary
Table 5: Scenarios and Methods of Deployment
Scenarios Methods
OAC, Pulse, or non-Pulse Secure 802.1X supplicant
 Unauthenticated wired network access  Captive

portal—Redirect HTTP traffic in user’s
(no 802.1X authentication) browser to Policy Secure gateway user sign-in
URL
 Announcement—Instruct users to use a web
browser to manually find the sign-in URL
 802.1X switches that allow  Captive portal—Redirect HTTP traffic in user’s
unauthenticated access by using a browser to Policy Secure gateway user sign-in
preconfigured VLAN that allows limited URL
network access  Announcement—Instruct users to use a web
browser to manually find the sign-in URL
 802.1X switches or wireless access  Preinstallation of OAC, Pulse, or third-party

points that do not allow any means to supplicant by means of SMS or remote login on
access the Pulse Policy Secure endpoints
 Users who do not have administrator
rights on endpoint, which is required for
OAC or Pulse installation
Agentless or Java agent (no 802.1X authentication)
 Captive portal—Redirect HTTP traffic in user’s

browser to the sign-in URL
 Announcement—Instruct users to use a browser
to manually find the sign-in URL
Related Deploying the Pulse Policy Secure Solution to Users on page 16

Documentation
 Understanding the Initial Pulse Policy Secure Deployment User Experience on

page 19
Understanding the Initial Pulse Policy Secure Deployment User Experience
The user experience during initial deployment depends on whether the user is accessing
the Windows or Macintosh version of OAC, Pulse, the Java agent, an agentless
deployment, or a non-UAC agent (third-party 802.1X supplicant). Additionally, you can
preconfigure the settings for OAC and Pulse on the Policy Secure gateway
(recommended), and you can configure SSO for Windows endpoints.

If you evaluate or enforce a Host Checker policy at the realm level, OAC and Pulse
automatically run the built-in Host Checker on the endpoint to verify for security
compliance before the user is authenticated. If the endpoint is in compliance, the user is
assigned the role. If you enforce Host Checker at the role level, the user can be
authenticated, but can access only roles whose Host Checker policies the endpoint can
pass.
 OAC on supported Windows endpoint platforms—If you have configured OAC as the
client for a role on Windows machines, the first time the user accesses the Pulse
Policy Secure using a browser, the system automatically installs OAC on the user’s
computer with the OAC configuration settings you specify. If you enable validation of
the device certificate, the user must allow the root CA certificate to be installed. After
the initial OAC installation, OAC automatically starts when the user signs into their
computer, and displays a sign-in dialog box to sign in to the Policy Secure gateway.
If you integrate a solution with Active Directory Service and enable SSO, Windows
endpoint users automatically sign in using the same credentials they use to access
their Windows desktop. The sign-in dialog box for OAC does not appear.
 OAC on supported Macintosh endpoint platforms—OAC is not automatically installed

on Macintosh endpoints. You can direct users to a sign-in page, and the system detects
what type of client is attempting to log in. If the machine is a Macintosh, the system
displays a landing page from which the user can download and manually install OAC.
 Pulse on supported Windows endpoint platforms—If you have configured Pulse as

the client for a role on Windows machines, the first time the user accesses the system
using a browser, the Policy Secure gateway automatically installs Pulse on the user’s
computer with the configuration settings you specify. The user is prompted to accept
the security certificate. After the initial installation, Pulse automatically starts when
the user signs into their computer and displays a sign-in dialog box to sign in.
If you integrate a solution with Active Directory Service and enable SSO, Windows
endpoint users automatically sign in using the same credentials they use to access
their Windows desktop. The sign-in dialog box for Pulse does not appear.
 Java agent—If you provision a Linux user for access with the Java agent, a lightweight
client is automatically downloaded after the user is authenticated through a browser.
The agent displays connection status, the IP address, and a logout mechanism. The
user is not required to leave the browser window open, but if the session expires, the
user must provide credentials through a browser again.
 Agentless access—If you configure agentless access for users on Windows, Macintosh,
Linux, or Solaris endpoints, the user always signs in directly using a browser instead of
OAC. If you evaluate or enforce a Host Checker policy at the realm level, Host Checker
is installed and is run on the endpoint.

NOTE: When using agentless access, the user must leave the browser
window that contains the sign-in page open. If the user closes the browser
window or opens a different window, the endpoint loses the connection
to the Pulse Policy Secure, and the Infranet Enforcer denies the user
access to protected resources.
 Non-UAC agent software (third-party 802.1X supplicant)—Users of non-UAC agent

software must preinstall a security certificate and configure authentication protocols
that have been configured for the access management framework. These clients can
connect only via Layer 2, so if any restrictive Host Checker policies are configured, users
cannot connect. You can configure a default VLAN with no Host Checker restrictions
for the initial login.
Related Creating an Initial Configuration of OAC for Windows Endpoints on page 22

Documentation

gateway on page 72
Specifying the Client that Endpoints Use for Access
For each role you create, you specify which client users must employ when they access
that role.
You can specify the following clients for each role on the Agent > General tab:
 OAC (for Windows or Macintosh endpoints)
 Pulse (for Windows or Macintosh endpoints)
 Agentless Host Checker client (for all platforms)
 Java agent (for Linux and Solaris endpoints)
To provision OAC, select the Odyssey Settings for IC Access and/or Odyssey Settings for
Preconfigured Installer check box to allow you to access Odyssey configuration options
after you create a role. After you save the role, select Users > User Roles > Select Role >
Agent, and then select the Install Agent for this role check box. Then select the Install
Odyssey check box.
To configure OAC access options select Users > User Roles > Select Role > Agent > Odyssey
Settings.
To provision Pulse, agentless access, or the Java agent, do not select the Odyssey check
boxes when you create the role.
To use the agentless access option, you create a role, then you select Users > User Roles
> Select Role > Agentless, and select the Enable Agentless Access for this role check box.

Then, configure agentless appearance options from the Users > User Roles > Select Role
> General > UI Options tab.
To specify the Java agent for a role, you create a role, then you select Users > User Roles
> Select Role > Agent, and select the Install Java Agent for this role check box.
To install Pulse on endpoints, you create a role, then you select Users > User Roles >
Select Role > Agent, and select the Install Agent for this role check box. Then, select the
Install Pulse check box.
Then, you configure Odyssey access options from the Users > User Roles > Select Role >
Agent > Pulse Settings tab.

Documentation
 Understanding Deployments with Pulse Secure Clients on page 34

Creating an Initial Configuration of OAC for Windows Endpoints
For Windows endpoints, you can preconfigure OAC with the settings required to connect
to the Pulse Policy Secure. You can configure all of the settings for the client on a
per-role basis. When the user first accesses the Pulse Policy Secure using a browser,
the Policy Secure gateway automatically installs OAC on the user’s computer. Each
time the user accesses a resource that is protected by the Policy Secure gateway, the
OAC configuration settings you specify are used.
NOTE: If OAC is already installed when the user accesses the Policy Secure
gateway, configuration settings you specify except for the login name in the
profile, all of the other configuration settings you specify on the Policy Secure
gateway overwrite any existing settings on the endpoint.
You can create a unique set of configuration settings for each role. For example, you can
create a role for users that use wired adapters, and another role for users that use wireless
adapters.
You determine whether or not OAC is installed at the role level, and you configure OAC
options through the Odyssey Access Client section of the Policy Secure gateway
interface.
In the admin console there are two tabs under Odyssey Settings. The IC Access tab allows
you to configure authentication and connection settings for OAC. The Preconfigured
Installer tab provides an interface that allows you to upload a preconfigured version of
OAC that you can deploy to users when they access a role.

NOTE: OAC is automatically configured to use the authentication protocol

settings in the default 802.1X authentication protocol set, which includes
Juniper Networks JUAC protocol. If you want to use different protocols for
authentication, you must configure a new protocol set on the Policy Secure
gateway, and you must configure matching settings on OAC. If you alter the
protocol settings on OAC, the client functions only as a 802.1X supplicant
for basic connectivity, and does not have any of the features of OAC such
as Host Checker, role and realm restriction enforcement and connection
with an Infranet Enforcer.
Related Specifying the Client that Endpoints Use for Access on page 21
Documentation
 Provisioning Detailed Configuration Profiles for Macintosh OAC Endpoints on page 34

Understanding OAC Configuration Settings for Windows Endpoints
Table 6 on page 23 lists settings that you can configure on the Policy Secure gateway
and the settings that the Policy Secure gateway automatically configures in OAC for
you.
Table 6: Initial OAC Configuration Settings
The Policy Secure The Policy Secure

gateway gateway
adds these items to You can preconfigure these automatically configures
OAC: settings in the Policy Secure gateway: these settings
for you:
Profile  Name of profile instance in OAC.  Enables OAC to validate
 Login name. the server certificate of
the Policy Secure
 Options for using the user’s
gateway
Windows credentials or
prompting user for login name
and/or password.
 Outer authentication
protocol—Tunneled TLS (TTLS)
or Protected EAP (PEAP).
 Personal certificate usage.
Policy Secure  Name of Policy Secure gateway instance  Server URL is
gateway sign-in
in OAC. URL.  New profile is associated
with Policy Secure
gateway
connection

Table 6: Initial OAC Configuration Settings (continued)
The Policy Secure The Policy Secure

gateway gateway
adds these items to You can preconfigure these automatically configures
OAC: settings in the Policy Secure gateway: these settings
for you:
Trusted server  Server name is common
name specified in Policy
Secure gateway server
certificate.
 Trusted root CA certificate
is added to OAC
certificate properties for
new trusted server.
Adapter  Configure the adapter that is

actively being used to access the
Policy Secure gateway (wired or
wireless adapter connected to
an
802.1X-enabled network).
 Configure a second adapter of the
other type. For example, if a wired
adapter is used to access the
Policy Secure gateway, then
automatically configure a
wireless adapter.
Network 

Do
If notadd
you addaany adapters.
wireless adapter, the If you select WEP encryption,
network name (SSID), association keys are generated
mode, and encryption method. automatically.

Documentation

 Specifying the Client that Endpoints Use for Access on page 21
Defining the Initial Configuration for OAC for Windows
To define the initial configuration of OAC:
1. In the admin console select Users > User Roles > New User Role from the left navigation
bar.
2. Enter a name for this role in the Name box.
3. Select the Odyssey Settings for IC Access and Odyssey Settings for Preconfigured
Installer check boxes to preconfigure OAC.
4. Click Save Changes. The roles configuration page opens with the name you entered
for this role at the top of the page.
5. Click the Agent tab. The Install Agent for this role check box is selected by default.

NOTE: You can continue configuring this role, or you can complete the
configuration of OAC.
6. Select the Odyssey Settings tab. The IC Access configuration page is displayed.
7. Select an option for naming the profile and Policy Secure gateway instance in OAC:
 Use Policy Secure gateway's host name—Specifies the name of the profile and
the Policy Secure gateway instance in OAC. If the Policy Secure gateway does not
have a hostname configured, the URL for the Policy Secure gateway or the
redirect URL from a captive portal is used instead.
 Use this name—Specifies the name of the profile and the Policy Secure gateway
instance in OAC.
8. Under Policy Secure gateway, select Require connection to this Policy Secure gateway
to require the enforcement of Host Enforcer policies on the endpoint that apply to
the user’s role. This option requires OAC to always attempt to connect to this Policy
Secure gateway and prevents the user from disconnecting from this Policy Secure
gateway. The user also cannot delete the properties of this Policy Secure gateway
from the OAC configuration.
In effect, this option forces the enforcement of any applicable Host Enforcer policies
whenever the endpoint is on the network. If the endpoint is not on the network or is
unable to connect to the required Policy Secure gateway, the Host Enforcer policies
are not enforced.
9. Under Profile, specify the settings to configure in the OAC profile:
a. Under Login name, specify how you want to configure the Login name setting in
the profile:
 Use qualified Windows login name (domain\user) configures the login name with
the user’s Windows domain name and username in the format domain
name\username. Use this option if you are using an Active Directory authentication
server that requires a domain name in addition to a username for authentication.
 Use unqualified Windows login name configures the login name with the user’s
Windows username only. Use this option for authentication servers that require
a username only for authentication.
 Prompt for login name using the following prompt displays a dialog box for the
user to enter a name during the initial OAC installation only. The login name is
then configured and the user is not prompted again. You can also configure the
text string used for the prompt in the dialog box.
b. Select Permit login using password to enable password authentication, and then
select an option for how OAC obtains user credentials to sign into the Policy
Secure gateway:
 Use Windows password enables OAC to automatically authenticate the user to

the Policy Secure gateway by using the user’s Windows password. During the
initial OAC installation, the user must enter a password once. OAC
automatically uses the Windows password after that.

 Prompt for password enables OAC to prompt the user to enter a password when
the user is authenticated the first time after startup. OAC reuses the user’s
credentials for the duration of the Windows session. If you choose this option
and if you have configured SSO, OAC does not prompt the user for the password.
c. Specify whether to use Tunneled TLS (TTLS) or Protected EAP (PEAP) as the
outer authentication protocol for traffic between OAC and the Policy Secure
gateway by selecting either Use EAP-TTLS as outer authentication protocol or
Use EAP-PEAP as outer authentication protocol.
 If you select Use EAP-TTLS as outer authentication protocol and you want to use
a client certificate as part of the EAP-TTLS authentication, select Use the user’s
certificate and perform inner authentication. This option uses EAP-TTLS
certificate-based authentication and tunnels password credentials with inner
authentication. Note that the most typical use of EAP-TTLS authentication is
without a client certificate.
 If you select Use EAP-PEAP as outer authentication protocol and you want to use
a client certificate as part of the EAP-PEAP authentication, select Inner
authentication is required.
NOTE:
 Enter a name in the Anonymous name box to enable users to appear
to log in anonymously while passing the user’s login name (called
the inner identity) through an encrypted tunnel. As a result, the
user’s credentials are secure from eavesdropping and the user’s
inner identity is protected.
 If you enable the personal client certificate option, the Policy

Secure gateway automatically selects Permit login using my
Certificate and Use automatic certificate selection in the OAC
profile.
d. Enter a name in the Anonymous name box to enable users to appear to log in
anonymously while passing the user’s login name (called the inner identity) through
an encrypted tunnel. As a result, the user’s credentials are secure from
eavesdropping and the user’s inner identity is protected.
As a general rule, enter anonymous in the this box, which is the default value. In
some cases, you may need to add additional text. For example, if the outer identity
is used to route the user’s authentication to the proper server, you might be required
to use a format such as anonymous@acme.com. If you leave the Anonymous name
box blank, OAC passes the user’s login name (inner identity) as the outer identity.
10. (Only if you are using 802.1X enforcement) Under Adapters, specify the type of adapter
you want to configure in OAC:
 Configure wired adapter(s)—OAC configures the wired adapter on the user’s

computer that is actively being used to access the Policy Secure gateway on an
802.1X-enabled network. If the user is accessing the Policy Secure gateway
through a
wireless adapter during OAC installation, then OAC automatically configures a wired
adapter for wired access to the Policy Secure gateway at a later time.

 Configure wireless adapter(s)—OAC configures the wireless adapter on the user’s

computer that is actively used to access the Policy Secure gateway on an 802.1X-
enabled network. If the user is accessing the Policy Secure gateway through a wired
adapter during OAC installation, then OAC automatically configures a wireless
adapter to use for wireless access to the Policy Secure gateway at a later time.
Select this option only if the endpoint is connecting to the Policy Secure gateway
by using 802.1X. If you select this option, you must also configure the network
name (SSID) under Network. You might also need to configure other Network
properties, depending on your environment.
NOTE: On Windows systems, if you select Configure wireless adapter(s),

Windows Wireless Zero Configuration (WZC) is disabled for the wireless
adapter that OAC configures. If the user removes a wireless adapter
from the local OAC configuration, the user must enable the adapter
again by selecting Control Panel > Network Connections> adapter name
> Properties > Wireless Networks and selecting the Use Windows to
configure my network settings option.
11. (Only if you selected Configure wireless adapter) Under Network, specify the network
settings you want to configure in OAC for wireless adapters:
 Network name (SSID)—Specify the network name or service set identifier (SSID)
of the wireless network to which you want OAC to connect. A network name can
contain up to 32 alphanumeric characters and is case sensitive. You must enter the
name correctly to connect successfully. For example: <MyCorpNet>.
 Association mode—Specify the association mode you want OAC to use when
associating to the access point hardware on the network:
 Open—Connects to a network through an access point or switch that implements

802.1X authentication. Select this mode if users are not required to use shared
mode or Wi-Fi Protected Access (WPA).
 WPA—Connects to a network through an access point that implements WPA.
 WPA2—Connects to a network through an access point that implements WPA2,

the second generation of WPA that satisfies 802.11i.
 Encryption method—Specify the encryption method for OAC to use. The available
choices depend on the association mode you select:
 None—Uses 802.1X authentication without WEP keys. This option is available

only if you configure access point association in open mode. This is a typical
setting to use for wireless hotspots.
 WEP—Uses WEP keys for data encryption. You can select this option if you
selected open mode association. Select WEP encryption if the access points in
the network require WEP encryption. OAC automatically generates the WEP keys.

 TKIP—Uses the Temporal Key Integrity Protocol. Select TKIP if the access points
in the network require WPA or WPA2 association and are configured for TKIP
data encryption.
 AES—Uses the advanced encryption standard protocol. Select AES if the access
points in the network require WPA or WPA2 association and are configured for
AES data encryption.
NOTE: If you select WEP encryption, the Policy Secure gateway

automatically selects the Keys will be generated automatically for data
privacy option in the OAC Network properties for the wireless
adapter on OAC.
12. Click Save Changes.
13. In the admin console select Roles > user > General > Overview. Then select the Odyssey
Settings for IC Access check box. Note that if the Odyssey Settings for Preconfigured
Installer check box is selected, the options on the Odyssey Settings for IC Access page
overwrite the options from the preconfigured installer.
NOTE:
 Because the configuration settings you specify on the Policy Secure
gateway overwrite existing settings on the endpoint (except for login
name), you can use the Odyssey Configuration page in the admin console
to change settings for users. For example, to remove the requirement to
connect to a particular Policy Secure gateway, clear the Require
connection to this Policy Secure gateway check box in the sign-in policy.
Then instruct users to access the IC
Series device again using a browser to download OAC with the new setting.
 The settings you specify on the Odyssey Configuration page do not configure
the settings for the OAC installer (called OdysseyAccessClient.msi) that
you can manually download from the Installers page. However, after
installation, you can instruct users to access the Policy Secure gateway
using a Web browser to automatically configure OAC using the
configuration settings you specified on the Odyssey Configuration page.
 For more information see

http://www.juniper.net/techpubs/en_US/release-independent/aaa-802/information-products/pathway-pages/oac/product/
.
Related Configuring General Role Options on page 267

Documentation

 Downloading Client Installer Files on page 708

Using the Preconfigured Installer for OAC on Windows Endpoints
You can create a preconfigured installer for OAC that is downloaded to Windows
endpoints using the Custom Installer in the Odyssey Client Administrator (OCA). The
OCA is a utility that allows you to fully configure all of the OAC settings.
A preconfigured installer contains the settings you configured using the OCA as well as
certificates. The installer might also contain a license key and a flag indicating whether
or not GINA is installed on the client. You must include the license key for OAC upgrades
if you are upgrading to UAC from an earlier version.
After you configure all of the settings with the OCA, you export the preconfigured installer
as a .zip file to a directory that is accessible to the Policy Secure gateway. You upload
the preconfigured installer file from the Policy Secure gateway admin console interface.
The settings available in the OCA allow you to comprehensively control security and
accessibility features for users who access the Policy Secure gateway. For example, you
can hide or disable the configuration icons on the sidebar of OAC, you can control
whether or not endpoints can modify adapter settings, and you can configure settings
to prevent endpoints from disabling OAC.
The preconfigured installer downloads are role based. When you create new user roles,
you can specify a preconfigured installer that you have created specifically for the role.
You can configure a different OAC feature set for each role that you create. For example,
you can create a client configuration with few restrictions for employee roles and a more
restrictive configuration for visitor roles. Alternately, you can select the same configuration
for different roles.
When OAC is installed or upgraded on an endpoint, the preconfigured installer file is

downloaded from the Policy Secure gateway. The file that is downloaded depends on
the authenticated user’s role.
If a user is assigned to more than one role, and the roles have different OAC preconfigured
installer files, the settings from the first role assigned are retained.
Related Preconfiguring OAC Using the Custom Installer on page 29

Documentation

Preconfiguring OAC Using the Custom Installer
To preconfigure OAC:
1. Open OAC Manager and select Tools > OAC Administrator from the OAC toolbar. The
OCA console opens.
2. Configure all of the OAC settings that you want to apply for a preconfigured installer,
including certificates and license using the tools in the OCA. For more information see
the Odyssey Access Client Administration Guide.
3. Double-click Custom Installer.

4. Select the Preconfiguration file option button.
5. Enter a name for the destination file.
6. (Optional) Select Export license key and enter any valid license key (Enterprise or FIPS
Edition) for the copies of OAC to distribute for a given role.
7. Click Browse to download the file to a selected location.
NOTE: The download consists of a .zip file containing a properties.xml

file with licenses and GINA settings, a preconfig.xml file, and certificates.
8. Click OK.
9. Select an existing role from the Users > User Roles page on the Policy Secure gateway
admin console, or create a new role.
10. Select the Odyssey Settings for Preconfigured Installer check box. Note that if you also
click the Odyssey Settings for IC Access check box, the options on that page will
overwrite the options from the preconfigured installer.
11. Click the Edit link.
12. Click the Browse button and locate the file from the selected location. The
preconfigured installer downloads the customized OAC version to all users who access
the specified role.
NOTE: If you do not create and upload an OAC configuration for a role,
users who access that role get the factory default OAC version.
Related Using the Preconfigured Installer for OAC on Windows Endpoints on page 29
Documentation

Validating the IC Series Certificate
When Windows users install OAC by accessing the Policy Secure gateway through a
browser, the Validate server certificate option on the Authentication tab of the user’s
profile is automatically enabled. When this option is enabled, OAC validates the server
certificate of the Policy Secure gateway. OAC is automatically configured to trust the
Policy Secure gateway if it can verify that the Policy Secure gateway is passing a valid
certificate.
For this verification to occur, the trusted root certificate of the CA that signed the Policy
Secure gateway’s server certificate must be installed on the endpoint. If the CA
certificate is not installed, then the user cannot authenticate.
You can install the trusted root CA certificate on the endpoint in any of the following
ways:
 Using a CA certificate that is chained to a root certificate already installed on the

endpoint, such as Verisign.

 Importing the CA certificate on the endpoint by whatever method your organization

uses to distribute root certificates.
 Uploading the CA certificate and any intermediate CA certificates to the Policy

Secure gateway. During OAC installation, the Policy Secure gateway automatically
installs the CA certificate on the endpoint. When prompted during installation, the
user must allow the installation of the CA certificate.
Related Using Trusted Server CAs on page 622

Documentation

Using OAC Licenses with the IC Series
You can configure the Windows version OAC to download by default from the Policy
Secure gateway. The downloaded edition contains all of the functionality in the
Enterprise Edition, including an 802.1X wired and wireless supplicant. The currently
installed Policy Secure gateway Endpoint License determines the maximum number of
concurrent endpoints that can access OAC with the Policy Secure gateway.
The FIPS Edition of the Windows version OAC can also be used with the Policy Secure
gateway. All editions support the full OAC feature set and OAC Administrator. The
licenses for the FIPS edition and Enterprise Edition must be purchased in addition to the
Policy Secure gateway Endpoint License. To prevent user sessions generated by these
two editions from increasing the concurrent user count against the Policy Secure
gateway Endpoint License, you can install the OAC-Add-UAC license on the Policy
Secure gateway.
NOTE: You can use the FIPS edition of OAC with the non-FIPS edition of the
Policy Secure gateway. In this case, data between OAC and an 802.1X
switch is protected by FIPS-validated encryption.
If you add a FIPS license to 64-bit OAC, the agent is an Enterprise Edition
with no FIPS capability. The only advantage in using a FIPS licensed 64-bit
OAC is that the agent can use xSec.
FIPS is not supported on the Macintosh version of OAC. The FIPS license is
accepted on the Macintosh version, but functionally the agent is equivalent
to the Enterprise Edition.
Related Using the Preconfigured Installer for OAC on Windows Endpoints on page 29
Documentation

Manually Installing OAC
If your 802.1X switch does not allow network connectivity from your computer to the
Policy Secure gateway, or if you are deploying the Macintosh version of OAC and want
to install the agent manually, use the instructions in this section to download the OAC
.msi for Windows or .dmg for the Macintosh to another computer that has network
connectivity to the Policy Secure gateway. Then, transfer the OAC .msi or .dmg file to
endpoints to manually

install and configure OAC. You can download either 32-bit or 64-bit version of OAC for
Windows, or the Macintosh version.
To manually install OAC:
1. In the admin console, select Maintenance > System > Installers.
2. Click the Download link for the correct version and platform of OAC. The File Download
dialog box is displayed.
3. Click Save in the File Download dialog box. The Save As dialog box is displayed.
4. Select an appropriate location in the Save As dialog box.
5. Click Save in the Save As dialog box.
6. Distribute the OAC .msi or .dmg installer program to endpoints that do not have
network connectivity to the Policy Secure gateway.
7. For Windows machines, double-click the OAC installer and respond to the prompts.
For Macintosh machines, drag the installer to the Applications folder.
8. Install the trusted root CA certificate or intermediate CA on the endpoint that you
generated.
NOTE: You must have the same root CA or intermediate CA for the server
certificate chain installed in the trusted root or intermediate certificate
store of your machine.
9. To install the CA on Windows systems, open Internet Explorer and select Tools >
Internet Options > Content > Certificates and click Import. To install on a Macintosh
system, double-click the certificate and click OK. The certificate is added to Keychain.
Related Validating the IC Series Certificate on page 30

Documentation
 Manually Configuring OAC for 802.1X (Windows or Macintosh) on page 32

Manually Configuring OAC for 802.1X (Windows or Macintosh)
To manually configure OAC for 802.1X:
1. Double-click the OAC tray icon to display OAC Manager on the Windows version.
Select the icon on the Macintosh version.
2. Configure a user profile in OAC:
a. In the side pane of the OAC Manager, select Configuration > Profiles > Add. The
Add Profile dialog box is displayed.
b. Enter a name in the Profile box.
c. Enter a name in the Login name box.

d. Click the Password tab and select a password option.
e. Click OK.
3. Configure OAC for 802.1X:
a. From the side pane of the OAC Manager, click Configuration > Adapters > Add. The
Add Adapter dialog box is displayed.
b. Click either the Wireless or Wired 802.1X tab to choose an adapter.
c. Select the adapter to use for 802.1X.
d. Click OK.
NOTE: If you do not see your wireless adapter in the list, select All
Adapters. Make sure that the adapters that you select on the Wireless
tab is wireless. You cannot configure OAC for wireless connections
unless you have a wireless adapter installed.
4. Connect to a 802.1X wireless network:
a. In the side pane of the OAC Manager, select Configuration > Networks > Add. The
Networks dialog box is displayed.
b. Specify the following settings for your wireless 802.1X network:
 Select the appropriate setting for Association mode.
 Select the appropriate setting for Encryption method.
 Select Authenticate using profile, and then select the profile you created earlier
from the list box.
 Select Keys will be generated automatically for data privacy.
5. Connect to the network:
a. In the side pane of the OAC Manager, select Configuration > Adapters and select
the adapter you just added.
b. If you are using a wired network, select the profile you just created from the Profile
list on the right. If you are using a wireless network, select the wireless network you
just added from the Network list on the right.
c. Click Connect to the network.
d. When you are prompted for a login name, sign in using the username you configured,
and click OK.
e. When you are prompted for a password, enter the password you configured, and
click OK.

Related Manually Installing OAC on page 31

Documentation

Provisioning Detailed Configuration Profiles for Macintosh OAC Endpoints
OAC does not install automatically on Macintosh endpoints. Users can log in, download,
and then install the agent. Alternately, users or the Policy Secure gateway administrator
can install the client on endpoints manually. To do this, the administrator can
download the
.dmg file from the Policy Secure gateway Maintenance > System > Installers page, and
then either distribute the file to users or install the file on individual machines. The
basic application does not include detailed profiles or settings like those that you can
configure on the Windows version through the preconfigured installer or the OAC
Administrator.
The OAC Macintosh version does not include the OAC Administrator, so detailed
configuration profiles and settings cannot be configured by the user. To provide detailed
profiles on the Macintosh client, you must configure settings on the Windows version of
OAC using the OAC Administrator. Then, use the Script Composer feature of the OAC
Administrator to generate a script that can be transferred to Macintosh machines to
populate detailed profiles on the Macintosh OAC. For details about configuring a detailed
profile, see
.
Related Manually Installing OAC on page 31

Documentation

Understanding Deployments with Pulse Secure Clients
This topic gives an overview of Pulse Policy Secure deployments with Pulse Secure
clients. It includes the following information:
 Pulse Overview on page 34

 Session Migration on page 35
 Location Awareness on page 35
 Security Certificates on Pulse on page 35
 User Experience on page 35
 Platform Support on page 36
 Downloading Pulse to Endpoints with Security Software Installed on page 36
Pulse Overview
Pulse supports all the connection methods that you can use with OAC (Layer 2 and Layer
3 connectivity, and wired or wireless connections). Pulse also supports static and dynamic
IPsec and Source IP enforcement as a UAC agent. An 802.1X connection with UAC is
supported on Windows XP SP3, Windows Vista, and Windows 7 by using components
of the native Windows supplicant. Pulse supports SSL transport for SSL VPN tunnels to
Connect Secure gateways. Pulse can also provide the WAN application acceleration
services.

Session Migration
One of the primary benefits of Pulse is that users can log in once through a device on the
network and then access additional devices without reauthentication.
Using Pulse, you can permit users to migrate from location to location without
reauthentication. For example, a user can connect from home through an Connect
Secure gateway, and then arrive at work and connect through a Policy Secure gateway
without logging in again. Session migration also enables users to access different
resources within the network that are protected by Juniper Networks devices without
repeatedly providing credentials. IF-MAP Federation is required to enable session
migration for users.
Location Awareness
The location awareness feature enables you to define connections that are activated
automatically based on the location of the endpoint. Pulse determines the location of
the endpoint by evaluating location awareness rules that you define. Location awareness
rules are based on the client’s IP address and interface. For example, you can define rules
to enable Pulse to automatically establish a secure tunnel to the corporate network
through an Connect Secure gateway only when the user is at home, and to establish a
UAC connection when the user is connected to the corporate network over the LAN.
You configure the location awareness feature by defining location awareness rules for
individual connections.
Location awareness rules are available for connections that are defined on the access
device and then distributed to endpoints. Users cannot configure the location awareness
feature by manually creating a connection on the Pulse client.
Security Certificates on Pulse

Users cannot add CA servers or manage the server list. Pulse handles certificates similar
to the way a browser handles certificates. If the Pulse dynamic certificate trust option is
enabled for a connection, the user can accept or reject the certificate that is presented
if it is one that is not from a CA that is defined in the endpoint’s certificate store.
An 802.1X connection enables an added layer of certificate verification. When you define
an 802.1X connection on the access device, you can specify server certificate distinguished
names for each CA.
User Experience
Pulse presents a clean, uncomplicated interface for the user. Users can enter credentials,
select a realm, save settings, and accept or reject the server certificate. When you
configure the client, you can specify whether or not to permit users to modify settings,
such as to add connections.
The client displays the connection status until the connection is made. If a connection
fails as a result of the endpoint failing a Host Checker policy, Host Checker reason strings
and remediation options appear.

Platform Support
The following Juniper Networks devices support Pulse:
 Pulse Policy Secure 4.0 or later
 Connect Secure gateway 7.0 or later
 WX Series JWOS 6.1 or later
 SRX Series 9.5 or later
The Pulse client is supported on Windows XP SP3 32, Windows Vista SP1/2 32 and 64,
and Windows 7.
NOTE: Although the ability to configure and deploy Pulse client software
from an SRX Series device is not yet available, endpoints can use Pulse client
software to connect to SRX Series devices that are running Junos OS Release
9.5. You can create connections that use the connection type “Firewall” and
deploy these connections from supported access devices.
Downloading Pulse to Endpoints with Security Software Installed

If endpoint security software is installed, some settings might not allow ActiveX controls
to launch, which disables the browser-based Pulse installation method. For example,
with Kaspersky 2010, users might need to remove the browser manually from the My
Security Zone in the Kaspersky client to allow the installation to run.
Related Pulse Client Configuration Overview on page 37

Documentation

 Understanding Session Migration on page 255
Configuring the Pulse Client for a Role
After you specify the connections and components that you want to distribute with the
client, you can deploy the client to endpoints. Either assign users to a role to receive the
download, or create a custom installer package and distribute it to users.
To configure the Pulse client for endpoints through a role assignment:
1. Select Users > User Roles > New User Role in the admin console, or select an existing
role.
2. For a new role, enter a name.
3. Click Save Changes. The Role configuration options appear.

4. Select the Agent tab.
5. Select the Install Agent for this role check box and then select the Install Junos Pulse
option.
6. Click Save Changes. A new Pulse settings tab is displayed.
7. On the Agent tab, click Junos Pulse Settings.
8. (Optional) Select a component set that you have created, use the Default component
set, or select none. If you select none, you must create an installer package and
distribute to users. The default installer contains all components.
9. Select Users > User Realms > Select Realm > Role Mapping > New Rule to configure
role-mapping rules that map Pulse users to the role(s) you configured.
Related Understanding Client Connection Set Options on page 40

Documentation

 Installing the Pulse Secure Client on Windows Endpoints Using a Preconfiguration

File on page 54
 Installing the Pulse Secure Client on OS X Endpoints Using a Preconfiguration File

on page 59
Pulse Client Configuration Overview
This topic provides an overview of Pulse client configuration tasks. It includes the following
information:
 Deploying Pulse Client Software to Users on page 37

 Pulse Components on page 38
 Pulse Client Connections on page 39
 Default Configuration on page 40
Deploying Pulse Client Software to Users

One method of provisioning Pulse for users is assigning user roles. You can allow users
to download the client automatically by selecting Pulse as the agent option for a role.
The download occurs when the user connects to the Web portal for the access device.
You can transition users to the new client by configuring a new role that includes the
Pulse download, and then you can migrate users to the new role in a controlled
deployment.
To provision a custom Pulse package for users, you first configure a Pulse connection
set, which includes one or more connections. Each connection includes all the settings
that an endpoint needs to connect to a particular access device. Then you create a Pulse
component set, which allows you to choose the Pulse components to download to

endpoints. You can select a previously created client connection set profile to associate
with the client component set.
To assign a role, you either create a new role or select an existing role. Then you choose
a client component set for that role. When users provide valid credentials at the URL you
provide, the Pulse client is downloaded automatically.
Another method of enabling users to install the Pulse client is by creating an installer
package from the main Pulse Components page and distributing the installer to endpoints
through SMS.
Figure 4 on page 38 illustrates the process for deploying the client to users.
Figure 4: Configuration and Installation Overview
Be sure to instruct users to disable or uninstall OAC before installing Pulse. Pulse and
OAC can coexist on the same endpoint, but they cannot run simultaneously. Users can
disable OAC from the Windows Task Manager.
Pulse Components
Pulse components are individual software packages that provide the software services
and features of Pulse that are deployed to the endpoint. A component set is a bundle of
selected components. The components you select affect the size of the installation
package and affect the time it takes for a client to establish an connection to a new
device. For example, you deploy Pulse to an endpoint using an installation package that
includes only the components required for a connection to a Policy Secure gateway. If
a client that is using that package later connects to an SRX Series Firewall, the device
must download the Firewall connection and all of the components required for a
firewall connection to the client.
Pulse is designed to be lightweight, so you can download only the components that are
required for individual connections. For example, if a connection does not require IPsec,
you can omit the components for IPsec.
Endpoints can download individual components on demand as they encounter different

devices that require different components. When an endpoint attempts to connect to

a Policy Secure gateway or Connect Secure gateway, the connection set determines how
to make the connection. Example components include connectivity options for 802.1X
access, WX functionality, and Policy Secure gateway IPsec.
Pulse Client Connections

You can define the connections and connection methods that are stored on a user’s
endpoint. You configure client settings on the Policy Secure or Connect Secure gateway,
and then distribute the connection options to users through the client installation or
connection. The client settings are text files that reside on the client computer.
Each time the client accesses a different device, the client settings that are configured
for that device may overwrite the files from any previous connections.
You configure client settings when you configure a client connection set.
Client settings include the following types of persistent data:
 Connections—A connection contains a connection-policy that controls when the

connection is made. For example, you can configure the client to connect automatically
at user login or manually when the user initiates the connection. Connections are not
user-specific. There is only one set of connections per client computer. All users of the
same client computer share the same set of connections.
 Connection set options—Connection set options are independent of connections.

Connection set options govern the operation of the Pulse client as a whole. They control
whether or not the client is provisioned with specific features that are used each time
a connection is made. You can enable or disable the following options:
 Allow saving logon information—Enables the Save settings check box in the certificate
trust and password prompts.
 Allow user connections—Enables the user to manually define new connections

instead of relying on connections provided from a server.
 Display Splash Screen—Controls whether the splash screen is displayed when Pulse
starts.
 Dynamic certificate trust—Controls whether users can choose to trust unknown

certificates.
 Dynamic connections—Allows a client to add a new connection when it connects

to a new supported access device.
 Wireless suppression—Automatically suppresses wireless operations on the client

computer when it connects to a wired connection, for example, when a laptop is
inserted into a docking station.
Pulse also retains learned user settings, which include user information such as passwords,
realms, and role assignments. Learned user settings are not configured by administrators.
These settings are retained securely on the endpoint, evolving as the user connects
through different devices and methods. Learned user settings are utilized by the Pulse
client to retain values entered by users. A user can enable a Save Setting check box to
have Pulse retain responses to login prompts.

The Pulse client can save the following settings:
 Certificate acceptance
 Certificate selection
 Realm
 Username and password
 Proxy username and password
 Secondary username and password
 Role
NOTE: When a user saves settings, that information is used for each
subsequent connection without prompting. If a user changes their password,
the saved setting becomes invalid and the connection attempt will fail. In
this case, the user must use the Pulse client’s Forget Saved Settings feature.
The Forget Saved Settings feature clears the saved settings and enables
prompting.
Default Configuration
Policy Secure and Connect Secure gateways include a default client connection set and
client component set. You can provision Pulse to users with the default values without
actively creating new connection sets or component sets. The default settings for the
client permit dynamic connections, installs only the components required for the
connection, and permit an automatic connection to the Policy Secure gateway or
Connect Secure gateway to which the endpoint connects.
Related Understanding Deployments with Pulse Secure Clients on page 34

Documentation

Understanding Client Connection Set Options
A client connection set contains general network access options, and allows you to
configure specific connection policies for client access to any access device that supports
Pulse. Table 7 on page 40 details the available options for a connection set.
Table 7: Configurable Parameters for Pulse Connection Sets

Options:

Table 7: Configurable Parameters for Pulse Connection Sets (continued)

Allow saving logon information—Controls whether the Save Settings check
box is available in logon credential dialog boxes in the Pulse client. If you clear
this check box, the Pulse client will always require users to provide their logon
credentials. If you enable this check box, users have the option of saving their
credentials.
Allow user connections—Controls whether users can add connections.
Display Splash Screen—Clear this check box to hide the Pulse splash screen
that normally appears when the Pulse client starts.
Dynamic certificate trust—Determines whether or not users can opt to trust

unknown certificates. If you enable this check box, a user can ignore warnings
about invalid certificates and connect to the target device.
Dynamic connections—Allows connections within this connection set to be

automatically updated or added to a Pulse Secure client when the user
connects to the Pulse server through the user Web portal. Dynamic
connections are created as manual rather than automatic connections,
which means that they are run only when the user initiates the connection or
the user browses to a Pulse Server and launches Pulse from the server’s Web
interface.
Wireless suppression—Disables wireless access when a wired connection is

available.
NOTE: If you enable wireless suppression, be sure to also configure a

connection that enables the client to connect through a wired connection.
When you create a connection for a connection set, you choose a connection type. The following
lists the options available for each connection type:
UAC 802.1X options:


Use the UAC Adapter type—Specifies the type of adapter to use for authentication: wired
802.1X or wireless.
connection type
to define
Outer username—Enables users to appear to log in anonymously while passing
authenticated
the actual login name (called the inner identity) through an encrypted tunnel.
connectivity to
As a result, the user’s credentials are secure from eavesdropping and the user’s
802.1X devices,
inner identity is protected. As a general rule enter anonymous, which is the
wired or wireless.
default value. In some cases, you may need to add additional text. For example,
Users cannot
if the outer identity is used to route the user’s authentication to the proper
create 802.1X
server, you may be required to use a format such as anonymous@acme.com.
connections
If you leave the box blank, the client passes the user’s login name (inner
from the Pulse
identity) as the outer identity.
client interface.
Users see 802.1X
connections in Scan list—If you selected wireless as the adapter type, the scan list box is
the Pulse available to specify the SSIDs to connect to in priority order.
interface only
when the
connection has
been deployed
from the server
and the specified
network is
available.
Support Non-Broadcast SSID—This option allows users to connect to a

non-broadcast wireless network from within the Pulse interface.
Trusted Server List for 802.1X Connection:
Server certificate DN—Specify the server certificate distinguished name (DN)

and its signing certificate authority (CA). An empty DN field allows a client to
accept any server certificate signed by the selected CA.
SSL VPN or UAC (L3) options:
Allow user to override connection policy—Allows a user to override the

connection policy by manually connecting or disconnecting. Typically, you
leave this option selected to make sure that a user can establish a connection
under all conditions. If you disable this check box, the user cannot change the
endpoint’s connection status, suspend/resume a connection, or shut down
Pulse Secure client.
Enable Pulse Collaboration integration on this connection—This option must

be disabled if this connection is for Pulse Policy Secure. If the connection is
for Pulse Connect Secure, you can enable this check box and use the
connection for accessing Pulse Collaboration meetings.
This server—Specifies whether you want the endpoint to connect to this

device.
URL—Allows you to specify a URL for a different device as the default

connection. You would specify a different server’s URL if you were creating
connections for other access devices in the network.


SRX options (for Dynamic VPN):
Address—Specifies the IP address of the SRX device.
Allow user to override connection policy—Allows users to override the

connection policy by manually connecting or disconnecting.
App Acceleration options:
Allow user to override connection policy—Allows a user to override the

connection policy by manually connecting or disconnecting. Typically, you
leave this option selected to make sure that a user can establish a connection
under all conditions. If you disable this check box, the user cannot change the
endpoint’s connection status or shut down Pulse Secure client.
Community string—The Pulse Secure client and the Junos Pulse Application
Acceleration Service can form an adjacency for application acceleration only
if they belong to the same community as identified by the community string.
When you create an App Acceleration connection, be sure the community
string for the connection matches the community string defined on the Pulse
Application Acceleration Service.
Connection is established:
For all connection types, specify how the connection is established. The options vary according
to the type of connection. Connections can be established using the following options:
Manually by the user—When the endpoint is started, the Pulse client software
is started, but no connection is attempted. The user must use the Pulse client
interface to select a connection.
Automatically after user signs into the desktop—When the endpoint is started
and the user has logged in to the endpoint, the Pulse Secure client software
connects automatically. For App Acceleration connections, automatic
connection is the default because Pulse forms an adjacency with Pulse
Application Acceleration Service automatically if the service is available.
NOTE: All connections on an endpoint that are configured to start

automatically attempt to connect to their target networks at startup time. To
avoid multiple connection attempts, be sure that only one connection is
configured to start automatically or configure location awareness rules.
Automatically when the machine starts. Machine credentials used for

authentication—Enables machine authentication, which requires that Active
Directory is used as the authentication server and that machine credentials
are configured in Active Directory.


Automatically when the machine starts. Connection is authenticated again
when the user signs in into the desktop—Enables machine authentication
for the initial connection. After the user connects with user credentials, the
machine authentication is dropped. When the user logs off, the machine
authentication connection is restored.
NOTE: If the machine and user have different roles, each role should map to
the same connection set. Otherwise after the user connects, the existing
connection set might be replaced.
Automatically at user login—This option enables Pulse client interaction with

the credential provider software on the endpoint. The user credentials are
used to establish the authenticated Pulse connection to the network, login
to the endpoint, and login to the domain server.
NOTE: This label changed at Pulse Policy Secure R4.3. If you had selected
the old label for a Pulse connection, Automatically during desktop
authentication. User is presented with the Pulse Secure credential tile at the logon
screen, it is automatically converted to the new label, Automatically at user
login when you perform the upgrade from R4.2.
Automatically when the machine starts. Connection is authenticated again

at user login—This option enables Pulse client interaction with the credential
provider software on the endpoint. Machine credentials are used to establish
the authenticated Pulse connection to the network. When the user provides
user credentials, the connection is authenticated again. In one typical use
case, the machine credentials provide access to one VLAN and the user
credentials provide access to a different VLAN.
Location awareness rules:


For SSL VPN or UAC (L3) and SRX connections that are set to have the
connection established automatically, you can define location awareness
rules that enable an endpoint to connect conditionally. For example, the
endpoint connects to Pulse Policy Secure if it is connected to the company
intranet or it connects to Pulse Connect Secure if it is in a remote location.
A Pulse connection uses the IP address of a specified interface on the endpoint

to determine its network location. Each location awareness rule includes the
following settings:
 Name—A descriptive name, for example, “corporate-DNS.” A name can

include letters, numbers, hyphens, and underscores.
 Action—The method the connection uses to discover the IP address. Choose
one of the following values:
 DNS Server—Allows the endpoint to connect if the endpoint’s DNS server
on the specified interface is set to one of the specified values. Use the
Condition box to specify IP addresses or address ranges.
 Resolve Address—Allows the endpoint to connect if the hostname
specified in the DNS Name box can be resolved by the DNS server for the
specified interface. If one or more address ranges are specified in the
Address Range box, the address must resolve to one of the ranges to
satisfy the expression.
 Endpoint Address—Allows the endpoint to connect if the IP address of
the specified interface is within a range specified in the IP Address Range
box.
NOTE: To create a negative location awareness rule, you first create the
positive state and then use rule requirement logic to use the rule as a negative
condition.
Machine Connection Preferences:
The Machine Connection Preferences appear if you have selected one of the
machine authentication options for how the connection is established.
Normally Pulse presents a selection dialog box if more than one realm or role
available to the user. However, a connection that is established through
machine authentication fails if a dialog box is presented during the connection
process. To suppress the selection dialogs, either ensure that only one role
and realm is available to users or specify a preferred realm and role for this
connection.
 Preferred Machine Realm—Specify the realm that this connection uses

when establishing the machine connection. The connection ignores any
other realm available for the specified logon credentials
 Preferred Machine Role Set—Specify the role or the name of rule for the
role set that this connection uses when establishing the machine connection.
The role or rule name used must be a member of the preferred machine
realm.
User Connection Preferences:


The User Connection Preferences options enable you to specify a realm and
role for automatic connections that would otherwise present a selection dialog
box to the user. To suppress the selection dialogs, either ensure that only one
role and realm is available to users or specify a preferred realm and role for
this connection.
 Preferred User Realm—Specify the realm that for this connection that is
used when a user logs onto the endpoint. The connection ignores any other
realm available for the user’s logon credentials
 Preferred User Role Set—Specify the preferred role or the name of rule for
the role set to be used for user authentication. The role or rule name used
must be a member of the preferred user realm.
 Select client certificate from machine certificate store—This option
enables you to specify the location of the client certificate on a Windows
endpoint as part of a Pulse connection that verifies the identity of both the
machine and the user before establishing a connection. When this check
box is selected, the Pulse connection looks at client certificates located in
the Local Computer personal certificate store. When this check box is not
selected, the connection accesses the user certificate store an a Windows
endpoint. For more information, see “Machine and User Authentication
Through a Pulse Connection for Pulse Policy Secure” on page 66
Related Creating a Client Connection Set on page 46

Documentation

 Configuring Location Awareness Rules on page 49
on page 66

Creating a Client Connection Set
To create a client configuration:
1. On the admin console, select Users > Junos Pulse > Connections.
2. Click New.
3. Enter a name, and optionally a description for this connection set.
NOTE: You must enter a name, otherwise you cannot create a connection
set.
4. Under Options, select or clear following check boxes:
 Allow saving logon information
 Allow user connections
 Display Splash Screen

 Dynamic certificate trust
 Dynamic connections
 Wireless suppression
5. Under Connections, click New to define a new connection.
6. Enter a name and an optionally a description for this connection.
7. Select a Type for the connection. The Type identifies the device type for the
connections and can be any of the following:
 UAC (802.1X)
 SSL VPN or UAC (L3)
 SRX
 App Acceleration
8. If you select UAC (802.1X) on the type list, either enter a value or select or clear the
following check boxes:
 Adapter type
 Outer username—Enter the outer username.
 Scan list—Enter the SSIDs to connect to in your order of priority.
 Support Non-Broadcast SSID
10. If you select SSL VPN or UAC (L3) after Options, select or clear the following check
boxes:
 Allow user to override connection policy
 Support Remote Access (SSL VPN) or LAN Access (UAC) on this connection
 Enable Pulse Collaboration integration on this connection
 This Server—This connection uses the URL of the server where you are creating the
connection.
 URL—If you did not select the This Server check box, you must specify the URL of
the server for the connection.
11. If you select SRX, enter an IP address in the Address box.
12. From the Options list, specify the following:
 Address
13. If you select App Acceleration, specify the following options: select the Connect
Automatically check box to permit the client to automatically connect to WX in the
network.

 Community string
14. For all connections, specify how the connection is established. Depending on the
connection, select one of the following:
 Manually by the user—When the endpoint is started, the Pulse client software is
started, but no connection is attempted. The user must use the Pulse client interface
to select a connection.
 Automatically after user signs into the desktop—When the endpoint is started and
the user has logged in to the endpoint, the Pulse Secure client software connects
automatically. For App Acceleration connections, automatic connection is the
default because Pulse forms an adjacency with Pulse Application Acceleration
Service automatically if the service is available.
NOTE: All connections on an endpoint that are configured to start

automatically attempt to connect to their target networks at startup
time. To avoid multiple connection attempts, be sure that only one
connection is configured to start automatically or configure location
awareness rules.
 Automatically when the machine starts. Machine credentials used for

authentication—Enablesmachine authentication, which requires thatActive Directory
is used as the authentication server and that machine credentials are configured in
Active Directory.
 Automatically when the machine starts. Connection is authenticated again when the
user signs in into the desktop—Enables machine authentication for the initial
connection. After the user connects with user credentials, the machine authentication
is dropped. When the user logs off, the machine authentication connection is
restored.
NOTE: If the machine and user have different roles, each role should
map to the same connection set. Otherwise after the user connects, the
existing connection set might be replaced.
 Automatically at user login—This option enables Pulse client interaction with the
credential provider software on the endpoint. The user credentials are used to
establish the authenticated Pulse connection to the network, login to the endpoint,
and login to the domain server.

NOTE: This label changed at Pulse Policy Secure R4.3. If you had
selected the old label for a Pulse connection, Automatically during
desktop authentication. User is presented with the Pulse Secure
credential tile at the logon screen. It is automatically converted to the
new label at user login when you perform the upgrade from R4.2.
15. After you create the client connection set, create a client component set profile, and
select this connection set.

Documentation

 Configuring Location Awareness Rules on page 49
Configuring Location Awareness Rules
The location awareness feature enables a Pulse Secure client to recognize its location
and then make the correct connection when the connection is set to connect
automatically. For example, a Pulse client that is started in a remote location
automatically connects to Pulse Connect Secure. But that same client automatically
connects to Pulse Policy Secure when it is started in the corporate office.
NOTE: Location awareness and session migration are similar because they
both simplify connectivity for the user, but they do so under different
conditions. With location awareness, the Pulse client makes a decision on
where to connect when a user logs in to the computer. Session migration
occurs when the user puts the computer into a stand by or hibernate mode
without first logging out, and then opens the computer in a different network
environment. Location awareness enables the Pulse client to intelligently
start a new session. Session migration enables Pulse servers to intelligently
migrate an existing session.
Location awareness relies on rules you define for each connection. If the conditions
specified in the rules are true, Pulse attempts to make the connection. To set up the
location awareness rules that select among many connections, you must define location
awareness rules for each connection. Each location awareness rule is based on the
endpoint’s ability to reach an IP address or resolve a DNS name over a specified network
interface.

NOTE: Location awareness behavior is affected by split tunneling

configuration. For example, if a location awareness rule relies on a address
resolution made on the physical adapter, and split tunneling is disabled, the
rule always resolves to FALSE after Pulse establishes the connection.
The following location awareness example includes two connections. The first connection
is a Pulse Policy Secure connection that resolves to TRUE when the endpoint is
connected to the corporate LAN. The second connection is Pulse Connect Secure
connection that resolves to TRUE when the endpoint is located in a remote location.
Pulse Policy Secure connection
If the DNS server that is reachable on the endpoint’s physical network

interface is one of your organization’s internal DNS servers, then
establish the connection.
Pulse Connect Secure connection
If the DNS server that is reachable on the endpoint’s physical network

interface is not one of your organization’s internal DNS servers, and the
DNS name of your Pulse Connect Secure device resolves to the external
facing IP address of the Pulse Connect Secure device, then establish the
connection.
NOTE: Connections can be set to manual, automatic, or controlled by location

awareness rules. When the user logs in, the Pulse client attempts every
connection in its connections list that is set to automatic or controlled by
location awareness rules.
NOTE: To create a negative location awareness rule, you first create the
positive state and then use rule requirement logic to use the rule as a negative
condition.
To configure location awareness rules:
1. If you have not already done so, create a connection or open an existing connection.
You can configure location awareness rules for Firewall connections and IC or SA
connections. Location awareness rules do not apply to 802.1X or App Acceleration
connections.
2. In the Connection is established area, select According to location awareness rules,

and then click New.
3. Specify a name for the rule.
4. In the Action list, select one of the following:

 DNS server—Connect if the DNS server associated with the endpoint's network
properties is (or is not) set to a certain value or set of values. Specify the DNS server
IP address in the IP address box. Also specify a network interface on which the
condition must be satisfied:
 Physical—The condition must be satisfied on the physical interfaces on the

endpoint.
 Pulse Secure—The condition must be satisfied on the virtual interface that

Pulse Secure creates when it establishes a connection.
 Any—Use any interface.
 Resolve address—Connect if the configured hostname or set of hostnames is (or is

not) resolvable by the endpoint to a particular IP address. Specify the hostname in
the DNS name box and the IP address or addresses in the IP address box. Also
specify a network interface on which the condition must be satisfied.
NOTE: The Pulse client software evaluates IP and DNS policies on

network interface changes. DNS lookups occur on DNS configuration
changes or when the time-to-live setting (10 minutes) expires for a
particular host record. If Pulse cannot resolve the host for any reason,
it polls the configured DNS server list every 30 seconds. If the host had
been resolved successfully previously and the time-to-live timer has
not expired, the polling continues until the timer expires. If the host had
not been resolved successfully previously, the resolution attempt fails
immediately.
 Endpoint Address—Connect if a network adapter on the endpoint has an IP address

that falls within or outside of a range or a set of ranges. Specify the IP address or
addresses in the IP address box. Also specify a network interface on which the
condition must be satisfied.
After you create the rule or rules, you must enable each rule you want to use for the
connection. To enable a negative form of a rule, use a custom version of the rule. To
enable location awareness rules:
1. In the list of connection awareness rules for a connection, select the check box next
to each rule you want to enable.
2. To specify how to enforce the selected location awareness rules, select one of the
following options:
 All of the above rules—The condition is TRUE and the connection is attempted only
when all selected location awareness rules are satisfied.
 Any of the above rules—The condition is TRUE and the connection is attempted
when any select location awareness rule is satisfied.
 Custom—The condition is TRUE and the connection is attempted only when all
selected location awareness rules are satisfied according to the Boolean logic you

specify in the Custom box. Use the Boolean condition to specify a negative location
rule. For example, connect to Pulse Connect Secure when Rule–1 is false and Rule–
2 is true. The boolean logic in the custom box would be: NOT Rule-1 AND
Rule-2. The accepted Boolean operators are AND, OR, NOT, and the use of ( ).
Related Understanding Session Migration on page 255

Documentation

Understanding Pulse Component Set Options
A Pulse component set includes individual software components that provide Pulse
connectivity and services.
Component set options include the following choices:
 All components—Includes the components listed in Table 8 on page 52. The Enhanced
Endpoint Security (EES) component, which is available only if you have purchased an
EES license, is included if the user’s assigned role requires it. You should choose the
All components option only if you want client endpoints to be able to connect to all
supported access devices and to use WAN acceleration (WX). When you include the
WX component, the disk space requirement for the Pulse client installation increases
to 300 MB.
 No components—You should select this option to create an installer that only updates
existing Pulse client installations, for example, to add a new connection. Do not use
this option if you are creating an installer to add Pulse to endpoints that do not already
have Pulse installed.
 Minimal components—Includes only the components needed to support the selected

connections. For example, if the connection set you create includes a connection to
an IC device, the component set will include only the components required to connect
to IC devices. Minimal components is the default choice. It provides all needed
components while also limiting the size of the Pulse installation file.
For a list of all components see Table 8 on page 52.
Table 8: Pulse Components
Components Description
Core functions Allows the client to download a minimal component set and install
on endpoints.
802.1X access Includes the required components for 802.1X connections. The client
interacts with the native wired and wireless 802.1X supplicant on the
client PC.
IC or SA access Provides basic functionality that allows Pulse to interoperate with

Policy Secure or Connect Secure gateways.

Table 8: Pulse Components (continued)
Components Description
Firewall access Provides basic functionality that allows Pulse to operate as a dynamic
VPN client with Juniper Networks J Series firewalls.
WX functionality Facilitates using the client with Pulse Application Acceleration Service
for WAN acceleration.
Host Checker Includes the Trusted Network Computing (TNC) client that allows IC
or SA connections to run and enforce Host Checker policies. This
component provides support for all existing host checks on Windows
machines.
Enhanced Endpoint Allows IC and SA to use the integrated EES antimalware software.
Security
IC IPsec Allows the client to use IPsec as a communication method with the
Policy Secure gateway when a Juniper Networks security device is
employed.
SSL-VPN Facilitates SSL connections with the Pulse Connect Secure.
Related Creating a Client Component Set on page 53

Documentation

Creating a Client Component Set
To create a client component set:
1. On the admin console, select Users > Junos Pulse > Components.
2. Click New to create a new component set.
3. If you have not yet created a client connection set, select Users > Junos Pulse >
Connections and create a new connection set. Alternately, use the default client
configuration, which permits dynamic connections, supports the outer username
anonymous, and allows the client to connect automatically to a Policy Secure or
Connect Secure gateway.
4. Specify a Name for the client component set.
5. (Optional) Enter a Description for this client component set.
6. Select a connection set that you have created, or use the default connection set.
7. For Pulse client components, select one of the following option buttons:
 All components—The installer contains all Pulse components, supporting all access
methods and all features.
 No components—The preconfigured installer is a configuration update, and only

works on endpoints that already have the Pulse Secure client installed.

 Minimal components—The configuration is analyzed, and only the access methods

needed to support the connections in the configuration (along with Pulse core
components) are included in the installer. Additional components such as IPsec or
Host Checker are downloaded as needed at run time and are not part of the installer.
9. After you create a component set, distribute the client to users through one of the
following methods:
a. Return to the main Pulse Client Components page to download and install the
preconfiguration utility and create an installer package.
b. Distribute to users through a role.
When users access the role, the installer downloads automatically to the endpoint.
The installer components and connections are applied to the endpoint client.
If client connections associated with the component set for a role are changed,
even though the list of components has not, the existing configuration on the
endpoint is replaced. This occurs either right away (if the endpoint is currently
connected), or the next time the endpoint connects.
If a user is assigned to multiple roles and the roles include different component
sets, the first role in an endpoint’s list of roles is the role that determines which
client (component set) is deployed.

Documentation

Installing the Pulse Secure Client on Windows Endpoints Using a Preconfiguration

File
The following procedures apply to Windows installations only.
After you create client connection sets and specify the connections to include within a
client component set, you can create a preconfiguration file with all of the connections
you want to distribute with the Pulse client. You specify the preconfiguration file as an
option when you run the Pulse MSI installer program using an msiexec
(windows\system32\msiexec.exe) command.
To create a preconfigured Pulse installer for distribution to Windows endpoints:
1. Select Users > Junos Pulse > Connections and create a connection set with the
connections that you want to distribute.
2. Select Users > Junos Pulse > Components.
3. If necessary, create a new component set with the connection sets you want to
distribute.

It does not matter which component option you select, All components, No
components, or Minimal components. The Pulse installer installs all components
unless you specify which components to install using one or more ADDLOCAL options
in the command line. If you specify one or more ADDLOCAL options, the installer
installs only the components you specify. Be sure that you specify all the components
required to support the connections you have selected.
4. Select the check boxes next to the component sets that you want to distribute.
5. Click Download Installer Configuration.
You are prompted to save the preconfiguration. You can also specify the name of the
target Pulse server for the connections, which enables you to create configuration
files that are the same except for the target server.
The default filename of the .jnprpreconfig file is the name of the selected component
set. Make note of the filename and location where you put the file. The preconfiguration
file must be available to the clients either through a network share or distributed along
with the Pulse Secure client installation file.
6. Select Maintenance > System > Installers.
If necessary for your environment, download and install the Juniper Installer Service.
To install Pulse, users must have appropriate privileges. The Juniper Installer Service
allows you to bypass privilege restrictions and allow users with limited privileges to
install Pulse. See “Downloading Client Installer Files” on page 708 for more information
about Juniper Installer Service.
7. Download the appropriate Pulse Secure installer for your Windows environment:
 Pulse Secure Installer (32-bit)
 Pulse Secure Installer (64-bit)
NOTE: For a Windows installation (.msi) that uses an automated distribution

mechanism and where the users do not have administrator privileges, you
should ensure that the installation is run in the proper context, typically the
USER context. To install in USER context, first advertise the .msi while in the
SYSTEM context. For example, to advertise the 64-bit Windows installation
to all users, use the following msiexec command:
msiexec /jm \JunosPulse.x64.msi
The advertisement allows the installation to be run in USER context even if
the user is a restricted (non-admin) user. The location where the
advertisement is run and where the actual installation is run must be the
same. If the installation is an upgrade, you must advertise the upgrade version
before running it. (Note that it is much easier to upgrade the Pulse client by
not disabling the automatic upgrade feature on the Pulse server.) After the
installation is run by the user, the Pulse client will use the correct user
certificate and context.

Installing the Pulse Client Using Advanced Command-Line Options

The Pulse Secure installer includes the Pulse client and all the software components for
all the Pulse services. The preconfiguration file contains the definitions of the Pulse
connections that provide client access to specific Pulse servers and services.
Usage Notes:
 The preconfigured installer installs all Pulse components unless you specify the specific
components you want using ADDLOCAL options. If you use one or more ADDLOCAL
options, the preconfigured installer installs only the components specified by
ADDLOCAL. A preconfigured installer ignores the component set you select when you
create the preconfiguration file.
 When you use ADDLOCAL options, be sure that your msiexec command specifies all
the components required for your connections. For example, if the connection requires
802.1X connectivity for a connection to Pulse Policy Secure, be sure to include both
the 802.1X component and the Pulse Policy Secure component
(ADDLOCAL=PulseUAC,Pulse8021x).
 When you run msiexec, you should append /qn or /qb (msiexec options) to the
command line to suppress the installation program user interface. For example, the
user interface lets the user choose a complete installation or a custom installation,
which can override the components you specify with ADDLOCAL options. If the user
selects Complete, the msiexec program ignores the ADDLOCAL options in the command
line and installs all components. The /qn option specifies a silent install, so no user
interface appears. The /qb option also hides the user interface but it displays a progress
bar.
 The procedures in this topic are valid with Windows installations only. For information
about installing Pulse on OS X endpoints, see “Installing the Pulse Secure Client on OS
X Endpoints Using a Preconfiguration File” on page 59.
You run the Pulse preconfigured installer program with msiexec (the command line for
launching .msi programs on Windows platforms) and specify the following options.
NOTE: Command line options (CONFIGFILE and ADDLOCAL) are case

sensitive and must be all caps.
NOTE: If the path to the .jnprpreconfig file includes spaces, be sure to use
quotes around the path.
 CONFIGFILE—This property specifies a configuration file to be imported into Pulse

during installation. The property must include the full path to the configuration file. For
example:
msiexec -i JunosPulse.msi CONFIGFILE="c:\temp\my configuration.jnprpreconfig"

 ADDLOCAL—This optional property specifies which features and feature options

(subfeatures) to install when you want to install only specific Pulse features. If you do
not specify ADDLOCAL options, all Pulse components are installed. A feature comprises
the components required to support client connections. When you use ADDLOCAL,
you should append msiexec options /qn or /qb to the command line to suppress the
installation program user interface.
Feature and subfeature names are case sensitive. To specify multiple features in a
single command, separate each feature with a comma.
The ADDLOCAL property has the following features:
 PulseSA—Pulse components required for Pulse Connect Secure.
 PulseUAC—Pulse components required for Pulse Policy Secure.
 PulseSRX—Pulse components required for SRX Series Gateways.
 PulseAppAccel—Pulse components required for Pulse Application Acceleration

Service.
The ADDLOCAL property has the following optional subfeatures:
 Pulse8021x—Available with PulseUAC. Includes 802.1X connectivity components.
 SAEndpointDefense—Available with PulseSA. Includes Enhanced Endpoint Security

(EES) components for connections to Pulse Connect Secure.
 SAHostChecker—Available with PulseSA. Includes Host Checker components for

connections to Pulse Connect Secure.
 UACEndpointDefense—Available with PulseUAC. Includes EES components for

connections to Pulse Policy Secure.
 UACHostChecker—Available with PulseUAC. Includes Host Checker components

for connections to Pulse Policy Secure.
 UACIPSec—Available with PulseUAC. Includes components required to connect

to Pulse Policy Secure using IPSec from 32-bit Windows endpoints. This feature
is available in the 32-bit MSI only.
 UACIPSec64—Available with PulseUAC. Includes components required to connect

to Pulse Policy Secure using IPsec from 64-bit Windows endpoints. This feature
is available in the 64-bit MSI only.
Examples
When you use ADDLOCAL, you should append msiexec options /qn or /qb to the command
line to suppress the installation program user interface. These examples use /qb.
To install PulseUAC with 802.1X and EES support on a Windows 32-bit endpoint using
a configuration file:
msiexec -i JunosPulse.x86.msi CONFIGFILE=c:\pulse\Pulse-Connection-no.jnprpreconfig

ADDLOCAL=PulseUAC,Pulse8021x,UACEndpointDefense /qb

To install PulseSA on a 32-bit Windows endpoint using a configuration file:
msiexec -i JunosPulse.x86.msi CONFIGFILE="c:\temp\myconfiguration.jnprpreconfig"

ADDLOCAL=PulseSA /qb
To install PulseSA with EES and Host Checker on a 64-bit Windows endpoint using a
configuration file:

ADDLOCAL=PulseSA,SAEndpointDefense,SAHostChecker /qb
To install PulseAppAccel on a 64-bit Windows endpoint using a configuration file:

ADDLOCAL=PulseAppAccel /qb
To install all Pulse components on a 64-bit Windows endpoint using a configuration file:

/qb
Repairing a Pulse Installation on a Windows Endpoint

Pulse Secure client uses an MSI installer, which supports a repair function. If problems
with Pulse on a Windows endpoint indicate missing or damaged files or registry
settings, the user can easily run the installation repair program. The repair program
performs a reinstallation and replaces any missing files. The repair program does not
install any files that were not part of the original installation. For example, if the file
that holds Pulse connection configurations is damaged, the file installed by the repair
program does not replace any Pulse connections that were created by the user or
deployed to the endpoint after the original Pulse installation.
To repair a Pulse installation on a Windows endpoint:
1. On the Windows endpoint where Pulse is installed, click Start > Programs > Juniper
Networks > Junos Pulse > Repair Junos Pulse.
2. Follow the prompts for the installation wizard.
When the program is finished, you might be prompted to reboot the system.
Related Installing the Pulse Secure Client on OS X Endpoints Using a Preconfiguration File
Documentation on page 59

Installing the Pulse Secure Client on OS X Endpoints Using a Preconfiguration File
The following procedures apply to OS X installations only.
After you create client connection sets and specify the connections to include within a
client component set, you can create a preconfiguration file with all the connections you
want to distribute with the Pulse client. After you run the Pulse installer on the endpoint,
you run a special command that imports the settings from the preconfiguration file into
Pulse.
To create a preconfigured Pulse installer for distribution to OS X endpoints:
1. Select Users > Junos Pulse > Connections and create a connection set with the
connections that you want to distribute.
2. Select Users > Junos Pulse > Components.
3. If necessary, create a new component set with the connection sets you want to
distribute.
It does not matter which component option you select, All components, No
components, or Minimal components. The Pulse installation program for OS X always
installs all components.
4. Select the check boxes next to the component sets that you want to distribute.
5. Click Download Installer Configuration.
You are prompted to save the preconfiguration. You can also specify the name of the
target Pulse server for the connections, which enables you to quickly create multiple
configuration files that are the same except for the target server.
The default filename of the .jnprpreconfig file is the name of the selected component
set. Make note of the filename and location where you put the file. The preconfiguration
file must be available to the clients either through a network share or distributed along
with the Pulse Secure installer file.
6. Select Maintenance > System > Installers.
7. Download the Pulse Secure installer, Pulse Secure Installer (Macintosh).
Installing the Pulse Client on OS X Endpoints Using Command-Line Options

The Pulse Secure installer includes the Pulse client and all of the software components
for all of the Pulse services. The preconfiguration (.jnprpreconfig) file contains the
definitions of the Pulse connections that provide client access to specific Pulse servers
and services. After you distribute the Pulse installation package, you must first run the
installer, and then run a separate program called jamCommand, which imports the
settings from the .jnprpreconfig file. The jamCommand program is part of the Pulse
installation.
The Pulse file you download from the Pulse server is in compressed (.dmg) format. You
must unpack the file before you run the Pulse installation program.

The following steps include sample commands to install Pulse on an OS X endpoint and
then import Pulse connections from a .jnprpreconfig file.
1. Run the Pulse installation program:
sudo /usr/sbin/installer -pkg <full-path-to-the-pulse-install-package> -target /
2. Import the settings from the .jnprpreconfig file:
/Applications/Junos\ Pulse.app/Contents/Plugins/JamUI/jamCommand –importFIle

<full-path-to-the-jnprpreconfig-file>
Related Installing the Pulse Secure Client on Windows Endpoints Using a Preconfiguration File
  jamCommand Reference
Pulse Secure Command-line Launcher
The Pulse Secure Launcher (pulselauncher.exe) is a standalone client-side command-

line utility that allows you to launch Pulse and connect to or disconnect from a Pulse
server (Pulse Connect Secure or Pulse Policy Secure) without displaying the Pulse
graphical user interface.
Pulse Launcher Usage Notes:
 Pulse Launcher runs on 32-bit and 64-bit endpoints.
 Pulse Launcher runs on the following platforms:
 Windows XP
 Windows Vista
 Windows 7
 The Pulse Launcher program, pulselauncher.exe, is installed as part of a Pulse client

installation in Program Files\Common Files\Juniper Networks\Integration.
 Pulse Launcher works only for the SA or IC connection type. The Pulse launcher does
not support the Firewall or 802.1X connection types.
 The Pulse Launcher program does not support the role mapping option that prompts
a user to select from a list of assigned roles. If you use the Pulse Launcher and more
than one role can be assigned to a user, you must configure the role mapping settings
for the realm to merge settings for all assigned roles. If the realm settings require the
user to select a role, the Pulse Launcher command fails and exits with return code 2.
 The Pulse Launcher program does not support secondary authentication.
To use the Pulse Launcher program:
1. Write a script, batch file, or application.
2. Include a call to the Pulse Launcher executable, pulselauncher.exe.

3. Include logic in your script, batch file, or application to handle the possible return
codes.
Table 10 on page 62 lists the Pulse Launcher return codes.
The following command shows the complete pulselauncher.exe command syntax:

pulselauncher.exe [-version|-help|-stop] [-url <url> -u <user> -p <password> -r
<realm>] [-d <DSID> -url <url>] [-cert <client certificate> -url <url> -r <realm>]
[-signout -url <url>] [-t timeout]
Table 9: Pulse Launcher Arguments
Argument Action
-version Display the Pulse Launcher version information, then exit.
-help Display available arguments information.
-stop Stop Pulse and disconnect all active connections.
-url <url> Specify the Pulse server URL.
-u <user> Specify the username.
-p <password. Specify the password for authentication.
-r <realm> Specify the realm on the Pulse server.
-d <DSID> Passes a cookie to Pulse Launcher for a specified Pulse server from another authentication
mechanism when Pulse Launcher starts. When you use the -d argument, you must also specify
the -url argument to specify the Pulse server.
-cert <client certificate> Specify the certificate to use for user authentication. For <client certificate> use the string
specified in the Issued To field of the certificate. When using the -cert argument, you must also
specify the -url and -r <realm> arguments.
To use certificate authentication with the Pulse Launcher program, you must first configure
the Pulse server to allow the user to sign in via user certificate authentication. You must also
configure a trusted client CA on the Pulse server and install the corresponding client-side
certificate in the Web browsers of end-users before running the Pulse Launcher.
If the certificate is invalid, the Pulse Launcher displays an error message on the command line
and logs a message in the log file.
NOTE: If Pulse is launched through a browser, the browser handles certificate verification. If
Pulse is launched through an application on Windows, the application handles certificate
verification. If Pulse is launched through the Pulse Launcher on Windows, Pulse Launcher
handles the expired or revoked client certificates.
-signout Disconnect and sign out from a specific server. Pulse can have multiple simultaneous
connections so the -url argument is required when you use the -signout argument.
-timeout <time in seconds> The amount of time allowed for the connection to take place before the attempt fails. Min =
45 (default), Max = 600.

The following table lists the possible return codes pulselauncher.exe returns when it
exits.
Table 10: Pulse Launcher Return Codes
Code Description
-1 Pulse is not running.
0 Success.
1 A parameter is invalid.
2 Connection has failed or Pulse is unable to connect to the specified gateway.
3 Connection established with error.
4 Connection does not exist. Example: the command attempts to sign out from a server that was
not which has not been added on Pulse UI.
5 User cancelled connection.
6 Client certificate error.
7 Timeout error.
8 No user connection allowed from Pulse UI.
9 No policy override from Pulse UI.
100 General error.
Examples
The following command is a simple login application that captures the credentials the
user enters, and passes the credentials as arguments to pulselauncher.exe:
pulselauncher.exe -u JDoe -p my$Pass84 -url https://int-company.portal.com/usr -r

Users
pulselauncher return code: 0
The following Pulse Launcher example shows a certificate authentication:
pulselauncher.exe -url https://int-company.portal.com/usr -cert MyCert -url

https://int-company.portal.com/usr -r Users
The following example shows a command to use Pulse Launcher to specify a cookie (-d)
for a specific Pulse server (-url):
pulselauncher.exe –d 12adf234nasu234 -url https://int-company.portal.com/usr


Related Using jamCommand to Import Pulse Secure Connections on page 63

Documentation
 jamCommand Reference

Using jamCommand to Import Pulse Secure Connections
The jamCommand.exe program is a command line program that imports a .jnprpreconfig

file into the Pulse client. The jamCommand program is available for Windows (XP, Vista,
and Win7) and Mac OSX.
NOTE: The working name for Pulse Secure client during the early
development phase was Juniper Access Manager. Many Pulse filenames,
directories, and other Pulse Secure elements include the acronym “jam.”
A .jnprpreconfig file includes Pulse connection parameters. You can create a .jnprpreconfig
file on the Pulse server, and then use it as part of a Pulse installation to ensure that Pulse
users have one or more Pulse connections when they start Pulse for the first time.
NOTE: One typical use case for jamCommand on a Windows endpoint is to

first run jamCommand to import one or more Pulse connections from a
.jnprpredong file, and then run pulselauncher.exe to start Pulse.
To install Pulse connections using jamCommand:
1. Create a .jnprpreconfig file on the Pulse server.
In the Pulse server admin console, click Users > Junos Pulse > Components.
2. Select the component sets you want, and then click Download Installer Configuration.
3. Distribute the .jnprpreconfig file to the Pulse endpoints.
4. Run jamCommand with the .jnprpreconfig file as an option. For example:
On Windows:
\Program Files\Common Files\Juniper Networks\JamUI\jamCommand -importfile

myfile.jnprpreconfig
On Mac OSX:
/Applications/Junos Pulse/Contents/Plugins/JamUI/jamCommand -importfile

myfile.jnprpreconfig
If the Pulse client is running when you run jamCommand, the new Pulse connection or
connections appear immediately. The connection name appears as it was defined when
you created the connection in the Pulse server admin console.
Related Pulse Secure Command-line Launcher on page 60

Documentation


 Installing the Pulse Secure Client on Windows Endpoints Using a Preconfiguration

File on page 54
 Installing the Pulse Secure Client on OS X Endpoints Using a Preconfiguration File

on page 59
 jamCommand Reference
Configuring Machine-Only Machine Authentication for a Pulse Secure Connection
When a Pulse connection is configured for machine-only machine authentication, the

Pulse connection is established using machine credentials when no user is logged in. The
connection is maintained after user login.
To enable a Pulse connection for machine-only machine authentication:
1. Click Users > Junos Pulse > Connections and create or select a connection set.
2. Create or edit a connection. For the connection type, you can select either UAC (802.1X)
for a Layer 2 connection or SSL VPN or UAC (L3) for a Layer 3 connection.
3. Under Connection is established, select Automatically when the machine starts. Machine
credentials used for authentication.
Machine credentials are used to connect to the Pulse Policy Secure when the
endpoint is started, before a user logs in. The connection is maintained when a
users logs in, logs out, or switches to a different login.
4. For a Layer 2 connection that uses machine certificate authentication, make sure that
the connection has an entry in the Trusted Server List. To allow any server certificate,
type ANY as the Server certificate DN. To allow only one server certificate, specify the
server certificate’s full DN, for example, C=US; ST=NH; L=Kingston; O=My Company;
OU=Engineering; CN=c4k1.stnh.mycompany.net; E=ausername@mycompany.com.
5. Specify Realm and Role Preferences to suppress realm or role selection dialogs during
the login process:
 Preferred Machine Realm—Specify the realm for this connection. The connection
ignores any other realm available for the specific login credentials
 Preferred Machine Role Set—Specify the preferred role or the name of the rule for
the role set to be used for user authentication. The role or rule name must be a
member of the preferred machine realm.
Related Machine Authentication for Pulse Policy Secure Overview on page 71

Documentation
 Credential Provider Authentication for Pulse Policy Secure Overview on

page 69


Configuring User-After-Desktop Machine Authentication for a Pulse Secure Connection
When a Pulse connection is configured for user-after-desktop machine authentication,

the connection is established using machine credentials when no user is logged in. After
user login, the machine connection is disconnected. Once the user logs out, user
connection is disconnected and machine connection is reestablished.
To enable a Pulse connection for user-after-desktop machine authentication:
1. Click Users > Junos Pulse > Connections, and then create or select a connection set.
2. Create or edit a connection. For the connection type, you can select either UAC (802.1X)
for a Layer 2 connection or SSL VPN or UAC (L3) for a Layer 3 connection.
3. Under Connection is established, select Automatically when the machine starts.

Connection is authenticated again when the user signs in to the desktop.
Machine credentials are used to connect to the Pulse Policy Secure when the
endpoint is started, before a user logs in. When a user logs in, the machine
authentication connection is dropped, and the user login is used instead. When the
user logs out, the machine connection is reestablished.
4. For a Layer 2 connection that uses machine certificate authentication, make sure that
the connection has an entry in the Trusted Server List. To allow any server certificate,
type ANY as the Server certificate DN. To allow only one server certificate, specify the
server certificate’s full DN, for example, C=US; ST=NH; L=Kingston; O=My Company;
OU=Engineering; CN=c4k1.stnh.mycompany.net; E=ausername@mycompany.com.
5. Specify Realm and Role Preferences to suppress realm or role selection dialogs during
the login process for both machine and user logins:
 Preferred Machine Realm—Specify the realm that this connection uses when
establishing the machine connection. The connection ignores any other realm
available for the specific login credentials
 Preferred Machine Role Set—Specify the role or the name of a rule for the role set
that this connection uses when establishing the machine connection. The role or
rule name used must be a member of the preferred machine realm.
 Preferred User Realm—Specify the realm that for this connection that is used when
a user logs onto the endpoint. The connection ignores any other realm available for
the user’s login credentials.
 Preferred User Role Set—Specify the preferred role or the name of rule for the role
set to be used for user authentication. The role or rule name used must be a member
of the preferred user realm.

Documentation
 Credential Provider Authentication for Pulse Policy Secure Overview on

page 69


Machine and User Authentication Through a Pulse Connection for Pulse Policy Secure
Pulse Secure client supports certificate authentication for establishing Layer 2 and
Layer 3 connections. On Windows endpoints, a Pulse client connection accesses client
certificates located in the Local Computer personal certificate store to provide machine
authentication, or user certificates located in a user’s personal certificate store or on a
smart card for user authentication. A Pulse connection can access certificates from only
one location. For information on machine authentication, see “Machine Authentication
for Pulse Policy Secure Overview” on page 71.
You can create a Pulse connection that uses System Local, Active Directory, or RSA ACE
server authentication to verify the user and a certificate to verify machine identity before
establishing a connection. To do so, you must first enable an option for the Pulse
connection that allows the connection to check the client certificates located in the Local
Computer personal certificate store. The option, Select client certificate from machine
certificate store, is part of the User Connection Preferences of a Pulse connection. User
authentication is accomplished through realm authentication. Machine authentication
is accomplished as part of a realm certificate restriction, because the Pulse connection
uses the machine certificate. If the certificate store holds more than one valid certificate
for the connection, Pulse opens a dialog box that prompts the user to select a certificate.
The following list summarizes the steps to configure a Pulse connection on a Windows
endpoint that authenticates both the user and the machine. For detailed procedures on
how to perform each configuration task, see the related documentation links.
 Install a machine authentication certificate in the Local Computer personal certificate

store of the Windows endpoint and configure the Pulse server certificate server.
 Create a Pulse connection for the target Pulse server. The connection type can be UAC
(802.1X) or SSL VPN or UAC (L3). The Connection is established option is typically set
to Manually by the user or Automatically at user login.
 In the User Connection Preferences section of the connection properties, click the check
box labeled Select client certificate from machine certificate store. This option enables
the Pulse connection to perform the machine authentication as part of the Pulse
connection attempt.
 Create a sign-in policy on the Pulse server that specifies a user realm. The realm
authentication server can be a System Local, Active Directory, or RSA ACE server.
 Configure a certificate restriction on the realm to enable the Pulse server to request a
client certificate. Be sure to enable the option labeled Only allow users with a client-side
certificate signed by Trusted Client CAs to sign in. Because the Pulse connection is
configured to use the machine certificate, the user authentication takes place by means
of the realm certificate restriction.
Related Using the Certificate Server on page 312

Documentation
 About Sign-In Policies on page 471


Preferred Realm and Role for Pulse Secure Machine Authentication
When a Pulse Secure connection is configured to use machine authentication, any

prompts that occur during the login process cause the connection to fail. For example,
if the Pulse server authentication policy allows a user to select a realm or a role during
the login process, Pulse presents a dialog box to the user and prompts for the realm or
role selection. Toavoid failed connections caused by prompts during machine
authentication, you can specify a preferred role and realm for a Pulse connection.
For a Pulse connection that is used for machine authentication, you do not need to specify
the preferred role if either of the following conditions are true:
 Users are mapped to only one role.
 Users are mapped to more than one role, but the realm’s role mapping properties are
set to merge settings for all assigned roles.
For a Pulse connection that is used for machine authentication, you must specify the
preferred realm if the authentication sign-in policy allows the user to select a realm. If
that realm maps to only one role, you do not need to specify the role.
For a Pulse connection that is used for machine authentication, you must specify the
preferred role if either of the following conditions are true:
 The realm that the user connects to maps to more than one role and the realm’s role
mapping properties are set to require that the user must select a role. The preferred
role set must be the name of a role assigned in that realm.
 The realm that the user connects to maps to more than one role, and the realm’s role
mapping properties are defined by role mapping rules. You specify the preferred role
by specifying the name of a rule that assigns the role set. Figure 5 on page 68 shows a
role mapping rule with the rule name highlighted.

Figure 5: Pulse Secure Role Mapping Rule
To identify the connection as a machine authentication connection, you specify how the
connection is established using one of the following options:
 Automatically when the machine starts. Machine credentials used for authentication.
This option uses the machine credentials defined in Active Directory for the machine
login process and uses the same credentials for user login. When you select this option,
the Realm and Role Set Preferences settings enable you to specify the following
options:
 Preferred Machine Realm—Type the realm name that maps to the role you want to
assign.
 Preferred Machine Role Set—Type the name of the role. The role must be one that is
identified in the realm’s role mapping properties. Alternatively, you can specify the
name of a role mapping rule that assigns the role set.
user signs in to the desktop.
This option uses the Active Directory machine credentials for the machine login process.
When machine login is complete, Pulse drops that connection and then uses the user
credentials for user login. When you select this option, the Realm and Role Set
Preferences enable you to specify the following options:
 Preferred Machine Realm—Type the realm name that maps to the role you want to
assign.
 Preferred Machine Role Set—Type the name of the role. The role must be one that is

 Preferred User Realm—Type the realm name that maps to the role you want to assign.
 Preferred User Role Set—Type the name of the role. The role must be one that is
NOTE: Realm and role prompts are not the only prompts that are possible
during the login process. If the Pulse connection has the Dynamic Certificate
Trust option enabled and there is an issue with the server certificate, Pulse
asks the user if it is OK to proceed. That certificate prompt causes a machine
connection to fail. Note that the Pulse prompt for upgrading Pulse software
is presented after the user connection is established, and it will not affect a
machine authentication connection.

Documentation

Remote Desktop Protocol Compatibility with Pulse Secure 802.1X Machine
Authentication Connection
If you want to use Remote Desktop Protocol (RDP) to access an endpoint over a Pulse
802.1X connection, machine authentication is required. Because of a Microsoft OS
limitation, an RDP connection attempt over a user-only 802.1X authenticated connection
will fail. To support RDP connectivity over an authenticated 802.1X connection, you must
have a machine-only connection or a machine-then-user connection. In the case of a
machine-then-user connection, when you use RDP to connect to a machine over an
802.1X connection that is connected as user, the connection transitions the 802.1X
connection to a machine connection. If you subsequently login to the machine directly,
it transitions back to a user connection.
To access the endpoint using RDP, you must define that the connection is established
using one of the following Pulse connection options:
 Automatically when the machine starts. Machine credentials used for authentication.
user signs in to the desktop.
Credential Provider Authentication for Pulse Policy Secure Overview
When Microsoft introduced Windows Vista, it moved away from a login integration
interface based on GINA (Graphical Identification and Authentication) in favor of
credential providerauthentication. The Pulse Secure credential provider integration
enables connectivity to a network that is required for the user to login to the Windows
domain. For example, the domain controller might reside behind a firewall and the
endpoint uses credential provider login to connect to Pulse Policy Secure prior to
domain login. Pulse Secure integrates with Microsoft credential providers to enable
password-based

login and smart card login. Credential provider login is supported on Windows Vista and
later Windows platforms.
You can use the Pulse support for credential provider authentication to provide single
sign-on capabilities. Pulse establishes a connection to the network and then uses the
same credentials to login the Windows domain.
You enable Pulse credential provider support on a Pulse connection, (connection type
802.1X (UAC) or SSL VPN (L3)). After the connection has been downloaded to the
endpoint through the normal Pulse distribution methods, Pulse annotates the credential
provider tile that appears on the user login screen by adding a Pulse icon in the lower
right corner of the tile. When the user initiates the login process, Pulse establishes the
connection.
Pulse supports the following credential provider types:
 user-at-credprov—The connection is established before the user login using credentials

collected at the selected credential tile, which provides single-sign-on functionality.
The connection is maintained as an active connection on the user’s desktop.
 machine-then-user-at-credprov—The connection is established using machine

credentials when no user is logged in. When a user clicks a login tile and provides user
credentials, the machine connection is disconnected and a new connection is
established. When the user logs out, the user connection is disconnected and the
machine connection is reestablished. In one typical machine-then-user-at-cred prov
implementation, the machine connection and the user connection are mapped to
different VLANs.
Pulse credential provider support usage notes:
 If the endpoint includes more than one Pulse Layer 2 connection, Windows determines
which connection to use:
1. If a network cable is attached to the endpoint, Layer 2 wired connections are

attempted, and then wireless connections. If more than one wireless network is
available, the order is determined by the scan list specified as a Pulse connection
option.
2. After all Layer 2 options are attempted, Pulse runs location awareness rules to find
one or more eligible Layer 3 connections that are configured for credential provider
login. If more than one Layer 3 connection is found, Pulse prompts the user to select
a connection. A user can cancel the network connection attempt by clicking the
cancel button.
3. After Pulse evaluates all configured connection options, Pulse returns control to
Windows, which enables the user login operation.
 For connections that use user credentials, you can configure the Pulse connection so
that prompts are presented during the login process, for example, prompts for realm
or role selection or a server certificate trust prompt. For connections that use machine
credentials, Pulse prompts cause the connection to fail because there is no interface

to allow a response to the prompts. You can suppress any potential realm and role
choice by specifying a preferred realm and role for the connection.
 Pulse upgrade notifications and actions are disabled during credential provider login
and postponed until the user connection is established. Host Checker remediation
notifications are displayed.
Related Configuring Location Awareness Rules on page 49

Documentation

Machine Authentication for Pulse Policy Secure Overview
Machine authentication uses machine credentials (machine name and password or

machine certificate) to authenticate the endpoint. You can enable machine authentication
for Pulse Policy Secure as part of a Pulse Secure connection and distribute the
connection to endpoints through the normal Pulse distribution methods. You enable
Pulse machine authentication support on a Pulse connection, either Layer 2 or Layer 3.
The following describes the requirements for a machine authentication environment:
 The authentication server used by the Pulse connection must be Active

Directory/Windows NT for machine name/password authentication or a certificate
server for machine certificate authentication.
 The endpoint must be a member of a Windows domain, and the machine credentials
must be defined in Active Directory.
 The Pulse connection must be configured so that no prompts are presented during the
login process. For example, prompts for realm or role selection or for a server certificate
trust prompt cause the connection to fail. You can specify a preferred role and realm
for the connection, which eliminates realm and role selection dialogs.
 For machine certificate authentication, the domain workstation login certificate must
be issued by the domain certificate authority. The root certificate must be in the Machine
Trusted Certificate store instead of the certificate store for a particular user.
Pulse supports the following machine authentication types:
 machine-only—The connection is established using machine credentials when no user

is logged in. The connection is maintained after user login.
 user-after-desktop—The connection is established using machine credentials when

no user is logged in. After user login, the machine connection is disconnected. Once
the user logs out, the user connection is disconnected and the machine connection is
reestablished.
Related Preferred Realm and Role for Pulse Secure Machine Authentication on page 67
Documentation
 Configuring machine-only Machine Authentication for a Pulse Secure Connection on

page 64
 Configuring user-after-desktop Machine Authentication for a Pulse Secure

Connection on page 65

on page 66

Additional Methods for Accessing Protected Resources Behind the Policy Secure
Gateway
OAC and Pulse allow users to access protected resources on the following endpoint
platforms:
 Windows (Pulse Secure client and OAC)
 Macintosh (OAC)
You can install a basic Java agent with minimal functionality for Linux platforms. You
can also allow users on Windows, Macintosh, Linux, and Solaris platforms to access
protected resources without installing and running a Pulse Secure client on the
endpoint. This type of access is referred to as agentless access.
You specify whether you want the Policy Secure gateway to install OAC or Pulse or
provision agentless access for endpoints at the role level for Windows machines. Then
you can use role-mapping to associate users with specific roles. This allows you, for
example, to assign specific users to roles that are configured for agentless access.
For example, if you have contract employees with noncompany machines onto which
you do not want to install OAC, you can create two roles: one that allows agentless
access, and one that requires installation of OAC. Then, create two associated roles: one
for agentless access and one for OAC. Add role-mapping rules based on usernames to
assign the contract employees to the agentless role, and employees to the agent role.
When a user attempts to log in, they will be assigned to a role that either provisions
agentless access or installs OAC.
You can associate different realms with different sign-in policies and sign-in pages, so
users who log in to a resource can see a sign-in page based on whether they are a regular
employee or a contractor.

NOTE:
 When using agentless access, the user must leave the browser window
open on the Policy Secure gateway sign-in page to stay signed in. If the
user closes the browser window or opens a different page, the endpoint
loses the connection to the Policy Secure gateway, and the Infranet
Enforcer denies the user access to protected resources.
 IPsec enforcement is not supported on agentless or Java agent endpoints.

You must use source IP enforcement by setting up a source-based policy
on the Infranet Enforcer.
 Host Enforcer policies are not supported on agentless or Java endpoints.
 Agentless access with the Firefox browser is the only option for the Solaris
platform.
 Some older Mozilla browsers may crash over time with agentless access.
This is because the Policy Secure gateway normally uses AJAX to send
heartbeat messages to the endpoint. You can disable AJAX when you
configure agentless access if you have clients using older browsers.
Documentation
 Configuring a Non-Pulse Secure Supplicant for 802.1X on page 205

Configuring Agentless Access to Protected Resources
To configure agentless access to protected resources:
1. In the left navigation bar of the admin console select Users > User Roles > New User
Role.
2. Enter a name for this role.
3. Click Save Changes. The Roles configuration page is displayed.
4. Select the Agentless tab.
5. Select the Enable Agentless Access check box for this role.
6. If you have endpoints that will access the Policy Secure gateway from older Mozilla
browsers, select the Disable use of AJAX for heartbeats check box. You can then
specify these agentless roles for clients using Release 10 or earlier.

7. Select Hide the Agentless page after Captive Portal redirect if you do not want the
browser splash page to appear aftere Captive Portal authentication.
8. Select Users > User Realms > Select Realm > Role Mapping > New Rule to configure
role-mapping rules that map agentless access users to the role(s) you configured.
configuration for agentless access.
Documentation
 gateway on
page 72
 Understanding Role Mapping Rules on page 432
Using the Java Agent
You can allow Linux machines to access protected resources by configuring the Java
agent option on the Policy Secure gateway for these platforms.
If you provision a role with Java agent access and direct users to a browser to sign in, the
Java agent downloads automatically onto a Linux machine after the endpoint successfully
authenticates and any applicable Host Checker policies are enforced.
The Java agent is displayed on Linux as an icon in the menu bar. The Java agent displays
connected or disconnected status, the assigned IP address and a link to log out from the
session.
The Java agent maintains a heartbeat between the endpoint and the Policy Secure
gateway. It is not necessary to leave a browser window open to maintain connectivity.
IPsec enforcement is not supported with Java agent access. You must use source IP
enforcement by setting up a source-based policy.
Documentation
 Configuring the Java Agent on page 74

Configuring the Java Agent
To configure Java agent access for Linux and Solaris endpoints:
1. In the left navigation bar of the admin console select Users > User Roles > New User
Role.
2. Enter a name for this role.

3. Click Save Changes. The Roles configuration page is displayed.
4. Select the Agent tab.
5. Select the Install Java agent for this role check box. When a user assigned to this role
successfully accesses a portal that you have configured for access to the Policy
Secure gateway, the agent is downloaded automatically to the user’s machine.
configuration for Java agent access.
7. To configure role-mapping rules that map Java agent users to the role you configured
select Users > User Realms > Select Realm > Role Mapping > New Rule.
Related Additional Methods for Accessing Protected Resources Behind the Policy Secure
Documentation gateway on page 72
  Understanding User Roles on page 261


CHAPTER 3
Deployments with ScreenOS and Junos

OS Infranet Enforcers
 Using the Infranet Enforcer as a Policy Enforcement Point on page 79

 Understanding Deployments with Junos Infranet Enforcers on page 79
 Using Certificate-Based Security with Junos Enforcer Deployments on page 82
 Binding an Interface to a Security Zone on a Junos Enforcer on page 83
 Binding the Physical Interface on the Junos Enforcer on page 85
 Configuring the Junos Enforcer to Communicate with the Pulse Policy
Secure on page 86
 Setting Up the Junos Enforcer to Work with Pulse Policy Secure on page
87
 Connecting with the Junos Enforcer on page 88
 The IC Series and the Infranet Enforcer on page 89
 Understanding Deployments with ScreenOS Infranet Enforcers on page 90
 Task Summary: Setting Up Certificates for the IC Series and Infranet Enforcer on page 93
 Setting Up Certificates for the IC Series and Infranet Enforcer on page 94
 Using OpenSSL to Create a CA and Sign the Server Certificate on page 95
 Creating a CA and Signing the Server Certificate Using OpenSSL on page 95
 Importing the Certificate Into the Infranet Enforcer on page 97
 Configuring Certificate Authority Server Settings on page 97
 Binding an Interface to a Security Zone on a ScreenOS Enforcer on page 99
 Binding the Physical Interface on page 100
 ScreenOS Enforcer Configuration Overview on page 100
 Configuring the ScreenOS Connection on page 101
 Setting Up an Infranet Enforcer in Route Mode on page 102
 Create a Route Mode Interface with the ScreenOS Enforcer on page 103
 Setting Up an Infranet Enforcer in Transparent Mode on page 106
 Creating a Transparent Mode Instance on the ScreenOS Enforcer on page 107

 Viewing the Configuration of a Policy Secure gateway on the ScreenOS Enforcer on page
108
 Understanding the Infranet Enforcer Captive Portal Feature on page 109
 Before Configuring Captive Portal on page 110
 Creating a Redirect Policy on the Infranet Enforcer on page 111
 Overriding the Default Redirection Destination for Captive Portal on page 112
 Creating a Redirect Policy on the Junos Enforcer on page 113
 Creating a Redirect Policy on the ScreenOS Enforcer on page 114
 Understanding Deployments with ScreenOS Enforcer Virtual Systems on page 116
 Configuring the Policy Secure gateway for Overlapping IP Addresses on page 120
 IPsec Policies on page 121
 Using IPsec with the Infranet Enforcer on page 122
 Understanding IPsec Routing Policy Configuration Options on page 126
 IPsec Routing Policies on page 128
 Before you Begin on page 128
 Configuring IPsec Routing Policies on page 129
 Using IP Address Pool Policies for IPsec in a NAT Environment on page 130
 Understanding IP Address Pool Policies on page 132
 Configuring an IP Address Pool Policy on page 133
 Understanding ScreenOS Enforcer Source Interface Policies on page 135
 Configuring Source Interface Policies on page 135
 Using the Pulse Policy Secure User Interface to Create Basic ScreenOS Enforcer
IPsec Policies on page 136
 Setting Up ScreenOS Enforcer IPsec Routing Policies on page 137
 Configuring ScreenOS Enforcer IPsec Encryption Settings on page 138
 Using ScreenOS Enforcer Bidirectional VPN Policies on page 139
 Creating a ScreenOS Bidirectional VPN Policy on page 139
 Configuring Junos Enforcer IPsec Routing Policies on page 140
 Infranet Enforcer Policies Overview on page 144
 About Resource Access Policies on page 145
 Configuring Resource Access Policies on page 147
 User Role Policies on the Junos Enforcer on page 148
 Understanding Infranet Enforcer Auth Tables on page 150
 Understanding Dynamic Auth Table Allocation on page 151
 Configuring Dynamic Auth Table Allocation on page 152

Chapter 3: Deployments with ScreenOS and Junos OS Infranet Enforcers
 Configuring Auth Table Mapping Policies for Source IP Enforcement on page 152
 Configuring Auth Table Mapping Policies on page 154
Using the Infranet Enforcer as a Policy Enforcement Point
The Policy Secure gateway is the Layer 2 or Layer 3 policy decision point that
determines which users and endpoints can access protected resources. You can use
Juniper Networks firewalls to serve as the enforcement point to provide the ultimate
protection to ensure that network assets are secured.
You can use ScreenOS Enforcer or a Junos Enforcer with the UAC solution. A Junos
Enforcer is a J Series Services Router or an SRX Series Services Gateway configured as
a Layer 3 enforcement point. This document contains a configuration overview for using
the Policy Secure gateway with the ScreenOS Enforcer and the Junos Enforcer. For
version compatibility, see Pulse Policy Secure Supported Platforms.
The Policy Secure gateway authenticates users, ensures that endpoints meet security
policies, and serves resource access policy information to Juniper Networks security
devices.
After you configure the Policy Secure gateway and the Infranet Enforcer to successfully
communicate, you set up trust and untrust zones to define network boundaries. You
configure source IP policies or encrypted IPsec tunnels for endpoints to route traffic
between zones. Finally, you use resource access policies to permit or deny traffic to
protected resources.
For configuration instructions, see the UAC Interoperability with the ScreenOS Enforcer
and UAC Interoperability with the Junos Enforcer.
NOTE: The default keepalive time between the Policy Secure gateway and
the Infranet Enforcer is 300 seconds.
NOTE: With Pulse Policy Secure Release 4.2 and JunosOS Release 12.2,
the Juniper Networks EX Series Ethernet switch can be used as an Infranet
Enforcer. You can add an EX Series Ethernet switch in an 802.1X
deployment as an Infranet Enforcer, and then create resource access policies
to control access as the policy enforcement point.
Understanding Deployments with Junos Infranet Enforcers
This topic provides an overview of Pulse Policy Secure deployments with Junos
Infranet Enforcers. A Junos Enforcer is a J Series Services Router or an SRX Series

Services Gateway configured as a Layer 3 enforcement point. This topic includes the
 Communication Summary on page 80

 Configuration Summary on page 81
 Version Requirements on page 81
Communication Summary
This section describes the communication between the Policy Secure gateway and the
Infranet Enforcer.
 At startup, the Junos Enforcer contacts the Policy Secure gateway. The Junos
Enforcer uses the proprietary Junos Infranet Enforcer Protocol over an SSL
connection.
 The Junos Enforcer runs on top of SSL and makes a direct connection with the Policy
Secure gateway. Optionally, the Policy Secure gateway authenticates the Junos
Enforcer by means of a client certificate obtained during the SSL handshake. All
communications between the Policy Secure gateway and the Junos Enforcer are
through the Junos Enforcer Protocol over SSL.
 With the Junos Enforcer, you can configure the Policy Secure gateway to
dynamically create auth table entries on the Infranet Enforcer after a specific
resource is requested.
 To use source IP enforcement, you create security policies on Junos Enforcers that
allow traffic from the endpoint to protected resources.
 To use IPsec enforcement, you set up a VPN tunnel for a dial-up user with Internet
Key Exchange (IKE) with an Enforcer policy. The VPN tunnel and the IPsec policy enable
the user's endpoint (OAC or Pulse) to use an IPsec tunnel to the Junos Enforcer and
access protected resources. The Policy Secure gateway sends the necessary setup
information to the client.
 When the Junos Enforcer detects traffic from an endpoint that matches a Junos Enforcer
policy, it uses the endpoint’s auth table entry to determine the role(s) associated with
that user.
 The Junos Enforcer then matches the destination IP address of the protected resource
(from the Junos Enforcer policy) with a resource access policy. The Junos Enforcer
searches for a matching role and applies the policy action.
 The Policy Secure gateway sends commands as needed to the Junos Enforcer to
remove policies or auth table entries and deny access to protected resources. This
can occur, for example, when the user’s computer becomes noncompliant with
endpoint security policies or loses its connection with the Policy Secure gateway,
when you change the configuration of a user’s role, or when you disable all user
accounts on the Policy Secure gateway in response to a security problem (such as a
virus on the network).
If you have a cluster of Pulse Policy Secure devices, you should have one Virtual IP
Address (VIP), either provided by the cluster in Active/Passive mode, or provided by
a load-balancer in an Active/Active configuration. You configure that VIP as the IP
address of your device on the Enforcer, and the cluster or load-balancer handles
which device communicates.

For failover from one cluster of Pulse Policy Secure devices to another, or from one
non-clustered device to another, you can define multiple ICs in the firewall. The
firewall connects to the first device listed, by default. If that device is (or becomes)
unavailable, the Enforcer will attempt the next IC in the list. Once the Enforcer is
connected to a Pulse Policy Secure device, it will not switch to another device unless
the first device becomes unavailable. There is no fail-back mechanism. If the first
device becomes available again, the Enforcer will not automatically switch back.
You can use the Junos Enforcer as a policy enforcement point for any number of
Policy Secure gateways or Instant Virtual Extranet (IVE) Connect Secure gateways in
a federated network.
Configuration Summary
You must perform the following basic tasks to use the Policy Secure gateway with a
Junos Enforcer:
 Configure the Policy Secure gateway and the Junos Enforcer to communicate over a
secure connection.
 Configure user authentication and authorization by setting up user roles, authentication

and authorization servers, and authentication realms on the Policy Secure gateway.
 Configure resource access policies on the Policy Secure gateway to specify which
endpoints are allowed or denied access to protected resources.
 Configure traffic enforcement between each source and destination zone with Junos
Enforcer policies using one of the following methods:
 Source IP enforcement
 IPsec enforcement
Version Requirements
JunosOS Release 9.4 or higher is required for Layer 3 enforcement with UAC
interoperability.
In UAC Release 3.1 or later, you can use either a J Series Services Router or an SRX Series
Services Gateway configured as a Layer 3 enforcement point. For complete platform
and version compatibility see 4.3R1 Supported Platforms.
NOTE: A J Series device as a Layer 2 enforcement point is fully supported

with current and future releases of Pulse Policy Secure and Pulse Secure
client.
A J Series device as a Layer 3 enforcement point is supported with future UAC

releases, but interoperability is limited to JunosOS Release 10.4 or lower.
As of Release 11.1, you cannot use J Series devices as a Layer 3 enforcement

point.

Transparent mode is not supported on the Junos Enforcer.
Not all of the functionality of the ScreenOS Enforcer is supported. For feature
compatibility, see Table 11 on page 82
Table 11: Junos Enforcer Features
Feature Supported/Not Supported
Dynamic auth table allocation Supported
Resource access policies Supported
Auth table mapping Supported
Source IP Supported
IPsec Supported with Release 10.0
High availability Supported
Deny message to users Supported
Coordinated Threat Control (CTC – equivalent to SSG Supported with Release 10.0
IDP)
Support for vsys Not supported
Captive Portal Supported with Release 10.2
NOTE:
Related Using Certificate-Based Security with Junos Enforcer Deployments on page 82

Documentation
 Binding an Interface to a Security Zone on a Junos Enforcer on page 83

 Configuring the Junos Enforcer to Communicate with the Pulse Policy Secure on
page 86
Using Certificate-Based Security with Junos Enforcer Deployments
The Policy Secure gateway and the Junos Enforcer communicate over a secure channel.
Optionally, you can use digital security certificates as an enhanced mechanism for
establishing trust. A digital certificate is a form of identification. The certificate provides
information about the identity of the presenter and other data that helps determine
whether or not to trust the presenter.
When the Junos Enforcer first connects with the Policy Secure gateway, the devices
exchange security information to verify secure communication.

 In Pulse Secure implementations, the Junos Enforcer presents its password to the
Policy Secure gateway, and the Policy Secure gateway optionally verifies the
password before further communication is initiated. Once verified, the Policy Secure
gateway presents its device certificate to the Junos Enforcer. Verirfication of the
server certificate is not required for the Junos Enforcer to connect; however, as an
extra security measure you can verify the certificate for an additional layer of trust.
 If you are using the FIPS IC6500, only the Certificate Signing Request (CSR) method
for creating device certificates can be used. You cannot import a CA created certificate
(pfx) with a private key file on FIPS IC6500.
Public Key Infrastructure (PKI) refers to the hierarchical structure of trust required for
the successful implementation of public key cryptography.
Digital certificates are issued by a Certificate Authority (CA). With PKI, the CA is always
a trusted entity, so that the information contained in a certificate issued or signed by a
CA is guaranteed to be valid.
To ensure a secure trust relationship in the network between the Policy Secure gateway
and the Junos Enforcer is secure, you create a certificate hierarchy for this trust
relationship, and then upload the appropriate certificates into the devices.
To set up a CA certificate on the Junos Enforcer:
Import certificates on the Junos Enforcer by specifying the path in the CLI. You put the
certificate on a reachable server, then use the applicable statements to specify the
certificate from edit services.
1. To specify the full name of the Policy Secure gateway certificate that the Junos
Enforcer must match during communication, use the following statement:
set unified-access-control infranet-controller <Policy Secure gateway name> ca-profile

<specify ca-profile configured at security pki ca-profile>
For more detailed information, see the Junos OS CLI Reference and the Junos OS Initial
Configuration Guide for Security Devices.
See Certificate Security Administration for details about configuring certificate trust
between the Junos Enforcer and the Policy Secure gateway.
Related Connecting with the Junos Enforcer on page 88

Documentation

Binding an Interface to a Security Zone on a Junos Enforcer
Interfaces are a doorway through which traffic enters and exits a Juniper Networks device.
Many interfaces share the same security requirements. However, different interfaces can
have different security requirements for inbound and outbound data packets. Interfaces
with identical security requirements can be grouped together in a single security zone.
A security zone is a collection of network segments that require the regulation of inbound
and outbound traffic through policies. Security zones are logical entities to which one or

more interfaces are bound. Many types of Juniper devices, let you define multiple security
zones based on network requirements.
You can configure multiple security zones by dividing the network into segments to which
you can then apply various security options to satisfy the needs of each segment. At a
minimum, you must define two security zones, basically to protect one area of the network
from the other. On some security platforms, you can define many security zones, bringing
finer granularity to the network security design without deploying multiple security
appliances to do so.
From the perspective of security policies, traffic enters one security zone and exits through
another security zone. This combination of a “from-zone” and a “to-zone” is defined as
a context. Each context contains an ordered list of policies. On the Junos Enforcer, you
must define at least two zones to protect one area of the network from another.
You might need to bind the physical interfaces on a Juniper security device to security
zones or you might need to change a binding to accommodate your deployment.
NOTE: Slot numbering varies by platform, and interface numbering varies

by module type. For numbering information, see the user guide that
accompanied the device for slot and interface numbering information or visit
www.juniper.net/techpubs/ to obtain a copy of the user guide specific to your
device.
On J Series Services Routers, interface ports for the system are located on
Physical Interface Modules (PIMs) that you can install in slots on the device.
In addition, each device has four built-in Gigabit Ethernet ports in slot 0. Each
physical port can have many logical interfaces configured with properties
different from the port's other logical units.
Endpoints must reside in a different security zone from your protected resources. The
Policy Secure gateway can reside in any security zone. If you place the Policy Secure
gateway in a different security zone from the one that contains endpoints, you must set a
policy allowing traffic from the endpoints to the Policy Secure gateway.
Through the policies you define, you can permit traffic between zones to flow in one or
both directions. The routes that you define specify the interfaces that traffic from one
zone to another must use. Because you can bind multiple interfaces to a zone, the routes
you chart are important for directing traffic to the interfaces of your choice.
To view the zones on a Junos Enforcer, type the following command in the CLI:
user@host#show security zones
Related Binding the Physical Interface on the Junos Enforcer on page 85

Documentation
 Junos OS Documentation


Binding the Physical Interface on the Junos Enforcer
Figure 6: Binding the Interfaces
1. To configure the interface and its IP address for the trust and untrust zones, enter the
following statements in Edit mode:
user@host# set interfaces ge-0/0/1 unit 0 family inet address 192.168.0.1/24

2. To configure the trust zone and to assign the interface to it, enter the following
statement in Edit mode:
user@host# set security zones security-zone trust interfaces interface

3. To configure the interface and its IP address for the untrust zone, enter the following

user@host# set interfaces ge-0/0/1 unit 0 family inet address 10.0.0.20/24

4. To configure the untrust zone and to assign the interface to it, enter the following
user@host# set security zones security-zone untrust interfaces interface
NOTE: To use IPsec with the Junos Enforcer, you must enable IKE services
for the gateway. If you have multiple IPsec tunnels with multiple gateways,
the hostname for each gateway must be unique.
Related Binding an Interface to a Security Zone on a Junos Enforcer on page 83

Documentation

Configuring the Junos Enforcer to Communicate with the Pulse Policy Secure
The Junos Enforcer works with the Policy Secure gateway for Layer 3 connectivity. Users
can connect with source IP or IPsec (JunosOS Release 10.0 or later).
For the initial setup, you must specify the Policy Secure gateway name, IP address, port
number over which the Junos Enforcer and Policy Secure gateway will connect, the
interface, the password (the same password as entered on the Policy Secure
gateway), and, optionally, the CA profile and server certificate subject. Use the Junos
CLI to add this information.
You can configure the Junos Enforcer in “test only” mode. In test only mode, the Junos
Enforcer does not enforce UAC policies and allows all traffic to pass. However, all policy
decisions are logged. This allows you to set up the devices before actual deployment
and determine how the UAC solution works using different configuration options. For
example, the Policy Secure gateway and endpoints can reside on different physical
interfaces of the Junos Enforcer (using both interfaces on the Policy Secure gateway) or
on the same interface.
Policy Secure gateway policies are role based. Each policy specifies a destination (the
resources that are being protected), a set of roles, and an action (allow or deny). To
determine the roles for users, an auth table maps source IP addresses to roles. When an
endpoint accesses the Policy Secure gateway, the Policy Secure gateway populates
the Junos Enforcer with the mapping from the endpoint's IP address to the endpoint's
set of roles. When evaluating a flow, the source IP address of the initial packet is used to
look up the roles. Then the first policy that matches both the destination (resource) and
the roles is used to determine whether to permit or deny the flow.
NOTE: If you are using the Export edition of Pulse Secure, you must set the
encryption strength on the Policy Secure gateway to use 40-bit ciphers on
the Configuration > Security page of the admin console. Domestic editions
do not have this requirement.
Related Setting Up the Junos Enforcer to Work with Pulse Policy Secure on page 87
Documentation


 Connecting with the Junos Enforcer on page 88
Setting Up the Junos Enforcer to Work with Pulse Policy Secure
This example details a configuration with the Policy Secure gateway on the untrusted
interface side (the same side as endpoints). For more information, see the Junos OS
Initial Configuration Guide for Security Devices and Junos OS CLI Reference.
To configure the Junos Enforcer:
1. Set up the trusted interface. The trusted interface connects to the protected resource.
The untrusted interface connects to the Policy Secure gateway.
2. Ensure that the DHCP server is disabled or enabled as required for the deployment.
3. Create an instance of the Policy Secure gateway on the Junos security device, and
provide the network information required for connecting using the CLI. This information
includes the Policy Secure gateway host name, the IP address, and the interface to
which the device will connect. The default port for communication with the Policy
Secure gateway is 11123, you cannot change the port. You must also specify a
password that matches the password configured on the Policy Secure gateway.
For complete CLI instructions and syntax, see the Junos OS CLI Reference.
a. Specify the Policy Secure gateway’s hostname:
user@host# set services unified-access-control infranet-controller hostname

b. Specify the Policy Secure gateway’s IP address:
user@host# set services unified-access-control infranet-controller hostname address

ip-address
c. Specify the Junos interface to which the Policy Secure gateway should connect:
user@host# set services unified-access-control infranet-controller hostname interface

interface-name
d. Specify the password that the SRX Series or J Series device should use to initiate
secure communications with the Policy Secure gateway:
user@host# set services unified-access-control infranet-controller hostname password

password
4. Set the appropriate timeout and interval values, and specify a timeout action. The
timeout that you set specifies the elapsed time beyond which the Junos Enforcer
attempts to reconnect with the Policy Secure gateway if no communication is
received. The interval specifies how often the Policy Secure gateway sends a
heartbeat to the Junos Enforcer.
5. (Optional) Verify that the certificate of the CA that signed the Policy Secure
gateway’s server certificate is loaded in the Junos Enforcer and that the path to the
certificate is specified.

NOTE: Although certificate verification is optional, there are three different

certificate options on the Junos Enforcer that will produce different results.
If certificate-verification is set to required, it is required that the device

verify any Policy Secure gateway server certificate. If any Policy Secure
gateway's
ca-profile is not configured, the commit check fails.
If certificate-verification is set to warning (the default), and the Policy

Secure gateway ca-profile is not configured, the commit check displays a
warning about the security risk with a similar warning in the syslog.
If certificate-verification is set to optional, there is no warning.
Juniper Networks highly recommends that you choose to verify the

Policy Secure gateway certificate.
6. Verify routing from the Policy Secure gateway to the untrusted interface.
7. Ensure that both the Junos Enforcer and the Policy Secure gateway are set to the
correct time. If possible, use a Network Time Protocol (NTP) Server to set the date
and time of both appliances.
When you finish configuring the Policy Secure gateway instance, the Junos Enforcer can
initiate the connection with the Policy Secure gateway. The Junos Enforcer optionally
validates the Policy Secure gateway server certificate if so configured. The device sends
the serial number to authenticate with the Policy Secure gateway.
For the Junos Enforcer to establish communication, you must configure the Junos Enforcer
on the Policy Secure gateway.
Related Connecting with the Junos Enforcer on page 88

Documentation

Connecting with the Junos Enforcer
The Junos Enforcer connects with the Infranet Enforcer over an SSL connection. To initiate
the connection between the two devices, you must specify the password and serial
number of the Junos Enforcer.
The Junos Enforcer initiates the connection to the Policy Secure gateway. The Policy
Secure gateway presents its SSL server certificate to the Junos Enforcer. Optionally,
you can configure the Junos Enforcer to verify the certificate and to specify constraints
with which the Policy Secure gateway must comply.
The Junos Enforcer and the Policy Secure gateway perform mutual authentication with
the proprietary JUEP-MAUTH challenge-response authentication based on the
password configured. For security reasons, the password is not included in the message
sent to the Policy Secure gateway.

After the SSL handshake, all further communication between the Policy Secure
gateway and the Junos Enforcer occurs over the SSL connection. The Junos Enforcer is
the client and the Policy Secure gateway is the server.
To configure the Policy Secure gateway to accept a connection from the Junos Enforcer:
1. On the left navigation bar in the Policy Secure gateway admin console, select UAC >
Infranet Enforcer > Connection.
2. Click New Enforcer. The New Infranet Enforcer dialog box is displayed. By default, the
new ScreenOS Enforcer page is displayed.
3. Select the Junos option button. The Junos Enforcer page is displayed.
4. Enter the name of the Infranet Enforcer in the Name box.
5. Enter the password for the Junos Enforcer.
6. Enter the serial number of the Junos Enforcer. You can view the serial number on the
Junos Enforcer using the command:
user@hostshow chassis hardware

7. Ensure that the server certificate for the Policy Secure gateway is configured for the
interface to which the Junos Enforcer is connecting.
After you the devices to communicate, you must create security policies on the Junos
Enforcer for traffic enforcement.
Related Understanding Infranet Enforcer Source IP Security Policies on page 148

Documentation
 Setting Up the Junos Enforcer to Work with Pulse Policy Secure on

page 87
The IC Series and the Infranet Enforcer
NOTE: A Infranet Enforcer can be either a ScreenOS firewall device, or a J

Series or SRX Series Services Gateway.
The Policy Secure gateway is the policy decision point that determines which users and
endpoints can access protected resources. You can use Juniper Networks firewalls to
serve as the enforcement point to provide the ultimate protection to ensure that
network assets are secured.
You can use either a ScreenOS Enforcer or a Junos Enforcer with the UAC solution. A
Junos Enforcer is a J Series Services Router or an SRX Series Services Gateway configured
as a Layer 3 enforcement point. A ScreenOS Enforcer is an ISG Series Integrated Services
Gateway or a SSG Series Secure Services Gateway. This document contains configuration
details for the ScreenOS Enforcer. See 4.3R1 Supported Platforms for version compatibility.

Understanding Deployments with ScreenOS Infranet Enforcers
This topic provides an overview of Pulse Policy Secure deployments with ScreenOS
Infranet Enforcers. It includes the following information:
 Deployment Summary on page 90

 Communication Summary on page 90
 Version Requirements on page 92
Deployment Summary
The Policy Secure gateway is the policy decision point that determines which users and
endpoints can access protected resources. You can use Juniper Networks firewalls to
serve as the enforcement point to provide the ultimate protection to ensure that
network assets are secured.
Communication Summary
This section describes the communication between the Policy Secure gateway and the
Infranet Enforcer.
 At startup, the ScreenOS Enforcer contacts the Policy Secure gateway over an SSL
connection using the NetScreen Address Change Notification (NACN) protocol.
 After the ScreenOS Enforcer establishes a connection with the Policy Secure
gateway, the Policy Secure gateway opens an SSH connection with the ScreenOS
Enforcer. The Policy Secure gateway uses this SSH connection to push policy and
user authentication information to the ScreenOS Enforcer.
 With ScreenOS Release 6.0 or earlier, when the Policy Secure gateway
authenticates a user and verifies that the user’s endpoint is compliant with
endpoint security policies, the Policy Secure gateway pushes user-specific
configuration information to the ScreenOS Enforcer. This information includes an
auth table entry for each authenticated user. An auth table entry consists of the
user’s name, a set of roles, and the IP address of the wired adapter, wireless
adapter, or virtual adapter in the user’s computer. With ScreenOS Release 6.1 or
later, and with the Junos Enforcer, you can configure the Policy Secure gateway to
dynamically create auth table entries on the Infranet Enforcer after a specific
resource is requested.
 To use source IP enforcement, you create infranet auth source IP policies on ScreenOS
Enforcers that allow traffic from the endpoint to protected resources.
 To use IPsec enforcement, you set up a VPN tunnel for a dial-up user with Internet Key
Exchange (IKE) with an Enforcer policy. The VPN tunnel and the infranet auth IPsec
policy enable the user's endpoint (OAC or Pulse) to use an IPsec tunnel to the Infranet
Enforcer and to access protected resources. The Infranet Enforcer sends the necessary
setup information to the client.

 When the Infranet Enforcer detects traffic from an endpoint that matches an Infranet
Enforcer policy, it uses the endpoint’s auth table entry to determine the role associated
with that user.
 The Infranet Enforcer matches the destination IP address of the protected resource
(from the Infranet Enforcer policy) with a resource access policy. The Infranet Enforcer
searches for a matching role and applies the policy action.
 As necessary, the Policy Secure gateway sends commands to the Infranet Enforcer to
remove policies or auth table entries and deny access to protected resources. This
can occur, for example, when the user’s computer becomes noncompliant with
endpoint security policies or loses its connection with the Policy Secure gateway,
when you change the configuration of a user’s role, or when you disable all user
accounts on the Policy Secure gateway in response to a security problem (such as a
virus on the network).
The FIPS IC6500 or a non-FIPS Policy Secure gateway can be used with a ScreenOS
Enforcer that is in FIPS mode. If FIPS is enabled on the Infranet Enforcer, the admin
console displays the information on the Connection page.
You can configure an Infranet Enforcer to work with more than one Policy Secure
gateway in a high availability configuration known as a Policy Secure gateway
cluster. The Infranet Enforcer communicates with only one Policy Secure gateway
at a time. The other Policy Secure gateways are used for failover. If the Infranet
Enforcer cannot connect to the first Policy Secure gateway you added to the cluster, it
attempts to connect to successive devices in the configuration list until a connection
occurs. If the currently connected Policy Secure gateway fails, the Infranet Enforcer
attempts to connect to the first Policy Secure gateway again. The Policy Secure
gateways configured on an Infranet Enforcer should all be members of the same
Policy Secure gateway cluster.
You can use the Infranet Enforcer as a policy enforcement point for any number of
Policy Secure gateways or Instant Virtual Extranet (IVE) Connect Secure gateways in
a federated network.
You must perform the following basic tasks to use the Policy Secure gateway with an
Infranet Enforcer:
 Configure the Policy Secure gateway and the ScreenOS Enforcer to communicate
with each other over a secure connection.
 Configure user authentication and authorization by setting up user roles, authentication

and authorization servers, and authentication realms on the Policy Secure gateway.
 Configure resource access policies on the Policy Secure gateway to specify which
endpoints are allowed or denied access to protected resources.
 Configure traffic enforcement between each source and destination zone with ScreenOS
Enforcer Infranet auth policies. Use one of the following methods:
 Source IP enforcement
 IPsec enforcement

Version Requirements
You can use either a ScreenOS Enforcer or a Junos Enforcer with the UAC solution. This
section describes version requirements for ScreenOS Enforcers. See 4.3R1 Supported
Platforms for version compatibility.
You can use Juniper ScreenOS Release 5.4 or later with UAC.
Not all ScreenOS releases support all features described in this

document.Table 12 on page 92 indicates what release version of ScreenOS is required
for specific features.
Table 12: ScreenOS Options
Feature Required ScreenOS Release
Captive portal 5.4
Configurable auth table entries 6.0
Seamless cluster failover 6.0R2
Dynamic auth table allocation 6.1
200 roles per auth table entry 6.1
Messages to authenticated but unauthorized users 6.2
Support for ISG-IDP 6.2
Support for vsys 6.2
Nonstandard port for captive portal 6.3
Related Using Certificate-Based Security with Infranet Enforcer Deployments on page 92

Documentation

Using Certificate-Based Security with Infranet Enforcer Deployments
The Policy Secure gateway and the Infranet Enforcer communicate over a secure
channel using digital security certificates as the mechanism for establishing trust. A
digital certificate is a form of identification. The certificate provides information about
the identity of the presenter and other data that helps determine whether or not to
trust the presenter.
Public Key Infrastructure (PKI) refers to the hierarchical structure of trust required for
the successful implementation of public key cryptography.

When the Infranet Enforcer first connects with the Policy Secure gateway, the devices
exchange security information to verify secure communication.
 In ScreenOS implementations, the Policy Secure gateway presents its device

certificate, and the ScreenOS Enforcer must verify the certificate before further
communication is initiated.
 In Pulse Secure implementations, the Junos Enforcer presents its password to the
Policy Secure gateway, and the Policy Secure gateway verifies the password before
further communication is initiated. Once verified, the Policy Secure gateway presents
its device certificate to the Junos Enforcer. Verification of the server certificate is not
required for the Junos Enforcer to connect, however, you can verify the certificate for
an additional layer of trust.
 If you are using the FIPS IC6500, only the Certificate Signing Request (CSR) method
for creating device certificates can be used. You cannot import a CA-created certificate
(pfx) with a private key file on a FIPS IC6500.
Digital certificates are issued by a Certificate Authority (CA). With PKI the CA is always
a trusted entity, so the information in a certificate issued or signed by a CA is guaranteed
to be valid.
To ensure that the trust relationship in the network between the Policy Secure gateway
and the Infranet Enforcer is secure, you create a certificate hierarchy for this trust
relationship, and then upload the appropriate certificates into the devices.
Related Task Summary: Setting Up Certificates for the IC Series and Infranet Enforcer on page 93
Documentation
 Setting Up Certificates for the IC Series and Infranet Enforcer on page 94

 Using OpenSSL to Create a CA and Sign the Server Certificate on page 95
Task Summary: Setting Up Certificates for the IC Series and Infranet Enforcer
To allow the ScreenOS Enforcer to communicate with the Policy Secure gateway, you
must perform all of the following tasks:
 If you do not have one already, obtain the CA certificate that signed the Policy Secure
gateway server certificate to load on the Infranet Enforcer.
 Create a CSR for a Policy Secure gateway server certificate, and use the CA
certificate to sign the server certificate.
 Import the CA certificate into the Infranet Enforcer.
 Specify the CA certificate to be used to verify the Policy Secure gateway.
If the server certificate or the CA certificate is missing or expired, the Infranet Enforcer
cannot communicate with the ScreenOS Enforcer. The Infranet Enforcer does not accept
the temporary self-signed certificate that the Policy Secure gateway created during
initialization.

Related Using OpenSSL to Create a CA and Sign the Server Certificate on page 95
Documentation

Setting Up Certificates for the IC Series and Infranet Enforcer
To set up certificates for the Policy Secure gateway and Infranet Enforcer:
1. If you do not have a CA, install and use OpenSSL to generate a CA certificate.
2. Create a CSR for a server certificate, and then sign the CSR by using either your CA or
OpenSSL.
3. Import the signed server certificate created from the CSR into the Policy Secure
gateway by selecting System > Configuration > Certificates > Device Certificates from
the left navigation bar of the Policy Secure gateway admin console.
 Under Certificate Signing Requests, click the Pending CSR link that corresponds to
the signed certificate. The Pending Certificate Signing Request dialog box is
displayed.
 Under Step 2 Import the signed certificate and then browse to the certificate file
you received from the CA. For example:
c:\openssl\certs\ic.crt
 Click Import.
4. By default, the signed server certificate is automatically associated with the internal
port on the Policy Secure gateway. To associate the certificate with the external or
virtual port, perform these steps:
 Select System > Configuration > Certificates > Device Certificates in the left navigation
bar.
 Click the link that corresponds to a certificate that you want to use. The Certificate
Details dialog box is displayed.
 Under Present certificate on these ports, specify the port that the Policy Secure
gateway should associate with the certificate. You can choose internal or external
ports and primary or virtual ports, but you cannot choose a port that is already
associated with another certificate.
 Click Save Changes.
5. Import the certificate of the CA that signed the Policy Secure gateway’s server
certificate into the Infranet Enforcer.
NOTE: To prevent your Web browser’s security warning from appearing each
time you sign into the Policy Secure gateway, import the certificate of the
CA that signed the Policy Secure gateway’s server certificate into your
browser’s list of trusted root certification authorities.

NOTE: If you later import a different server certificate and CA certificate, you
might need to initiate a new connection to use them. To initiate a new
connection, select Maintenance > System > Platform > Restart Services in the
Policy Secure gateway admin console. The Infranet Enforcer connects to the
Policy Secure gateway and validates the new certificate.
Related Creating a CA and Signing the Server Certificate Using OpenSSL on page 95
Documentation

Using OpenSSL to Create a CA and Sign the Server Certificate
If you do not have a CA, follow the instructions in this section to use OpenSSL on Windows
to create a CA certificate and to sign the CSR for the server certificate.
You can also use OpenSSL to create a trusted root CA certificate for validation of the
Policy Secure gateway by OAC or Pulse. Follow the instructions in this section to create
a CA certificate and sign the CSR for the Policy Secure gateway’s server certificate.
Related Creating a CA and Signing the Server Certificate Using OpenSSL on page 95
Documentation

Creating a CA and Signing the Server Certificate Using OpenSSL
To set up OpenSSL:
1. Download and install OpenSSL from

http://www.slproweb.com/products/Win32OpenSSL.html.
2. Set the install directory to c:\openssl and accept the other installation defaults.
3. At the Windows command prompt, type the following commands:
C: cd \openssl
C: md certs
C: cd certs
C: md demoCA
C: md demoCA\newcerts
C: edit demoCA\index.txt
4. Press Alt+F, S to save the file.
5. Press Alt+F, X to exit the editor.
6. At the Windows command prompt, type the following command:
C: edit demoCA\serial
7. Type 01 in the document window.
8. Press Alt+F, S to save the file.

9. Press Alt+F, X to exit the editor.
10. At the Windows command prompt, type the following command:
C: set path=c:\openssl\bin;%path%
C: set OPENSSL_CONF=c:\openssl\bin\openssl.cfg
11. : In Wordpad (or an equivalent text editor that correctly handles Unix line breaks),
edit the openssl config file (c:\openssl\bin\openssl.cfg), change the CA policy match
for country and state from “match” to “optional”, and save your changes. The resulting
config stanza should appear as follows:
# For the CA policy

[ policy_match ]
countryName = optional
stateOrProvinceName = optional
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
12. To create a CA key, type the following command at the Windows command prompt
in the c:\openssl\certs directory:
C: openssl genrsa -out ca.key 1024

Loading 'screen' into random state - done
Generating RSA private key, 1024 bit long modulus
........++++++
.++++++
e is 65537 (0x10001
To create and sign a CSR from the CLI:
1. Type the following command at the Windows command prompt in the c:\openssl\certs
directory:
C: openssl req -new -x509 -days 365 -key ca.key -out demoCA/cacert.pem
2. Enter the appropriate distinguished name (DN) information for the CA certificate. You
can leave some fields blank by hitting enter.
For example:
Country Name: US
State or Province Name: MA
Locality Name: Boston
Organization Name: XYZ
Org. Unit Name: IT
Common Name: ca.xyz.com
e-mail Address: user@xyz.com
To create and sign a CSR from the Web UI:
1. Select System > Configuration > Certificates > Device Certificates in the left navigation
bar.
2. Click New CSR. The new Certificate Signing Request page is displayed.
3. Enter the required information. For example:

Country Name: US
State or Province Name: MA
Locality Name: Boston


Org. Unit Name: IT
Common Name: ic.xyz.com
The organization name in the CSR must match the CA certificate's organization name.
If the organization names do not match, you cannot sign the CSR.
4. Enter random characters in the Random Data box.
5. Click Create CSR. The Pending Certificate Signing Request page is displayed.
6. Select and copy all of the text in the text box in Step 1 into a text editor, and save the
text file in the following directory:
c:\openssl\certs\ic.csr
7. To sign the certificate, type the following command at the Windows command prompt
in the c:\openssl\certs directory:
openssl ca -in ic.csr -out ic.crt -keyfile ca.key

8. Enter Y to sign the certificate.
9. Enter Y to commit the certificate.
You are now ready to import the server certificate into the Policy Secure gateway
and the CA certificate into the Infranet Enforcer.
Related Importing the Certificate Into the Infranet Enforcer on page 97

Documentation

Importing the Certificate Into the Infranet Enforcer
To import a CA certificate on the ScreenOS Enforcer:
1. On the Infranet Enforcer Web UI, select Objects > Certificates in the left navigation
bar.
2. Select CA from the Show list.
3. Click Browse to find and select the CA certificate (such as

c:\OpenSSL\certs\demoCA\cacert.pem) Then click Load.
4. Select CA from the Show list to display the CA certificate.
Related Setting Up Certificates for the IC Series and Infranet Enforcer on page 94
Documentation

Configuring Certificate Authority Server Settings
The CA server you use can be owned and operated by an independent CA or by your own
organization. If you use an independent CA, you must contact them for the addresses of
their CA and CRL servers (for obtaining certificates and certificate revocation lists), and
for the information they require when submitting certificate requests. When you are your
own CA, you determine this information yourself.

On the ScreenOS Enforcer, you can use the Web UI to configure CA server settings. Select
Objects > Certificates and navigate to the proper certificate.
You can configure the following options:
 X509 Certificate Path Validation Level: Within X509 is a specification for a certificate
that binds an entity's distinguished name to its public key through the use of a digital
signature. Select Full to validate the certificate path all the way back to the root, or
select Partial to validate it only part of the way. The CRL distribution point extension
(.cdp) in an X509 certificate can be either an HTTP URL or an LDAP URL.
 Certificate Revocation Check settings:
 CRL (Certificate Revocation List): Enables the Juniper security device to use only the
CRL to check the certificate status.
 OCSP (Online Certificate Status Protocol): Enables the Juniper security device to
use only OCSP to check the certificate status.
 None: Disables CRL certificate checking. If you are not using CRL certificate checking,
be sure to disable it in the CA Server Settings dialog box.
 Best Effort: Enables the Juniper security device to use CRL to check the certificate
status. If there is no indication that the certificate is revoked, accept the certificate.
 CRL settings:
 URL Address: Specifies the internal Web-based URL of the LDAP server managing
your CRL.
 LDAP Server: Specifies the IP address or domain name of the LDAP Root CA server
that manages the CRL.
 Refresh Frequency: Applies only to the CRL only. From the list, select whether you
want to update the CRL daily, weekly, monthly, or according to the default setting
(which updates the CRL shortly after the next scheduled update).
 OCSP settings:
 URL Address: Specifies the internal Web URL of the OCSP server.
 Advanced Settings: Specifies a CA with which the Juniper security device verifies the
OCSP response.
 SCEP (Simple Certificate Enrollment Protocol) settings:
 RA CGI (registration authority certificate generation information): Specifies the RA

URL where the Juniper security device will request a CA certificate.
 CA CGI (certificate authority certificate generation information): Specifies the CA

URL.
 CA IDENT: Specifies the name of the CA for purposes of certificate ownership, if

necessary.

 Challenge: Specifies the challenge word sent to you by the CA that prove your identity
to the CA.
 Advanced Settings: Configures Advanced SCEP settings, such as polling interval and
certificate authentication.

Documentation

Binding an Interface to a Security Zone on a ScreenOS Enforcer
Security zones represent virtual sections of the network that are segmented into logical
areas. Security zones can be assigned to an interface or, on large devices, to a virtual
system.
From the perspective of security policies, traffic enters one security zone and exits through
another security zone. The ScreenOS Enforcer includes several predefined zones, for
example trust and untrust.
You might need to bind the physical interfaces on the Pulse Secure security device to
security zones, or you might need to change a binding to accommodate your
deployment.
Figure 7 on page 100 shows a typical setup for a ScreenOS Enforcer Integrated Security
Gateway 2000 (ISG 2000).
NOTE: Slot numbering varies by platform, and interface numbering varies

by module type. For slot numbering and interface information refer to the
user guide that accompanied the device.
Endpoints must reside in a security zone different from where your protected resources
reside. The trust and untrust security zones in Figure 7 on page 100 are default zones for
Route mode configurations on a ScreenOS Enforcer. For Transparent mode (on ScreenOS
Enforcers), use the v1-trust and v1-untrust security zones (not shown). The Policy
Secure gateway (not shown) can reside in any security zone. If you place the Policy
Secure gateway in a security zone that is different from the security zone that contains
endpoints, you must set a policy allowing traffic from the endpoints to the Policy
Secure gateway.
To view the zones available on the ScreenOS Enforcer, enter the get zone command in
the ScreenOS CLI. To configure custom zones, see
http://www.juniper.net/techpubs/en_US/release-independent/screenos/information-products/pathway-pages/screenos/product/index.html
.
In Figure 7 on page 100 the endpoints reside in the Untrust zone, and the protected resources
reside in the Trust zone. Port numbering is dependent on chassis configuration.

Figure 7: Binding a Physical Interface to a Security Zone
Related Binding the Physical Interface on page 100

Documentation

Binding the Physical Interface
On the ScreenOS Enforcer, you can bind an interface to a security zone from either the
Web UI or the CLI.
ScreenOS Web UI
Select Network > Interfaces > Edit: Select a Zone from the menu then click OK.
ScreenOS CLI
set interface ethernet4/1 zone trust
set interface ethernet3/8 zone untrust
save
Related ScreenOS Enforcer Configuration Overview on page 100

Documentation

ScreenOS Enforcer Configuration Overview
You can use Route mode or Transparent mode to configure a Juniper Networks ScreenOS
Enforcer. By default, the ScreenOS Enforcer operates in Route mode. For more information

about how to set up routing, see

http://www.juniper.net/techpubs/en_US/release-independent/screenos/information-products/pathway-pages/screenos/product/index.html.
Pulse Secure recommends configuring the Infranet Enforcer to use SSHv2.
To perform ScreenOS configuration tasks the administrator must have root access.
The related documentation list provides links to information about configuring the Infranet
Enforcer. For cabling, rack mounting, and basic configuration instructions for platforms,
see IC Series Hardware.
Related Configuring the ScreenOS Connection on page 101

Documentation

Configuring the ScreenOS Connection
The ScreenOS Enforcer connects to the Policy Secure gateway over an SSH connection
that uses the NetScreen Address Change Notification (NACN) protocol. To configure a
connection between the two appliances, specify the following items on the Policy
Secure gateway in an Infranet Enforcer connection policy:
 An NACN password
 An administrator name and password for signing into the Infranet Enforcer using SSH
 The serial number of the Infranet Enforcer
The Policy Secure gateway uses the NACN password and serial number for a connection
from the ScreenOS Enforcer. When the ScreenOS Enforcer first turns on, it sends an
NACN message containing the NACN password and serial number to the Policy Secure
gateway. The Policy Secure gateway uses the serial number to determine which
ScreenOS Enforcer is attempting to connect, and the Policy Secure gateway uses the
NACN password to authenticate the ScreenOS Enforcer. The Policy Secure gateway then
begins communicating with the ScreenOS Enforcer using SSH.
To configure the Policy Secure gateway to connect to the Infranet Enforcer:
2. Click New Enforcer. The new ScreenOS Enforcer page is displayed.
3. Enter an NACN password for this Infranet Enforcer in the NACN password box. You
must enter this same NACN password when configuring the Infranet Enforcer.
4. In the appropriate boxes, enter the administrator name and password for signing into
the Infranet Enforcer.
5. Enter the serial number of the Infranet Enforcer. You can view the serial number on
the Home page of the Infranet Enforcer Web UI, or by using the ScreenOS CLI
command:

get system.
6. Select No 802.1X from the Location Group list if you are not using an Infranet Enforcer
as an 802.1X RADIUS client of the Policy Secure gateway. This is the typical setting.
When you finish configuring the Infranet Enforcer, the Infranet Enforcer attempts to
connect to the Policy Secure gateway. If the connection is successful, a green dot is
displayed next to the Infranet Enforcer icon under Enforcer Status select System > Status
> Overview in the Policy Secure gateway admin console. The Infranet Enforcer IP
address is also displayed in UAC > Infranet Enforcer > Connection.
NOTE: To initiate a connection immediately after you finish configuring the

Infranet Enforcer, restart the Policy Secure gateway services by clicking
Maintenance
> System > Platform > Restart Services from the Policy Secure gateway admin
console.

Documentation

Setting Up an Infranet Enforcer in Route Mode
The Policy Secure gateway can reside on either side of the Infranet Enforcer. If the Policy
Secure gateway resides on the trust interface side, and users come in through the untrust
interface, the administrator must configure a policy (untrust to trust) on the Infranet
Enforcer that allows traffic to pass between the Policy Secure gateway and OAC or
Pulse. By default, Infranet Enforcer traffic from the untrust interface to the trust
interface is denied.
The following describes the setup with the Policy Secure gateway on the untrust
interface side (same side as users).
To configure an Infranet Enforcer in Route mode:
1. Set up the trust interface. The trust interface connects to the protected resource.The
untrust interface connects to the Policy Secure gateway. Set the following interface
(ethernet1/1) settings:
 Set routing
 Enable management of the following services:
 SSL
 SSH
 IP (optionsl)
2. Ensure that the DHCP server is disabled or enabled, as appropriate for the deployment.

certificate into the Infranet Enforcer.
a. If you set up an NSRP cluster before you import the CA certificate into the Infranet
Enforcer, the CA certificate is automatically synchronized to all Infranet Enforcers
in the cluster. However, if you set up the NSRP cluster after you import the CA
certificate, you must manually synchronize the certificate to the other Infranet
Enforcers in the cluster by typing the following CLI command:
exec nsrp sync pki

You cannot load the self-signed Policy Secure gateway SSL certificate into the Juniper
security device. For more information about certificates and certificate options, see
Certificate Security Administration.
The certificate of the CA that signed the Policy Secure gateway’s certificate must be
imported on the Infranet Enforcer because the Infranet Enforcer must be able to
trust the Policy Secure gateway during an SSL session. When a user signs into a
server by means of SSL, the server displays a dialog box in which the user can
manually accept the certificate that is associated with that server. For the Infranet
Enforcer to skip that manual step and automatically accept the Policy Secure
gateway’s certificate, the Infranet Enforcer must have the certificate of the CA that
signed the Policy Secure gateway’s certificate.
4. Create an instance of the Policy Secure gateway on the Juniper security device.
5. Enable SSH.
6. Verify routing from the Policy Secure gateway to the untrust interface.
7. Ensure that both the Infranet Enforcer and the Policy Secure gateway have the
correct time. If possible, use a Network Time Protocol (NTP) server to set the date
Related  Creating a Route Mode Instance with the ScreenOS Enforcer

Documentation
Create a Route Mode Interface with the ScreenOS Enforcer
Before you begin this procedure, you must possess the certificate of the CA that signed
the Policy Secure gateway’s server certificate. If you do not already have an authentic
CA from a trusted source, you must generate a self-signed CA.
After you connect to the Juniper security device and set interface management options,
you can create a Policy Secure gateway instance. You need to name the instance and set
these items:
 IP address or host name of the Policy Secure gateway
 Password to use when the Infranet Enforcer uses NACN to contact the Policy Secure
gateway
 Source interface
 CA index number (ca-idx)

You can set these items using the Web UI or the CLI. Because the Juniper security device
can store more than one Policy Secure gateway instance, you must include the name of
the Policy Secure gateway with each command.
In the following procedure, you first set interface management options and disable the
DCHP server option. Then you enable SSHv2 and configure a Policy Secure gateway
instance named controller1. Next, you set the host IP address, which is the IP address of
the Policy Secure gateway, to 10.64.12.1. The NACN password is 8!JsP37cK9a*_HiEwe.
The NACN password must match the NACN password that you entered for the Policy
Secure gateway. The source interface is the interface that the Infranet Enforcer uses to
communicate with the Policy Secure gateway, and the CA index number is 001. For this
example, the source interface is ethernet 1/1. For a descriptive list of CA index numbers
by typing the following command at the ScreenOS CLI:
get ssl ca-list

You must use the Web UI to import the CA. For more information about certificates, see
the Concepts & Examples ScreenOS Reference Guide: Volume 5, VPNs.
To change SSH versions, delete SSH settings by typing the following CLI command:
delete ssh device all
When you use the Web UI, you do not need to fill in the Full Subject Name of IC Cert field.
If you do fill it in, be sure to enter the entire certificate subject. For example:
CN=ic1.juniper.net,CN=14087306185,CN=06990218,OU=Software,O=Juniper,S=CA, C=US
After you create the Policy Secure gateway instance, set the Policy Secure gateway
with the serial number of the Infranet Enforcer. To view the serial number of the
system, look at the
Device Information pane on the home page of the Web UI or enter the following command
at the CLI:
get system
To perform this task using the Web UI:
To create the instance using the Web UI:
1. Select Network > Interfaces > Edit > Services from the left navigation bar to set
management options.
2. Select Network > DHCP > Edit to disable the DHCP server for both interfaces (Trust
and Untrust).
3. Select and load the CA if you have not already done so.
a. Select Objects > Certificates.
b. Click Browse to find and select the certificate. Then click Load.
c. Select CA from the show list.

d. Click Server Settings and make sure Check Method is set correctly for the certificate
you are using.
e. Click OK.
4. Create the Policy Secure gateway instance.
a. Select Configuration > Infranet Auth > Controllers (List) > New.
b. Type controller1 in the Policy Secure gateway instance box.
c. Type IP/domain name: 10.64.12.1 in the IP/Domain Name box.
d. For the NACN Parameters, select ethernet1/1 from the Source Interface list.
e. Type 8!JsP37cK9a*_HiEwe in the Password box.
f. Select the CA from the Selected CA list.
5. Enable SSH version 2.
a. Select Configuration > Admin > Management > Enable SSH (v2).
To peform this task with the CLI:
To create the instance using the CLI:
1. Type the following commands:
set interface ethernet1/1 manage ssl
set interface ethernet1/1 manage ssh
set interface ethernet1/1 manage ip
set interface ethernet2/1manage ping
set interface ethernet2/1 dhcp server disable
set interface ethernet1/1 dhcp server disable
delete ssh device all
set ssh version v2
set ssh enable
set infranet controller name controller1 host-name 10.64.12.1
set infranet controller name controller1 password 8!JsP37cK9a*_HiEwe
set infranet controller name controller1 src-interface ethernet1/1
set infranet controller name controller1 ca-idx 001
save
Configuring the ScreenOS Connection on page 101

Related
Documentation
 108

Setting Up an Infranet Enforcer in Transparent Mode
In Transparent mode, the Juniper security device is usually installed between a core router
and an access distribution device. Services are enabled at the zone level, and VLAN1 is
used for management.
Transparent mode permits you to implement the following functionality:
 The device can act as a Layer 2 forwarding device, such as a bridge.
 You can control traffic flow between Layer 2 security zones by defining policies.
To configure a ScreenOS Enforcer in Transparent mode:
1. Set up Transparent mode using the predefined security zones, v1-trust and v1- untrust.
a. Assign interfaces to v1-trust and v1-untrust.
b. Configure the IP address for a source interface to establish connectivity with the
Policy Secure gateway. You can use V1-trust, V1-untrust, or V1-dmz.
c. Configure the broadcast mechanism to flooding (default) or ARP/traceroute.

ARP/trace-route is more secure than broadcast.
d. Enable management of the following services for VLAN1:
 SSL
 SSH
 Web (optional)
2. Set up the Juniper security device zones. The protected resources can be in either zone
(v1-trust or v1-untrust) as long as the protected resources are in a zone different from
the endpoints.
The Policy Secure gateway can also reside in either zone. If the Policy Secure
gateway resides in a zone different from the endpoints, configure a policy that allows
traffic to the endpoints through the ScreenOS Enforcer.
certificate into the ScreenOS Enforcer.
Do not import the Policy Secure gateway SSL certificate into the Juniper Networks
security device.
For more information about certificates and certificate options, see the Concepts &
Examples ScreenOS Reference Guide: Volume 5, VPNs.
4. Create an instance of the Policy Secure gateway on the ScreenOS Enforcer.
5. Enable SSH.
6. Verify routing from the Policy Secure gateway to the V1-untrust zone.

To use IPsec enforcement with a ScreenOS Enforcer in Transparent mode, you might
need to configure a source interface policy on the Policy Secure gateway.
7. Ensure that both the Infranet Enforcer and the Policy Secure gateway have the
correct time. If possible, use a Network Time Protocol (NTP) server to set the date
Related  Creating a Transparent Mode Instance with the ScreenOS Enforcer

Documentation
108
Creating a Transparent Mode Instance on the ScreenOS Enforcer
To create a Policy Secure gateway instance in transparent mode, use the CLI to
perform the following actions:
 Assign all interfaces to Layer 2 zones.
 Assign an IP address to vlan1 and set the route command.
 Set interface management options.
 Configure a Policy Secure gateway instance named controller1.
 Set the host IP address, which is the IP address of the Policy Secure gateway, to
10.64.12.1.
 Enter the NACN password. The NACN password is 8!JsP37cK9a*_HiEwe. The NACN
password must match the NACN password that you entered for the Policy Secure
gateway.
 The source interface, vlan1, is the interface that the Infranet Enforcer uses to
communicate with the Policy Secure gateway. The CA index number is 001. For a
descriptive list of CA index numbers type the following CLI command:
get ssl ca-list

You must use the Web UI to import the CA.
To create the instance using the CLI:
1. Type the following commands at the CLI:
NOTE: For the firewall to operate in Transparent (Layer 2) mode, all interfaces
must be in a Layer 2 zone, such as v1-trust or in the null zone. Interfaces cannot
remain in a Layer 3 zone.
set interface eth1 zone v1-trust
set interface eth2 zone v1-untrust
set interface vlan1 ip 10.64.12.x
set interface vlan1 route
set interface vlan1 ip manageable
unset interface vlan1 manage ping

unset interface vlan1 manage telnet
unset interface vlan1 manage snmp
unset interface vlan1 manage web
set infranet controller name controller1 host-name 10.64.12.1
set infranet controller name controller1 password 8!JsP37cK9a*_HiEwe
set infranet controller name controller1 src-interface vlan1
set infranet controller name controller1 ca-idx 0001

Documentation
 Configuring the ScreenOS Connection on page 101

Viewing the Configuration of a Policy Secure gateway on the ScreenOS Enforcer
This topic describes how to view details about the Pulse Policy Secure configuration
from the ScreenOS user interfaces. It includes the following information:
 Configuration Details Displayed on page 108

 Web UI on page 108
 CLI on page 109
Configuration Details Displayed

You can view the configuration of a Policy Secure gateway instance through the Web UI
and the CLI. You can view the following information:
 Name of the Policy Secure gateway instance
 IP address or domain name of the Policy Secure gateway
 Port number ( always 11122)
 Timeout (60 seconds by default)
 Source interface
The Web UI also allows you to view the NACN password.
Web UI
To view configuration information on the Web UI select the following:
1. Configuration > Infranet Auth > Controllers from the left navigation bar.
2. Configuration > Infranet Auth > General Settings from the left navigation bar.

CLI
To view configuration information at the CLI, type the following command:
1. get infranet controller name controller1

Documentation

Understanding the Infranet Enforcer Captive Portal Feature
When you deploy the Policy Secure gateway and Infranet Enforcer, users may not
know that they must first sign into the Policy Secure gateway for authentication and
endpoint security checking before they can access a protected resource behind the
Infranet Enforcer.
To facilitate sign-in, you can configure either a redirect infranet auth policy on the
ScreenOS Enforcer or a security policy on the Junos Enforcer to automatically redirect
HTTP traffic destined for protected resources to the Policy Secure gateway. This feature
is called captive portal. When the sign-in page for the Policy Secure gateway is
displayed, the user signs in and Host Checker for OAC or Pulse or agentless Host
Checker examines the endpoint for compliance with security policies, and if the
endpoint passes the security check, access is granted to the protected resource.
Captive portal is supported on both the ScreenOS Enforcer and the Junos Enforcer.
You can configure captive portal for endpoint clients that use either source IP enforcement
or IPsec enforcement, or a combination of both methods.
Figure 8 on page 109 illustrates the sequence of events when a user attempts to access
protected resources with captive portal configured.
Figure 8: Captive Portal Event Flow

Captive portal enables an endpoint to be redirected to a different URL when the user
attempts to access a protected resource behind an Infranet Enforcer, provided the
appropriate access policies are configured on the security device. By default, users are
not redirected if captive portal is not configured for a policy.
Related Before Configuring Captive Portal on page 110

Documentation
 Creating a Redirect Policy on the Infranet Enforcer on page 111

 Overriding the Default Redirection Destination for Captive Portal on page 112
Before Configuring Captive Portal
Topic Details
ScreenOS version The captive portal feature requires ScreenOS Release 5.4 or later running
on the ScreenOS Enforcer.
Junos version To use captive portal with the Junos Enforcer, Release 10.2 is required.
External Web server You can configure the ScreenOS Enforcer to redirect HTTP traffic to an
external Web server instead of the Policy Secure gateway. For example,
you can redirect HTTP traffic to a Web page that explains to users the
requirement to sign into the Policy Secure gateway before they can
access the protected resource. You can also explain the security policy
and include a link to the Policy Secure gateway on that Web page to
help users sign in.
HTTP vs. HTTPS The captive portal feature redirects HTTP traffic only. If the user attempts
to access a protected resource using HTTPS or another protocol such
as SMTP, the Infranet Enforcer does not redirect the user’s traffic. When
using HTTPS or another application, the user must manually sign into
the Policy Secure gateway first before attempting to access protected
resources.
HTTP proxy If there is an HTTP proxy between the endpoint and the Infranet Enforcer,
the Infranet Enforcer might not redirect the HTTP traffic.
Default port In standard configurations, ScreenOS uses default HTTP ports as the
redirect destination port for traffic. In addition to default HTTP ports,
nonstandard HTTP port 3128 is defined for HTTP-EXT traffic to
accommodate the SQUID proxy.
The Junos Enforcer, supports only port 80.

Creating a Redirect Policy on the Infranet Enforcer
To configure the captive portal feature, you must create special policies on the Infranet
Enforcer. On the Junos Enforcer, you configure a security policy using the CLI. On the
ScreenOS Enforcer, you can configure an infranet auth policy through either the Web UI
or the CLI.
When you configure a policy for captive portal, you can redirect all traffic or only
unauthenticated traffic.
 unauthenticated—Select this option if your deployment uses source IP only or a

combination of source IP and IPsec. The Infranet Enforcer redirects clear-text traffic
from unauthenticated users to the currently connected Policy Secure gateway, or
to an IP address or domain name that you specify in a redirect URL.
After a user signs in to the Policy Secure gateway and the user’s endpoint system
meets the requirements of the Policy Secure gateway’s security policies, the Infranet
Enforcer allows the user’s clear-text traffic to pass through in source IP deployments.
For IPsec deployments, OAC or Pulse create a VPN tunnel between the user and the
Infranet Enforcer. The Infranet Enforcer then applies the VPN policy that allows the
encrypted traffic to pass through.
 all—Select this option if your deployment uses IPsec only. The Infranet Enforcer redirects
all clear-text traffic to the currently connected Policy Secure gateway, or to an IP
address or domain name that you specify in a redirect URL.
After a user signs in to the Policy Secure gateway, OAC or Pulse creates a VPN tunnel
between the user and the Infranet Enforcer. The Infranet Enforcer then applies the
VPN policy that allows the user’s encrypted traffic to pass through. This option does
not allow clear text traffic to pass through the Infranet Enforcer, which protects the
network from IP spoofing.
From the Junos CLI
To enable captive portal, associate an instance of a captive portal with a security zone
use the following command format:
user@host# set security policies from-zone zone-name to-zone zone-name policy policy-name
To create the captive portal use the following command format:
user@host# permit application-services uac-policy captive-portal captive-portal-name

You can redirect all traffic, or only unauthenticated traffic on the Junos Enforcer using
the following command format:
edit services unified-access-control captive-portal policy redirect-traffic (all | unauthenticated)

From the ScreenOS Web UI
To create a redirect infranet auth policy on the ScreenOS Enforcer:
1. Click Policies on the left navigation bar.
2. Select a source zone from the From list.
3. Select a destination zone from the To list.

4. Click New. The advanced Policy Settings page is displayed.
5. Enter the policy configuration information such as source and destination addresses.
For more about policy configuration options, see the ScreenOS Enforcer Web UI online
help.
6. Click Advanced.
7. Select Authentication, then select Infranet-Auth.
8. Specify one of the following redirection options for the infranet auth policy:
 Redirect unauthenticated traffic
 Redirect all traffic
9. (Optional) Enter a Redirect URL that specifies where to redirect matching traffic.
10. Click OK.
11. Click OK again.
You can permit more versatile redirect support on a per-policy basis. If your Infranet
Enforcer connects to different Policy Secure gateways (though only one at a time can
communicate), you can configure the URL for each redirect policy. If a policy-based URL
is defined and redirect is enabled in the policy, unauthenticated HTTP traffic that matches
the policy is redirected to that URL even if a global redirect URL is configured. If
policy-based URL redirect is not defined and redirect is enabled, unauthenticated traffic
that matches the policy is redirected to the global redirect.
From the ScreenOS CLI
To configure a redirect infranet auth policy for deployments that use either source IP only
or a combination of source IP and IPsec type the following command:
set policy from source-zone to dest-zone src_addr dst_addr any permit infranet-auth
redirect-unauthenticated
To configure a redirect infranet auth policy for deployments that use IPsec only type the
following command:
set policy from source-zone to dest-zone src_addr dst_addr any permit infranet-auth redirect-all
Overriding the Default Redirection Destination for Captive Portal
By default, after you configure a redirect infranet auth policy for ScreenOS, the Infranet
Enforcer redirects HTTP traffic to the currently connected Policy Secure gateway using
HTTPS. To perform the redirection, the Infranet Enforcer uses the IP address or domain
name that you specified when you configured the Policy Secure gateway instance on
the Infranet Enforcer. The format of the URL that the ScreenOS Enforcer uses for
default redirection is:
https://<connected IC-Series-device IP or domain name>/?target=%dest-url%

If you configured your ScreenOS Enforcer to work with multiple Policy Secure gateways
in a cluster, and the current Policy Secure gateway becomes disconnected, the
ScreenOS Enforcer automatically redirects HTTP traffic to the next active Policy Secure
gateway in its configuration list. The ScreenOS Enforcer redirects traffic to only one
Policy Secure gateway at a time.

The Policy Secure gateway domain name that you specify when configuring the Policy
Secure gateway instance in the ScreenOS Enforcer must match the Policy Secure
gateway domain name in the Web browser certificate that is used when users sign in.
Otherwise, the browser displays a certificate warning when users sign in.
You do not need to override the default redirection destination except in the following
situations:
 You are using a VIP for a cluster of Policy Secure gateway appliances, and the
ScreenOS Enforcer is configured to connect to the Policy Secure gateway’s
physical IP addresses.
 You want to redirect traffic to a Web server instead of to the Policy Secure gateway.
 If, because of split DNS or IP routing restrictions at your site, the ScreenOS Enforcer
uses a different address for the Policy Secure gateway than endpoints, you must
specify the domain name or IP address that endpoints must use to access the Policy
Secure gateway.
By default, the ScreenOS Enforcer also encodes and forwards to the Policy Secure
gateway the protected resource URL that the user entered. The Policy Secure gateway
uses the protected resource URL to help users navigate to the protected resource. The
manner in which the Policy Secure gateway uses the protected resource URL depends
on whether or not the user’s endpoint is running OAC or Pulse.
 If the user’s endpoint is not running OAC or Pulse (that is, it is in an agentless or Java
agent configuration), the Policy Secure gateway automatically opens a new browser
window and uses HTTP to access the protected resource after the user signs in.
 If the endpoint is using OAC or Pulse, the Policy Secure gateway inserts a link in the
Web page that automatically opens after the user signs in. The user must then click that
hypertext link to access the protected resource by means of HTTP in the same
browser window.
To override the default redirect destination, you must configure policies on the Infranet
Enforcer. On the Junos Enforcer, you configure a redirect–url policy using the CLI. On the
ScreenOS Enforcer, you can configure an infranet auth policy through either the Web UI
or the CLI.
Creating a Redirect Policy on the Junos Enforcer
In a Junos Enforcer security policy, specify the redirect URL in the following format:
user@host# set services unified-access-control captive-portal policy redirect-url url

By default, after you configure a captive portal policy, the JUNOS Enforcer redirects HTTP
traffic to the currently connected Policy Secure gateway by using HTTPS. To perform
the redirection, the JUNOS Enforcer uses the IP address or domain name that you
specified when you configured the Policy Secure gateway instance on the JUNOS
Enforcer.
You specify the redirect url in a Junos Enforcer security policy using the following hierarchy:
user@host# https://%ic-ip%/?target=%dest-url%=%enforcer-id%=%policy-id%=%dest-ip%
These are the four available parameters for redirection.
 target

 enforcer

 policy
 dest-ip
Target, enforcer, and policy are required. Dest-ip is optional. For example:
redirect-url
"https://acmegizmo.juniper.net/?target=%dest-url%&enforcer=%enforcer-id%&policy=%policy-id%"
If you do not specify the redirect URL, the Junos Enforcer uses the default configuration.
NOTE: To set a redirect URL for the Junos Enforcer, use escape characters
instead of dot (.). For example:
“https://192.168.0.100/agentless/?target=http%3A%2F%2Fwww%2Ejuniper%2Enet”.
For configuration instructions and examples, see the Junos OS Initial Configuration Guide
for Security Devices.
Related Understanding the Infranet Enforcer Captive Portal Feature on page 109
Documentation

Creating a Redirect Policy on the ScreenOS Enforcer
From the ScreenOS Web UI
1. Select Configuration > Infranet Auth > Controllers > Edit from the left navigation bar.
2. In the Redirect URL box, specify the IP address or domain name of the Policy Secure
gateway or external Web server using HTTP or HTTPS in the following format:
https://<IP or domain name>/<url path>/?target=%dest-url%
For example, to redirect to a Policy Secure gateway and forward the protected
resource URL, enter:
https://abc.company.com/?target=%dest-url%
To redirect to a Web server and forward the protected resource URL enter:
https://server1.company.com/cgi-bin/redirect.cgi?target=%dest_url%
The ScreenOS Enforcer replaces the %dest-url% parameter with the protected
resource URL, and then forwards the protected resource URL in encrypted form to
the Policy Secure gateway.

NOTE: In the Redirect URL string, you can omit the ?target=%dest-url%
string. For example:
http://server1.company.com
If you do not include the ?target=%dest-url% string, the user must manually
open a new browser window and enter the protected resource URL again
after signing in.
From the ScreenOS CLI
1. To specify the redirect URL, enter:
set infranet controller name controller1 url "http://10.64.12.1/?target=%dest-url%"

2. To specify the redirect URL without the ?target=%dest-url% string, enter:
set infranet controller name controller1 url http://abc.company.com
Non standard Ports
With ScreenOS Release 6.3, captive portal supports HTTP traffic on any port. To use this
feature, you must define a new service on ScreenOS, and use the service in an infranet
auth policy.
You define the service with the destination ports on which HTTP is running. Select this
service in the infranet auth policy, and associate it with application “HTTP”.
For unauthenticated HTTP traffic on the port specified in the service, ScreenOS redirects
the traffic to the URL that is mentioned in the Inranet Controller configuration or that is
mentioned in the Redirect URL field of the infranet auth policy.
To configure an alternative port for redirct:
From the Web UI
1. Create a new service in ScreenOS.
2. Create an infranet auth policy and select DSTA-HTTP (or the name you are using
when you create the service) as the service in the infranet-auth policy.
3. Set the application as HTTP for the policy.
From the CLI
Type the following commands:
set service DSTA-HTTP protocol tcp dst-port 6060-6060
set policy id 1 from trust to untrust any any DSTA-HTTP permit infranet-auth
redirect-unauthenticated
set policy id 1 application HTTP

For unauthenticated HTTP traffic on the specified port, ScreenOS redirects the traffic to
the URL that is specified in the Policy Secure gateway configuration, or to the one that
is mentioned in the Redirect URL field of the infranet auth polcy.

If nonstandard ports are not used in the infranet-auth policy, the behavior is the same
as in ScreenOS Release 6.2.
Related Understanding the Infranet Enforcer Captive Portal Feature on page 109
Documentation

Understanding Deployments with ScreenOS Enforcer Virtual Systems
This topic describes deployments with ScreenOS virtual systems. It includes the following
information:
 ScreenOS Virtual Systems Overview on page 116

 Overlapping IP Addresses on page 117
 Deployment Example on page 118
 Deployment with IF-MAP Federation Example on page 119
ScreenOS Virtual Systems Overview

You can logically partition a single ScreenOS Enforcer into multiple virtual systems (vsys)
to provide multitenant services. Each vsys is a unique security domain and can have its
own administrator. vsys is supported on ISG1000, ISG2000, and NS5000 series ScreenOS
Enforcers.
Support for vsys on the Policy Secure gateway allows you to provision different auth table
entries and resource access policies on discrete vsys on the same firewall. You can also
choose a vsys for ScreenOS infranet auth policies and VPN objects.
When you add a vsys to a ScreenOS Enforcer with the appropriate CLI commands, the
vsys appears as an Infranet Enforcer on the Policy Secure gateway. For more
information, see http://www.juniper.net/techpubs/en_US/release-independent/screenos/information-products/pathway-
pages/screenos/product/index.html.
On Policy Secure gateways, the vsys appears as a standalone firewall device. You
configure policies on the vsys just as you do for a separate firewall.
For resource access policies and auth table policies, you add a vsys by entering its name
in the provided field. For Enforcer policies, you select the vsys from a list. This is because
resource access policies and auth table policies can be distributed to multiple ScreenOS
Enforcers, while Enforcer policies apply to only one ScreenOS Enforcer.
Virtual systems do not inherit resource access policies or auth table policies from the
root-vsys (the ScreenOS Enforcer on which the vsys is created). If a resource access
policy or auth table policy is configured for an existing ScreenOS Enforcer, and you
subsequently create one or more vsys, you must add new policies for the vsys to allow
users to access resources behind the vsys.
If you enable command tracing in the event log, the
exec-bulkcli
command is displayed in the log for vsys events.

You can configure multiple vsys with no shared zones, or you can configure different vsys
to share a common zone. For example, you can configure all endpoints to be on the
untrust zone connecting to multiple vsys in different zones. IPsec is not supported with
a shared-zone configuration. Figure 9 on page 117 shows multiple vsys in shared and
unshared zones.
Support for vsys on the Policy Secure gateway requires ScreenOS Release 6.2 or later.
Figure 9: Multiple vsys in Shared and Unshared Zones
When a ScreenOS Enforcer Release 6.2 or later and the appropriate vsys licensing
connects to the Policy Secure gateway, the Policy Secure gateway automatically
issues a command to the firewall to enable UAC support for vsys in ScreenOS
Enforcers.
Overlapping IP Addresses
On ScreenOS, each vsys can have individual administrators, and one or more vsys can
be assigned to a single customer. For example, a service provider can provision different
vsys to different customers. In turn, these customers might use overlapping IP addresses
in their internal networks. For instance, many organizations use the internal IP address
range 192.168.0.0 – 192.168.255.255. For ScreenOS, this is not an issue because the

ScreenOS Enforcer supports overlapping IP addresses. Previous releases of UAC did not
support overlapping IP addresses. As a result, the Policy Secure gateway was unable to
distinguish between two authorized users with matching addresses. With UAC Release
4.1, if the administrator creates mappings on the Policy Secure gateway as described in
this section, the Policy Secure gateway can recognize users with identical IP addresses
in multiple vsys, and the correct session information is sent to the ScreenOS firewall
auth table.
In the preceding scenarios, customer networks use the same internal IP address ranges
supplied by different service providers. When overlapping IP addresses occur among
different customer networks, if an IC administrator has created a mapping between the
VLAN and vsys, the Policy Secure gateway can use this mapping to correctly identify the
user and to send accurate session information to ScreenOS.
Deployment Example
In the following deployment, (see Figure 10 on page 119) authentication to the service
provider occurs through UAC on the Policy Secure gateway. On this network, different
VLANs and different firewalls are configured on the service provider side for each
customer network. Both customer networks use the same IP address ranges. When
the Policy Secure gateway correctly identifies and authenticates a user from one of the
customer networks who attempts to access a protected resource on the server
provider side, the following occurs:
 With the first login attempt, the Policy Secure gateway knows the user’s VLAN.
 When the user attempts to access a protected resource, the firewall drops the first
packet.
 With the user’s next access attempt (resend), the firewall sends the Policy Secure
gateway the vsys and source IP address.
 If the Policy Secure gateway administrator has configured a mapping on the IC

between the VLAN and the vsys for the firewall on which each customer network is
connected, the Policy Secure gateway can use the source IP and the VLAN ID to
correctly identify the user session. This allows the Policy Secure gateway to provide
session information for the ScreenOS auth table. (Note that the VLAN ID is part of the
user session information.)

Figure 10: Layer 3 Authentication with Overlapping IP Addresses
Deployment with IF-MAP Federation Example

In the following deployment, (see Figure 11 on page 120) the network configuration is
similar to the preceding example, except that the service provider uses two Policy
Secure gateways and both are in a Federated network. Both customer networks use the
same IP address ranges. In order for the Policy Secure gateway that controls access to
the protected resource to correctly identify and authenticate a user who attempts
access from one of the customer networks, the following events occur:
 When the user logs in to the first Policy Secure gateway, the Policy Secure gateway
correctly identifies the user’s VLAN. The Policy Secure gateway publishes information
about the user session to the IF-MAP server. If the Policy Secure gateway
administrator has configured a mapping on the first Policy Secure gateway between
the VLAN and an administrative domain, the Policy Secure gateway publishes the
source IP address with the administrative domain.
 When the user attempts to access a protected resource, the firewall drops the first
packet and identifies the vsys and the source IP address to the second Policy Secure
gateway. The second Policy Secure gateway looks up the source IP address in the IF-
MAP server to obtain session information so it can provision the ScreenOS auth table.
If the Policy Secure gateway administrator has configured a mapping on the second
Policy Secure gateway between the vsys and the VLAN, and between the VLAN and
an administrative domain, the second Policy Secure gateway looks up the
combination of the source IP address and administrative domain.

 With the user’s next access attempt (resend), the firewall is provisioned and forwards
the packet to the protected resource.
Figure 11: IF-MAP Authentication with Overlapping IP Addresses
Related Configuring the Policy Secure gateway for Overlapping IP Addresses on page 120
Documentation

Configuring the Policy Secure gateway for Overlapping IP Addresses
To configure overlapping vsys IP addresses with an Infranet Enforcer with vsys mapping:
NOTE: Before you perform this configuration, you must first add Infranet
Enforcer vsys and VLANs.
1. To map a vsys with a VLAN, in the admin console, select UAC > Infranet Enforcer >
VYSYS Mapping.
2. Under Mapping with vsys, select an available vsys. Select an available VLAN.

To configure overlapping vsys IP addresses with IF-MAP Federation using the

administrative domain:
1. Select UAC > Infranet Enforcer > VYSYS Mapping.
2. Under Mapping with Administrative Domain, select an available vsys. Select an

administrative domain.
To configure overlapping vsys IP addresses with the Infranet Enforcer and IF-MAP
Federation using the administrative domain and vsys mapping:
1. Select System > IF-MAP Federation > Administrative Domain.
2. Under Mapping with Administrative Domain, select an available VLAN. Select an

administrative domain.
NOTE: Administrators should note the following when dealing with

overlapping IP addresses:
 Overlapping IP address configurations are not supported in environments

with mixed deployments of SRX and ISG devices.
 Two VLANs with overlapping addresses should not be configured to the

same vsys.
 For overlapping vsys IP addresses with IF-MAP Federation using the

administrative domain, both the IF-MAP client and server should have
identical Administrative Domain - VLAN mappings. If there is a mismatch,
authentication table entries on the firewall may not update correctly for
federated users who become local users on the IC to which the firewall is
connected.
 IDP is not supported with overlapping IP addresses.
Related Understanding Deployments with ScreenOS Enforcer Virtual Systems on page 116
Documentation

IPsec Policies
This section describes the policies that you configure to use IPsec on the Infranet Enforcer.
 IPsec Routing Policy—Specifies which Infranet Enforcer an endpoint must use to

access a resource. This policy also specifies whether that resource requires an IPsec
tunnel for endpoints to access it. Note that an IPsec tunnel does not automatically
give the endpoint access. You configure IPsec routing policies on the Policy Secure
gateway.
 ScreenOS Infranet Auth IPsec Policy—Contains the source and destination. The
Policy Secure gateway uses the source and destination to set up a user, user group,
IKE gateway,

and VPN for each source interface in the source zone of the policy. You can set up a
basic ScreenOS IPsec policy on the Policy Secure gateway and push the policy to the
ScreenOS Enforcer, or you can set up the policy using ScreenOS Web UI or the
command line.
 IP Address Pools Policy—Specifies a pool of virtual IP addresses that you want the
Policy Secure gateway to automatically assign to endpoints in NAT environments that
use IPsec tunnels to the Infranet Enforcer. You configure IP address pools policies on
 ScreenOS Source Interface Policy—Specifies the source interface on the ScreenOS

Enforcer that receives traffic from endpoints if the ScreenOS Enforcer is in Transparent
mode. You create this type of policy only if you want endpoints to use IPsec to
communicate with a ScreenOS Enforcer that is in Transparent mode, and you are using
virtual routers. You configure source interface policies on the Policy Secure gateway.
 Junos Enforcer Security Policy—On the Junos Enforcer, security policies are used to
define the source and destination address, the application, and the phase 2 policy. You
configure security policies on the Junos Enforcer. You cannot configure security policies
Related Using IPsec with the Infranet Enforcer on page 122

Documentation

 Configuring ScreenOS Enforcer IPsec Encryption Settings on page 138
Using IPsec with the Infranet Enforcer
On supported endpoints that use OAC or Pulse, you can use IPsec enforcement to encrypt
the traffic between an endpoint and the ScreenOS Enforcer, thereby adding another of
protection for network assets.
IPsec is not supported on agentless or Java agent endpoints, or on endpoints that connect
by means of non-UAC software. For these clients, you must use source IP enforcement
instead.
To use IPsec enforcement, you set up a VPN tunnel with IKE (Internet Key Exchange) on
the Infranet Enforcer. You can configure IPsec enforcement by creating IPsec routing
policies on the Policy Secure gateway. For IPsec on the ScreenOS Enforcer, you can
create basic IPsec policies. For IPsec with the Junos Enforcer, you must create security
policies on the device.
Alternatively, you can set up the VPN tunnel manually using ScreenOS CLI commands
or Web UI. We recommend that you use the Policy Secure gateway to set up basic VPN
policies on the Infranet Enforcer. If necessary, you can modify the VPN tunnel setup
afterwards on the Infranet Enforcer by using ScreenOS CLI commands or Web UI.
If you modify the VPN tunnel setup on the Infranet Enforcer by using the ScreenOS CLI
commands or Web UI, you must refresh the policies on the Policy Secure gateway.

When you use the Policy Secure gateway to configure IPsec on the ScreenOS Enforcer,
the Policy Secure gateway sets up a user, user group, IKE gateway, and VPN for each
source interface in the source zone of the policy, in addition to the policy itself. The
Policy Secure gateway uses the source interface number and the ID of the destination
zone to uniquely name each of these objects.
For IPsec with the Junos Enforcer you use the CLI to create security policies. With the
Junos Enforcer, the Policy Secure gateway uses the destination zone to match the IPsec
routing policies that are configured on the Policy Secure gateway.
Related Setting Up ScreenOS Enforcer IPsec Routing Policies on page 137

Documentation

Understanding Pulse Policy Secure Support for IPsec Routing Policies
This topic provides an overview of Pulse Policy Secure support for IPsec routing
policies. It includes the following information:
 About IPsec on page 123

 Access Solution Service Client Support for IPsec Routing Policies on page 123
 Infranet Enforcer Support for IPsec Routing Policies on page 124
 Infranet Enforcer IPsec Policy Features on page 124
 Dynamic IPsec Routing Policies with ScreenOS Enforcers on page 125
 Refreshing IPsec Policies on the IC Series on page 125
About IPsec
IP Security (IPsec) is a suite of related protocols for cryptographically securing
communications at the IP Packet Layer. IPsec also provides methods for the manual and
automatic negotiation of security associations (SAs) and key distribution.
An IPsec tunnel consists of a pair of unidirectional SAs – one at each end of the tunnel
– that specify the security parameter index (SPI), destination IP address, and security
protocol. In a dial-up VPN, there is no tunnel gateway on the VPN dial-up client end of
the tunnel. Rather, the tunnel extends directly to the client itself.
IPsec routing policies allow you to specify the parameters for SAs between endpoints
and the Infranet Enforcer.
Access Solution Service Client Support for IPsec Routing Policies

OAC and Pulse support IPsec using IKEv1 with XAuth. For the client to establish an IPsec
tunnel, it must retrieve configuration information from the Infranet Enforcer. This
information is forwarded to The Policy Secure gateway by the respective device. When a
user with OAC or Pulse signs in to the Policy Secure gateway, these configuration
details are passed on to the client to establish an IPsec tunnel with the Infranet
Enforcer.
To set up IPsec for endpoints with OAC or Pulse, you configure policies on the Policy
Secure gateway and on the security device. The Policy Secure gateway pushes the
required IPsec

configuration parameters to the client when the client first attempts to connect to a
protected resource behind and Policy Secure gateway for which IPsec has been
configured.
IPsec is not supported on agentless or Java agent endpoints, or on endpoints that connect
by means of non-UAC software. For these clients, you must use source IP enforcement
instead. Source IP enforcement allows endpoints to communicate with unencrypted
traffic.
Infranet Enforcer Support for IPsec Routing Policies

IPsec is supported on both the ScreenOS Enforcer and the Junos Enforcer (beginning in
Release 10.0).
On the Infranet Enforcers, you set up a VPN tunnel with IKE (Internet Key Exchange).
For Junos Enforcers, you use the Junos OS user interface to configure the Junos Enforcer
IPsec security zones and IPsec routing policy settings. The Pulse Policy Secure IPsec
routing policies match the destination zone set in the Junos OS configuration.
For the ScreenOS Enforcer, you can use the Pulse Policy Secure user interface to
configure basic IPsec policies and then push them to the ScreenOS Enforcer. Alternatively,
you can use the ScreenOS user interface to set up the VPN tunnel. We recommend that
you use the Pulse Policy Secure user interface. When you use Pulse Policy Secure user
interface to set up the IPsec routing policy, you specify a user, user group, IKE gateway, and
VPN for each source interface in the source zone of the policy, in addition to the policy
itself. The Pulse Policy Secure uses the source interface number and the ID of the
destination zone to uniquely name each of these objects.
NOTE: If necessary, you can later use the ScreenOS user interface to modify
the VPN tunnel configuration. Whenever you modify the VPN tunnel setup
from the ScreenOS side of the configuation, you must refresh the Pulse
Policy Secure policies.
Infranet Enforcer IPsec Policy Features

This section describes the policies that you configure to use IPsec on the Infranet Enforcer.
 IPsec Routing Policy—Specifies which Infranet Enforcer an endpoint must use to

access a resource. This policy also specifies whether that resource requires an IPsec
tunnel for endpoints to access it. Note that an IPsec tunnel does not automatically
give the endpoint access. You configure IPsec routing policies on the Policy Secure
gateway.
 ScreenOS Infranet Auth IPsec Policy—Contains the source and destination. The
Policy Secure gateway uses the source and destination to set up a user, user group,
IKE gateway, and VPN for each source interface in the source zone of the policy. You
can set up a basic ScreenOS IPsec policy on the Policy Secure gateway and push the
policy to the ScreenOS Enforcer, or you can set up the policy using ScreenOS Web UI
or the command line.
 IP Address Pools Policy—Specifies a pool of virtual IP addresses that you want the
Policy Secure gateway to automatically assign to endpoints in NAT environments that
use IPsec
tunnels to the Infranet Enforcer. You configure IP address pools policies on the Policy
Secure gateway.
 ScreenOS Source Interface Policy—Specifies the source interface on the ScreenOS

Enforcer that receives traffic from endpoints if the ScreenOS Enforcer is in Transparent
mode. You create this type of policy only if you want endpoints to use IPsec to
communicate with a ScreenOS Enforcer that is in Transparent mode, and you are using
virtual routers. You configure source interface policies on the Policy Secure gateway.
 Junos Enforcer Security Policy—On the Junos Enforcer, security policies are used to
define the source and destination address, the application, and the phase 2 policy. You
configure security policies on the Junos Enforcer. You cannot configure security policies
Dynamic IPsec Routing Policies with ScreenOS Enforcers

Depending on the version of ScreenOS you are using, the steps for configuring IPsec
differs. If you are using ScreenOS Release to 6.1 and earlier, you configure ScreenOS IPsec
policies and an IPsec routing policy for each resource that you want to protect. With
ScreenOS Release 6.1 or later the Policy Secure gateway can dynamically provision IPsec
routing policies for you, eliminating the need to configure a separate policy for each
resource.
The Policy Secure gateway initially queries all connected Infranet Enforcers for version
information. If ScreenOS Release 6.1 or greater is detected, the Policy Secure gateway
initiates a command to enable dynamic provisioning.
When an authenticated endpoint without an auth table entry attempts to access a

resource through the Infranet Enforcer, the Infranet Enforcer sends a message to the
Policy Secure gateway that includes the source and destination IP, the source interface
on which the dropped packet was received, and the ID of the Enforcer policy associated
with the resource. The Policy Secure gateway uses this information to negotiate an
IPsec tunnel between the endpoint and the Infranet Enforcer and provision a dynamic
IPsec routing policy.
Refreshing IPsec Policies on the IC Series

Each time the Infranet Enforcer and Policy Secure gateway establish a new connection
with each other, the Policy Secure gateway queries the Infranet Enforcer for policy
information, which it uses for provisioning IPsec to endpoints. If you modify the IPsec
policies on the Infranet Enforcer while the Infranet Enforcer is connected to the Policy
Secure gateway, you must refresh the policies on the Policy Secure gateway so that the
Policy Secure gateway uses the new policies, otherwise, the Policy Secure gateway
continues to use the older policies until the next time it disconnects from and
reconnects to the Infranet Enforcer.
Related Understanding IPsec Routing Policy Configuration Options on page 126

Documentation


Understanding IPsec Routing Policy Configuration Options
This topic provides an overview of IPsec routing policy configuration options. You should
become familiar with these options before you begin the configuration tasks. This topic
includes the following information:
 Configuration Overview on page 126

 Advanced Configuration Options on page 127
Configuration Overview
An IPsec routing policy specifies which Infranet Enforcer the device endpoints must use
to access resources when using IPsec. The IPsec routing policy also specifies that
endpoints must use an IPsec tunnel to the Infranet Enforcer to access resources.
To use IPsec with ScreenOS Release 6.1 or earlier, you must configure separate IPsec
routing policies for different resources that you wish to protect. IPsec routing policies are
specific to the resources that you add.
If you are using Screen OS Release 6.1 or later, you can configure one dynamic IPsec
routing policy for each destination zone on each Infranet Enforcer.
In IPsec routing policies with ScreenOS Release 6.1 earlier, you can specify a range of
exceptions for traffic to certain resources that you do not want to use IPsec. The
exceptions can fall within the ranges of resources that the Infranet Enforcer protects. In
this case, if you create an exception for traffic that flows through the Infranet Enforcer,
you must also create another policy on the Infranet Enforcer that allows the exception
traffic to flow through.
For example, you might create an IPsec routing policy that uses IPsec for 0.0.0.0/0 (the
entire network). In the same policy, you can specify the resources that are exceptions
and that do not use IPsec, such as 172.24.80.30 (the Policy Secure gateway),
172.24.80.31 (the Infranet Enforcer), and 172.24.144/21 (a wireless network).
With ScreenOS Release 6.1 or later, policy exceptions are unnecessary. Dynamic IPsec
routing ensures that IPsec tunnels are created only for destinations that are governed
by the ScreenOS IPsec policy.
Table 13: Configuration Topics
Topic Details
Connection The Infranet Enforcer and the Policy Secure gateway must be connected before you use the
IC Seri

Table 13: Configuration Topics (continued)

Topic Details
IPsec access server on ScreenOS Enforcer You cannot establish an IPsec tunnel if IAS (IPsec access server) is enabled on the ScreenOS
command on the ScreenOS Enforcer Command Line Interface:
get ipsec access_session status
To turn off IAS, use the following command:
unset ipsec access-session enable.
For details about this functionality, see

http://www.juniper.net/techpubs/en_US/release-independent/screenos/informatio
Multiple interfaces If you configure IPsec enforcement for an Infranet Enforcer that has multiple interfaces in the
VPN, and tunnel policy for each interface. To distinguish the tunnel policies, the IC Series dev
column on UAC > Infranet Enforcer > Enforcer Policies after you click Save Changes.
Dynamic IPsec routing policies If you are using ScreenOS Release 6.1 or later you can configure the Infranet Enforcer to dyna
you create a ScreenOS source IP policy with a source and destination zone that matches the
source IP policy. Dynamic IPsec routing policies are not supported on the Junos Enforcer.
Default encryption settings on the ScreenOS Enforcer When you use the Policy Secure gateway to configure IPsec on the Infranet Enforcer, the IC
Series d
encryption settings: NoPFS, ESP, 3DES, and SHA1. You can, however, change the phase 2 pro
Bi-directional VPN policy To connect from a computer inside the protected network back to the endpoint, you can cre
CLI commands To include the CLI commands that the Policy Secure gateway sends to the Infranet Enforcer
in the IC
(select System > Log/Monitoring > Events > Settings).
Junos Enforcer zone limitation On the Junos Enforcer, only one IPsec VPN tunnel per “from-zone” to “to-zone” is supported.
Troubleshooting To troubleshoot your IPsec configuration, you can view the Event logs on the Policy Secure
gateway
Tools > Diagnostics > IPsec Diagnostics in OAC.
Advanced Configuration Options
Topic Details
IP address Do not use IPsec for the Policy Secure gateway, the Infranet Enforcer, and networks where your
exceptions endpoints are located. For example, if you create an IPsec routing policy that uses IPsec on an entire
network range (such as 0.0.0.0/0) for your protected resources, be sure to specify exceptions in the
same policy for the IP addresses assigned to Policy Secure gateway, Infranet Enforcer, and the
endpoints.
UDP encapsulation For maximum inter-operability with other third-party IPsec clients, select both Always use UDP
and virtual adapters encapsulation and Always use a virtual adapter. When both options are selected, Network address
translation (NAT) is simulated even if a NAT device is not present. We recommend that you select both
options or neither option. For example, if an endpoint contains two network interfaces, such as a wired
and a wireless interface, and a NAT device is not present between the endpoint and the Infranet Enforcer.
If the endpoint does not access a protected resource by using the interface that is connected to the
network where the Infranet Enforcer is installed, then the user cannot access the protected resource
through either interface without a virtual adapter. Because the Policy Secure gateway does not
automatically install a virtual adapter unless a NAT device is detected, enable the Always use a virtual
adapter option to simulate NAT and force the use of a virtual adapter for this use case.

Related Using the Pulse Policy Secure User Interface to Create Basic ScreenOS Enforcer
Documentation IPsec Policies on page 136
  Setting Up ScreenOS Enforcer IPsec Routing Policies on page 137
IPsec Routing Policies
An IPsec routing policy specifies which Infranet Enforcer the device endpoints must use
to access resources when using IPsec. The IPsec routing policy also specifies that
endpoints must use an IPsec tunnel to the Infranet Enforcer to access resources.
To use IPsec with ScreenOS Release 6.1 or earlier , you must configure separate IPsec
routing policies for different resources that you wish to protect. IPsec routing policies are
specific to the resources that you add.
If you are using Screen OS Release 6.1 or later, you can configure one dynamic IPsec
routing policy for each destination zone on each Infranet Enforcer.
In IPsec routing policies with ScreenOS Release 6.1 earlier , you can specify a range of
exceptions for traffic to certain resources that you do not want to use IPsec. The
exceptions can fall within the ranges of resources that the Infranet Enforcer protects. In
this case, if you create an exception for traffic that flows through the Infranet Enforcer,
you must also create another policy on the Infranet Enforcer that allows the exception
traffic to flow through.
For example, you might create an IPsec routing policy that uses IPsec for 0.0.0.0/0 (the
entire network). In the same policy, you can specify the resources that are exceptions
and that do not use IPsec, such as 172.24.80.30 (the Policy Secure gateway),
172.24.80.31 (the Infranet Enforcer), and 172.24.144/21 (a wireless network).
With ScreenOS Release 6.1 or later, policy exceptions are unnecessary. Dynamic IPsec
routing ensures that IPsec tunnels are created only for destinations that are governed
by the ScreenOS IPsec policy.
Related Before you Begin on page 128

Documentation

Before you Begin
Topic Details
IP address Do not use IPsec for the Policy Secure gateway, the Infranet Enforcer, and networks where your
exceptions endpoints are
located. For example, if you create an IPsec routing policy that uses IPsec on an entire network range
(such as 0.0.0.0/0) for your protected resources, be sure to specify exceptions in the same policy for
the IP addresses assigned to Policy Secure gateway, Infranet Enforcer, and the endpoints.

UDP encapsulation For maximum inter-operability with other third-party IPsec clients, select both Always use UDP
and virtual adapters encapsulation and Always use a virtual adapter. When both options are selected, Network address
translation (NAT) is simulated even if a NAT device is not present. We recommend that you select both
options or neither option. For example, if an endpoint contains two network interfaces, such as a wired
and a wireless interface, and a NAT device is not present between the endpoint and the Infranet Enforcer.
If the endpoint does not access a protected resource by using the interface that is connected to the
network where the Infranet Enforcer is installed, then the user cannot access the protected resource
through either interface without a virtual adapter. Because the Policy Secure gateway does not
automatically install a virtual adapter unless a NAT device is detected, enable the Always use a virtual
adapter option to simulate NAT and force the use of a virtual adapter for this use case.
Related Configuring IPsec Routing Policies on page 129

Documentation

Configuring IPsec Routing Policies
To configure an IPsec routing policy:
1. In the Policy Secure gateway admin console, select UAC > Infranet Enforcer > IPsec
Routing.
2. Click New Policy.
3. On the New Policy page:
a. For Name, enter a name to label this IPsec routing policy.
b. For Description, enter an optional description.
4. If you are using ScreenOS Release 6.1 or later, and you want to configure the Policy
Secure gateway to dynamically provision IPsec routing policies, select the Dynamic
check box. The Resources and Exceptions text boxes and the Infranet Enforcer
check boxes disappear.
5. Go to step 10 to continue configuring this policy for ScreenOS Release 6.1 or later.
6. For Resources, enter the IP address and netmask of each resource that requires
endpoints to use IPsec, one per line, in the following format:
<ip address>[/netmask]
You cannot specify a host name in an IPsec routing policy. You must specify an IP
address.
7. For Exceptions, use the following format, one per line, to specify the IP address and
netmask of each resource that has traffic which you do not want to flow through the
Infranet Enforcer:
<ip address>[/netmask]
Each exception must be a subset of what you specify for Resources.
8. For Destination Zone, enter the zone that is configured on the Infranet Enforcer where
the protected resources specified in this IPsec routing policy are located. For example:
trust
9. Select these options to configure IPsec interoperability and tunnel persistence:

 Always use UDP encapsulation—Allows the client and the Infranet Enforcer to
create an IPsec tunnel inside a third-party IPsec tunnel by using UDP encapsulation
even if a NAT device is not present. For example, for inter-operability with third-party
IPsec clients running on the endpoint The Policy Secure gateway uses port 4500
for UDP encapsulation in compliance with RFC 3948.
 Always use a virtual adapter—Forces the use of a virtual adapter on the endpoint.
If you select this option, you must also set up IP address pools even if a NAT device
is not present.
 Persistent Tunnel Mode—Allows you to determine whether or not a tunnel is

established when a user first connects to the Policy Secure gateway. If the check
box is selected, an IPsec tunnel is established, and users can access protected
resources behind the Infranet Enforcer. If the check box is not selected, the tunnel
is not automatically set up: a tunnel will not be initiated until there is a request for
traffic.
10. From the Enforcer list, choose the Infranet Enforcer to which endpoints connect to
access the resources specified in this IPsec routing policy.
11. In the Roles section, specify:
 Policy applies to ALL roles—To apply this IPsec routing policy to all users.
 Policy applies to SELECTED roles—To apply this IPsec routing policy only to users
who are mapped to roles in the Selected roles list. Be sure to add roles to this list
from the Available roles list.
 Policy applies to all roles OTHER THAN those selected below—To apply this IPsec
routing policy to all users except for those who map to the roles in the Selected
roles list. Be sure to add roles to this list from the Available roles list.

Documentation

Using IP Address Pool Policies for IPsec in a NAT Environment
The Policy Secure gateway supports the use of IPsec tunnels through NAT devices to
allow users secure access to protected resources. In a NAT environment, a virtual IP
address must be used for the IPsec tunnel’s inner address.
You can configure a pool of virtual IP addresses that the Policy Secure gateway can
automatically assign to endpoints by creating IP address pool policies. An IP address pool
is a contiguous range of IP addresses which you configure by specifying the starting
address and the number of addresses in the pool. You can associate an IP address pool
with one or more Infranet Enforcers.
IP address pool policies are required if one of the following is true:
 You are using IPsec in a NAT environment.

 You selected the Always use a virtual adapter option in an IPsec routing policy to enable
interoperability with other third-party IPsec clients running simultaneously on the
endpoint, such as Pulse Secure Network Connect or Microsoft IPsec.
To use NAT devices in the UACl solution, the endpoints must be located on one side of
the NAT devices, and both the Policy Secure gateway and Infranet Enforcer must be
located on the other side of the devices.
Also note the following if you are using NAT:
 NAT is not supported between the Policy Secure gateway and Infranet Enforcer.
 If there is a NAT device between the endpoint and the Policy Secure gateway, but not
between the endpoint and the Infranet Enforcer, source IP enforcement does not
work. This is also true if there is a NAT device between the endpoint and the Infranet
Enforcer, but not between the endpoint and the Policy Secure gateway.
If NAT is not detected, the client uses the endpoint’s physical IP address when creating
the IPsec tunnel to the Infranet Enforcer. The Policy Secure gateway does not allocate
an IP address from the pool.
Figure 12 on page 131 shows an example of a NAT environment where endpoints 1 and 2
have the same physical IP address: 192.168.1.1. By using an IP address pool policy, you
can configure the Policy Secure gateway to assign a unique, routable, virtual IP address
to each endpoint.
Figure 12: Using an IP Address Pool in a NAT Environment

The following sequence of events occur when the Policy Secure gateway and a Pulse
client (OAC or Pulse Secure) use an IPsec tunnel through a NAT device:
 When the client connects to the Policy Secure gateway and authenticates the user,
the client returns the endpoint’s source IP address that is used to access the Infranet
Enforcer to the Policy Secure gateway. The Policy Secure gateway saves the source
IP address internally.
 When the user attempts to access a protected resource, an IKE exchange occurs to
set up an IPsec tunnel between the endpoint and the Infranet Enforcer.
 During the IKE exchange, the Infranet Enforcer detects the source IP address of the
endpoint and sends that IP address to the Policy Secure gateway.
 The Policy Secure gateway compares its saved source IP address for the endpoint
with the endpoint’s IP address sent from the Infranet Enforcer. If the addresses do
not match, the Policy Secure gateway determines that there is a NAT device
between the endpoint and the Infranet Enforcer. The Policy Secure gateway
automatically provisions an IP address from an IP address pool policy that you
configured (for example, 10.11.0.10-100). The Policy Secure gateway assigns the IP
address to the endpoint based on the IP address pool policy that applies to the
user’s role. The Policy Secure gateway then sends the IP address to the Infranet
Enforcer.
 The Infranet Enforcer sends that IP address from the IP address pool (for example,
10.11.0.10) to the client on the endpoint during the Xauth authentication exchange.
 The client on the endpoint configures a virtual network adapter using the IP address
sent from the Infranet Enforcer.
 The endpoint initiates an IPsec connection to the Infranet Enforcer, and the Infranet
Enforcer sets up dynamic routes for each IP address. The user can now use the endpoint
to access protected resources.
The Policy Secure gateway allocates one IP address for the duration of each client
session, which lasts as long as the client is connected to the Policy Secure gateway.
After a session ends, the Policy Secure gateway can reuse the allocated address for a
different endpoint.
When the Policy Secure gateway must provide an inner IP address for a new IPsec
tunnel, it attempts to reuse an existing inner IP address assigned to the endpoint before
allocating a new one. The Policy Secure gateway checks all of the inner IPs allocated
from IP address pools for the endpoint. For each IP address, the Policy Secure gateway
determines whether the policy from which that address was allocated applies to the
user and the Infranet Enforcer for the new IPsec tunnel. If a compliant IP address is
found, it is used and no new IP address is allocated. If a compliant IP address is not
found, a new IP address is allocated.
Related Understanding IP Address Pool Policies on page 132

Documentation

Understanding IP Address Pool Policies
Topic Details

Multiple Infranet Enforcers If you are using multiple Infranet Enforcers across a LAN, make sure that
the IP address pool contains addresses that are valid for each Infranet
Enforcer.
Multiple unclustered Policy Secure If you are using multiple unclustered Policy Secure gateways across a
gateways LAN, make sure that the IP address pool contains addresses that are
unique for each Policy Secure gateway. The endpoint is assigned an
virtual IP address for each unclustered Policy Secure gateway to which
OAC connects.
IP address conflicts Make sure that the IP pool addresses do not conflict with addresses of
hosts that the endpoint might access.
Deleting IP addresses in an IP pool If you change or delete the IP addresses in an IP address pool, you must
delete all user sessions in order to stop using those addresses. To delete
all user sessions, select System > Status > Active Users page of the
Policy Secure gateway admin console and click Delete All.
Number of available IP addresses Be sure to specify a sufficient number of addresses in the IP address
pool for all of the endpoints in your deployment. When all of the
addresses in the pool are assigned to endpoints, additional endpoints
cannot obtain a virtual IP address and are blocked from accessing
protected resources. The Policy Secure gateway logs a message in the
Event log when an IP address cannot be assigned to an endpoint.
Related Using IP Address Pool Policies for IPsec in a NAT Environment on page 130
Documentation

Configuring an IP Address Pool Policy
To configure an IP address pool policy:
1. In the Policy Secure gateway admin console, select UAC > Infranet Enforcer > IP
Address Pools.
a. For Name, enter a name to label this IP address pool policy.
b. (Optional) For Description, enter a description.
4. For IP address pool, specify IP addresses or a range of IP addresses for the Policy
Secure gateway to assign to endpoints. The IP address range can be specified as
shown in Table 15 where the last component of the IP address is a range delimited
by a hyphen (-). Special characters are not allowed.
Table 14: Syntax for IP Address Pools
IP Address Range Description
a.b.c.d A single IP address

Table 14: Syntax for IP Address Pools (continued)
IP Address Range Description
a.b.c.d-e.f.g.h All IP addresses from the first address to the last address, inclusive
a.b.c.d-f.g.h An abbreviated form that specifies the range a.b.c.d through a.f.g.h
a.b.c.d-g.h An abbreviated form that specifies the range a.b.c.d through a.b.g.h
a.b.c.d-h An abbreviated form that specifies the range a.b.c.d through a.b.c.h
a.b.c.d/mask All addresses in a network
For example, to allocate all addresses in the range 172.20.0.0 through 172.20.3.255,
specify 172.20.0.0-3.255. To allocate all addresses in a class C network, specify
10.20.30.0/24.
5. Under Infranet Enforcer, select the Infranet Enforcer to which you want to apply this
IP address pool policy and click Add. To apply the policy to all Infranet Enforcers, do
not add any Infranet Enforcers, and leave the default setting (all) listed in the Selected
Enforcers list.
 Policy applies to ALL roles—To apply this IP address pool policy to all users.
 Policy applies to SELECTED roles—To apply this IP address pool policy only to users
 Policy applies to all roles OTHER THAN those selected below—To apply this IP address
pool policy to all users except for those who map to the roles in the Selected roles
list. Be sure to add roles to this list from the Available roles list.
If the IP addresses you specify in the IP address pool policies (that is, the virtual IP
addresses) are not routable from the network where your protected resources are located,
make sure you enable Source Network Address Translation (NAT-src) on the infranet
auth tunnel policies that configure IPsec on the Infranet Enforcer.
To enable NAT-src using the Infranet Enforcer Web UI:
1. Click Policies.
2. Click Edit on the infranet auth tunnel policy.
3. Click Advanced.
4. Select Source Translation and click OK.
For information about enabling NAT-src on the infranet auth tunnel policy, see
http://www.juniper.net/techpubs/en_US/release-independent/screenos/information-products/pathway-pages/screenos/product/index.html
.

Related Using IP Address Pool Policies for IPsec in a NAT Environment on page 130
Documentation
 Understanding IP Address Pool Policies on page 132

Understanding ScreenOS Enforcer Source Interface Policies
If you want endpoints to use IPsec to communicate with a ScreenOS Enforcer that is in
Transparent mode, you might need to configure a source interface policy on the Policy
Secure gateway. A source interface policy specifies the source interface on the
ScreenOS Enforcer that receives traffic from endpoints.
The use cases for configuring source interface policies are limited. You need to use a
source interface policy only if you have multiple virtual routers AND you have an IPsec
routing policy with destination zone DEST, and if one of the following is true:
 There are multiple IPsec policies on the ScreenOS Enforcer with a destination zone
DEST and different source zones.
 There is an IPsec policy on the ScreenOS Enforcer with a destination zone DEST whose
source zone has multiple interfaces.
For more information about how to set up a virtual router in the ScreenOS Enforcer, see
Related Setting Up an Infranet Enforcer in Transparent Mode on page 106

Documentation
 Configuring Source Interface Policies on page 135

Configuring Source Interface Policies
To configure a source interface policy:
1. In the Policy Secure gateway admin console, select UAC > Enforcer > IPsec Routing.
2. Select the Always show source interface policies check box. The Save Changes button
blinks.
3. Click Save Changes. The Source Interface tab is displayed at the top of the page.
4. Select the Source Interface tab.
a. For Name, enter a name to label this source interface policy.
7. From the Enforcer list, choose the Infranet Enforcer to which endpoints connect.
8. For Source Interface, specify the interface on the ScreenOS Enforcer to which traffic
from endpoints connects. This is the default interface for the zone you want to build

a gateway for, not the interface name. To view the zone table on the ScreenOS
Enforcer, type the following command:
get zone
 Policy applies to ALL roles—To apply this source interface policy to all users.
 Policy applies to SELECTED roles—To apply this source interface policy only to
users who are mapped to roles in the Selected roles list. Be sure to add roles to this
list from the Available roles list.
 Policy applies to all roles OTHER THAN those selected below—To apply this
source interface policy to all users except for those who map to the roles in the
Selected roles list. Be sure to add roles to this list from the Available roles list.
Related Understanding ScreenOS Enforcer Source Interface Policies on page 135

Documentation

Using the Pulse Policy Secure User Interface to Create Basic ScreenOS Enforcer
IPsec Policies
NOTE: The ScreenOS Enforcer supports static and dynamic IPsec.
If you are configuring IPsec with the ScreenOS Enforcer, you can create basic IPsec policies
on the Policy Secure gateway and then push the policies to the ScreenOS Enforcer,
where you can modify the policies.
To configure IPsec enforcement on the ScreenOS Enforcer:
1. In the admin console select UAC > Infranet Enforcer > Connection, then select New
Enforcer if you have not already configured a connection to the Infranet Enforcer on
which you want to configure IPsec enforcement.
2. Select UAC > Infranet Enforcer > Connection and click the name in the Enforcer column
of the Infranet Enforcer on which you want to configure IPsec enforcement.
3. Select UAC> Infranet Enforcer > Enforcer Policies. Then:
a. Select the source zone for the policy from the Source Zone list. The source zone is
the zone where the endpoint is located.
b. Select the destination zone for the policy from the Destination Zone list. The
destination zone is where the protected resources are located.
c. Select IPsec from the Typelist.
d. Click Add.
e. Click Save Changes to save the IPsec policy.

The Policy Secure gateway sets up a VPN tunnel with IKE on the Infranet Enforcer
that consists of a user, user group, IKE gateway, and VPN for each source
interface in the source zone of the policy. The Policy Secure gateway uses the
source interface number and the ID of the destination zone to uniquely name
each of these objects.
4. To configure the Policy Secure gateway to provision dynamic IPsec routing policies,
create
a new source IP policy on the Infranet Enforcer with the same source and destination
zone as the ScreenOS IPsec policy and with the captive portal feature configured to
redirect all traffic.
5. Select UAC > Infranet Enforcer > Resource Access, and configure Infranet Enforcer
resource access policies to specify which users are allowed or denied access to a set
of protected resources
6. Select UAC > Infranet Enforcer > IPsec Routing, and configure IPsec routing policies to
specify which Infranet Enforcer device the endpoints must use to access each set of
resources when using IPsec.
7. If you are using IPsec in a NAT environment, configure IP address pool policies by
selecting UAC > Infranet Enforcer > IP Address Pools.
8. If you want endpoints to use IPsec to communicate with an Infranet Enforcer that is
in Transparent mode, in some cases you may need a source interface policy.
9. To refresh IPsec policies, select UAC > Infranet Enforcer > Policies and click Refresh
Policies.

Documentation

Setting Up ScreenOS Enforcer IPsec Routing Policies
In this example, you use the Policy Secure gateway to set up IPsec enforcement from
Untrust to Trust, and Untrust has one source interface ethernet2. If ethernet2 has an
interface number of 5, and Trust has a zone ID of 2, then the Policy Secure gateway
runs the following CLI commands on the ScreenOS Enforcer:
set user $infra-u-5-2 ike-id u-fqdn u5-2.juniper.net share-limit 50000
set user $infra-u-5-2 type ike
set user-group $infra-g-5-2 user $infra-u-5-2
set ike gateway $infra-gw-5-2 dial-up $infra-g-5-2 Aggr outgoing-interface ethernet2 seedpreshare
ARANDOMSTRING proposal pre-g2-3des-sha
set ike gateway $infra-gw-5-2 xauth server $infranet query-config
set ike gateway $infra-gw-5-2 xauth server auth-method chap
set vpn $infra-vpn-5-2 gateway $infra-gw-5-2 no-replay tunnel idletime 0 sec-level compatible
set policy from Untrust to Trust "Dial-Up VPN" any any tunnel vpn $infra-vpn-5-2 infranet-auth
To use dynamic IPsec with ScreenOS, you configure two policies. On the ScreenOS
Enforcer, you must have two policies between the zones of interest: a source IP infranet
auth policy with the "redirect-all" option, and a tunnel infranet auth policy for IPsec.

Related Configuring ScreenOS Enforcer IPsec Encryption Settings on page 138

Documentation

Configuring ScreenOS Enforcer IPsec Encryption Settings
When you use the Policy Secure gateway to configure IPsec on the Infranet Enforcer, the
Policy Secure gateway creates an IPsec policy that uses these default IPsec encryption
settings for the phase 2 proposal: NoPFS, ESP, 3DES, and SHA1.
You can change the phase 2 proposal by using the Infranet Enforcer CLI or Web UI. For
example, you can change the phase 2 proposal by typing the following CLI command:
set vpn $infra-vpn-2-11 gateway $infra-gw-2-11 proposal nopfs-esp-aes128-sha

Possible values for the phase 2 proposal are:
nopfs-esp-des-md5
nopfs-esp-des-sha1
nopfs-esp-3des-md5
nopfs-esp-3des-sha1
nopfs-esp-aes128-md5
nopfs-esp-aes128-sha1
nopfs-esp-aes256-sha1
nopfs-esp-null-sha1
g2-esp-des-md5
g2-esp-des-sha1
g2-esp-3des-md5
g2-esp-3des-sha1
g2-esp-aes128-md5
g2-esp-aes128-sha1
g2-esp-aes192-sha1
g2-esp-aes256-sha1
In the Web UI select the following:
VPN > AutoKey IKE > edit > advanced > select user defined custom
It does not matter what preshared seed you use for the IKE gateway because the Policy
Secure gateway overrides it when it connects to the Infranet Enforcer.
Use the following settings for the VPN tunnel setup. Otherwise the IPsec enforcement
does not work correctly between the Policy Secure gateway and the Infranet Enforcer:
 xauth authentication
 dial-up VPN
 CHAP auth method

For more information about setting up a VPN tunnel for a dial-up user with IKE, see
the Concepts & Examples ScreenOS Reference Guide: Volume 5, Virtual Private Networks
or the ScreenOS CLI Reference Guide.

Documentation

Using ScreenOS Enforcer Bidirectional VPN Policies
If users need to connect from a computer inside the protected network back to the
endpoint that is connected by means of a dial-up VPN policy, you can create a bidirectional
VPN policy on the Infranet Enforcer. You create a bidirectional VPN policy on an existing
IPsec (dial-up VPN) policy that allows allow traffic from the endpoint to the protected
network.
The following examples are use cases for bidirectional VPN policies:
 A user’s endpoint at the office is connected by means of a dial-up VPN policy, and the
user wants to connect remotely to his office computer from another computer outside
the office.
 To diagnose a problem, a helpdesk employee needs to use a remote desktop system,

such as Virtual Network Computing (VNC) or Microsoft Remote Desktop on another
computer to connect to a user’s computer, and the user’s computer is connected by
means of a dial-up VPN policy.
Related Creating a ScreenOS Bidirectional VPN Policy on page 139

Documentation

Creating a ScreenOS Bidirectional VPN Policy
To create a bidirectional VPN policy using the CLI, use the following command:
set pol from <protected-resource-zone> to <endpoint-zone> any “Dial-up VPN” any tunnel vpn
<vpn-from-policy-going-the-other-way> pair policy <id-of-policy-going-the-other-way>
In the following example, an infranet-auth dial-up VPN policy from untrust to trust on
your Infranet Enforcer. The ID of the policy is 36, and the vpn is $infra-vpn- 1-2. The
following command sets up the corresponding bidirectional VPN policy to allow traffic
from trust to untrust:
set pol from trust to untrust any "Dial-up VPN" any tunnel vpn $infra-vpn-1-2 pair-policy 36
To create a bidirectional VPN policy using the Web UI:
1. Using the Policy Secure gateway, create the IPsec (dial-up VPN) policy on the UAC >
Infranet Enforcer > Enforcer Policies page.
2. In the Infranet Enforcer Web UI, edit the dial-up VPN policy that you created in the
previous step by selecting Policies > Edit.

3. Select Modify matching bidirectional VPN policy and click OK.
4. Select the new bidirectional VPN policy that you created in the preceding step by
selecting Policies > Edit.
a. Clear the Modify matching bidirectional VPN policy check box.
b. Click Advanced.
c. Clear the Authentication check box on the Advanced Policy Settings page.
d. Click OK.
Related  Using ScreenOS Enforcer Bidirectional VPN Policies on page 139

Documentation
Configuring Junos Enforcer IPsec Routing Policies
This topic describes how to configure Junos Enforcer IPsec routing policies. It includes
the following information:

 Configuration Example on page 141
You use the Junos OS CLI to configure IPsec routing policies on the Junos Enforcer. Unlike
the ScreenOS Enforcer, you cannot create policies on the Policy Secure gateway and
push the policies to the Junos Enforcer.
The source interface is specified in the IKE gateway configuration on the Junos Enforcer.
In security policies you specify a VPN, and you specify the IKE gateway in the VPN. For
more information see Junos OS Initial Configuration Guide for Security Devices.
NOTE:
 IPsec on the Junos Enforcer can handle up to 5,000 concurrent IKE
gateways.
 Dynamic IPsec is not supported on the Junos Enforcer.
To configure IPsec on the Junos Enforcer, you must perform three primary tasks:
 Configure the Policy Secure gateway as a RADIUS server for the Junos Enforcer client to
enable XAUTH. You must use the internal interface on the Policy Secure gateway,
the external interface does not support XAUTH.
 Configure IKE and IPsec parameters to specify security restrictions for SAs.
 Configure security policies to route traffic between the security gateway and the
interface for endpoints.

The Policy Secure gateway polls the Junos Enforcer to retrieve the following
configuration information:
 The IKE gateway interface
 The destination zone
 Identity
 The pre-shared seed
 The RADIUS shared secret
The Policy Secure gateway pushes these details to the client to allow establishment of a
dial-up VPN tunnel.
Configuration Example
The following example describes a sample configuration for setting up IPsec on the Junos
Enforcer.
To use IPsec with the ScreenOS Enforcer, you can configure basic IPsec security policies
on the Policy Secure gateway and then push the policies to the firewall. On the Junos
Enforcer, this functionality does not exist. For the Junos Enforcer, you use the CLI to
configure settings to create SAs on the Junos Enforcer that are negotiated with the
UAC agent.
Before you begin, ensure that security zones and interfaces are set up, and that IPsec
routing policies and optional IP address pool policies have been configured on the
Policy Secure gateway.
J Series devices support up to four proposals for Phase 2 negotiations, allowing you to
define the range of tunnel parameter restrictions that endpoints will accept.
For a complete description of IPsec on the Junos Enforcer see the Junos OS Initial
Configuration Guide for Security Devices.
To configure IPsec on the Junos Enforcer:
1. Configure the Policy Secure gateway as a RADIUS server for the Junos Enforcer client.
In this example, you create an instance of the Policy Secure gateway hostname
dev1086 as the RADIUS server. The IP address is 192.168.100.5. You need to provide
a shared secret, which is used to permit the Policy Secure gateway to accept
RADIUS packets from the device. Enter the following commands:
user@host# set access profile dev1086 authentication-order radius

user@host# set access profile dev1086 radius-server 192.168.100.5 secret some-shared-secret
If you are configuring Policy Secure gateways in an active/active cluster, you must
configure all IP addresses for individual Policy Secure gateways. The shared secret
must be the same,
as in the following example:
user@host# set access profile dev1086 authentication-order radius
If you are configuring and active/passive cluster, configure the Policy Secure
gateway’s VIP as the RADIUS server IP address.

2. Configure IKE and IPsec security parameters.
NOTE: IPsec with the Junos Enforcer is supported only with aggressive
mode and Encapsulation Security Payload (ESP).
 In aggressive mode, phase 1 security proposals are negotiated with two

exchanges and a total of three messages:
 First message—The initiator proposes the SA, initiates a Diffie-Hellman

exchange, and sends a pseudorandom number and the IKE identity.
 Second message—The recipient accepts the SA; authenticates the

initiator; and sends a pseudorandom number, the IKE identity, and, if
using certificates, the recipient's certificate.
 Third message—The initiator authenticates the recipient, confirms

the exchange, and, if using certificates, sends the initiator's certificate.
Because the participants' identities are exchanged in the clear (in the
first two messages), Aggressive mode does not provide identity
protection.
 ESP protects the inner IP packet, while the outer header remains
unprotected.
You define the security proposals, including all of the IKE parameters that determine
the strength of the IPsec tunnels. These options define the SAs for this IPsec tunnel.
Set up a phase 1 IKE proposal named prop, using Diffie-Hellman Group 2, authentication
algorithm SHA1, and encryption algorithm 3DES-CBC. Enter the following series of
commands.
a. user@host# set security ike proposal prop1 authentication-method pre-shared-keys

The client supports only the preshared key authentication method.
b. user@host# set security ike proposal prop1 dh-group group2

The client supports group1, group2, and group5.
c. user@host# set security ike proposal prop1 authentication-algorithm sha1

The client supports md5 and sha1.
d. user@host# set security ike proposal prop1 encryption-algorithm 3des-cbc

The client supports des-cbc, 3des-dbc, aes-128-cbc, aes-192-cbc, and aes-256-cbc
Set up an IKE policy named pol1 with aggressive mode, the pre-shared key and the
proposal configured above.
a. user@host# set security ike policy pol1 mode aggressive

The client supports only aggressive mode.
b. user@host# set security ike policy pol1 proposals prop1

c. user@host# set security ike policy pol1 pre-shared-key ascii-text some-preshared-key

Only ascii-text is supported. Do not use a hexadecimal pre-shared key.
Configure an IKE gateway named gateway1 with 5000 connection-limits,

host.company.com identity, group IKE ID, IKE policy pol1 configured above, and XAUTH
dev1086 as configured above.
a. user@host# set security ike gateway gateway1 ike-policy pol1

b. user@host# set security ike gateway gateway1 dynamic hostname host.company.com
c. user@host# set security ike gateway gateway1 dynamic ike-user-type group-ike-id
d. user@host# set security ike gateway gateway1 dynamic connections-limit (maximum
5,000)
e. user@host# set security ike gateway gateway1 external-interface ge-0/0/2.0
f. user@host# set security ike gateway gateway1 xauth access-profile dev1086
The Policy Secure gateway and the client support only group-ike-id.
Configure an IPsec phase 2 proposal named prop1 with ESP protocol, HMAC-SHA1-96
authentication algorithm, and 3DES-CBC encryption algorithm.
a. user@host# set security ipsec proposal prop1 protocol esp

The client supports only esp.
b. user@host# set security ipsec proposal prop1 authentication-algorithm hmac-sha1-96

The client supports hmac-md5-96, and hmac-sha1-96.
c. user@host# set security ipsec proposal prop1 encryption-algorithm 3des-cbc

The client supports des-cbc, 3des-cbc, aes-128-cbc, aes-192-cbc, aes-256-cbc,
and no encryption-algorithm.
Configure an IPsec phase 2 policy name pol1 with proposal prop1 as configured above.
a. user@host# set security ipsec policy pol1 proposals prop1
In this section, you configure an IPsec VPN named vpn1 with IKE gateway gateway1
as configured in the above example, and IPsec policy pol1 as configured above.
a. user@host# set security ipsec vpn vpn1 ike gateway gateway1

b. user@host# set security ipsec vpn vpn1 ike ipsec-policy pol1
c. user@host# set security ipsec vpn vpn1 establish-tunnels immediately
d. user@host# set security ike gateway gateway1 external-interface ge-0/0/0.0
NOTE: The external interface refers to the interface that faces the
client.
e. user@host# set security ike gateway gateway1 xauth access-profile name

3. Create the security policy.
 Enable the VPN vpn1 configured above, and add enforcement in UAC a security
policy named pol1 from the zone named untrust to the zone named trust.

user@host# set security policies from-zone untrust to-zone trust policy pol1 match
source-address any
NOTE: Always specify any with the following command.
destination-address any
application any
user@host# set security policies from-zone untrust to-zone trust policy pol1 then permit
tunnel ipsec-vpn vpn1
user@host# set security policies from-zone untrust to-zone trust policy pol1 then permit
application-services uac-policy
Related Understanding Pulse Policy Secure Support for IPsec Routing Policies on page 123
Documentation

Infranet Enforcer Policies Overview
After you set up user roles, authentication servers, realms and sign-in policies, you deploy
the Infranet Enforcer in front of servers and resources that you want to protect. You
control access through a number of different security policies that you configure on the
All policy options are supported on the ScreenOS Enforcer.
 Resource access policy—Specifies which users are allowed or denied access to a set
of protected resources. You specify which users you want to allow or deny by choosing
roles for each resource access policy.
 Source IP policy—This is an infranet auth policy the on ScreenOS Enforcer or a security

policy on the Junos Enforcer that contains a source and destination that permits the
Infranet Enforcer to route cleartext traffic between source and destination zones. You
can set up a source IP policy on the Policy Secure gateway and push the policy to the
Infranet Enforcer, or you can set up the policy using ScreenOS Web UI or the
command line.
 Auth table mapping policy—Specifies which Infranet Enforcer device an endpoint

must use to access resources when the endpoint is using source IP enforcement. If you
are using either a ScreenOS Enforcer with Release 6.1 or greater or the Junos Enforcer,
you do not need to configure auth table mapping policies. Instead, you can use dynamic
auth table provisioning.
NOTE: You can use a username with spaces, a username with quotation
marks, a username with UTF-8 characters, or a username with a backslash
(\). Each of these conventions is accepted by the firewall with a valid
corresponding auth table entry.
Figure 13 on page 145 demonstrates how policies on the Infranet Enforcer and the Policy
Secure gateway interact when a user has an auth table entry on the Infranet Enforcer.

Figure 13: Policy Interaction
The Infranet Enforcer detects a flow to a specific resource and compares the source IP
of the packet with IP addresses in the auth tables. The IP address is associated with a
set of roles in the auth table. The destination IP of the packet is matched with the
destination IP of a resource access policy to which a set of roles has been assigned. The
Infranet Enforcer parses the roles in the resource access policy to determine whether or
not the role can access the resource.
Related About Resource Access Policies on page 145

Documentation

About Resource Access Policies
A resource access policy specifies which users are allowed or denied access to a set of
You identify resources within your protected network, then you specify which users you
want to allow or deny by choosing the roles for each resource access policy. Auth table
entries on the Infranet Enforcer match user requests for access with resource access
policies.
The Infranet Enforcer evaluates traffic and enforces access control based on the policies
that you specify. When traffic from a role with a security policy enabled is compared with
a policy and a matching entry is detected, the Infranet Enforcer applies the appropriate
policy action.
For example, a resource access policy can specify that a user must have an Antivirus role
to access a particular network, and the Antivirus role requires the user’s computer to run
a particular antivirus program.
With the ScreenOS Infranet Enforcer, you can create an additional layer of security by
applying security policy actions to endpoints. Antispam, logging, IDP, web filtering,
antivirus, and deep inspection policies can be applied to any role.

The Policy Secure gateway pushes the policies to the Infranet Enforcer when the Infranet
Enforcer first connects to the Policy Secure gateway and any time you make a change
to a resource access policy. When any change is made on the resource access policies
page, all resource access policies on the Infranet Enforcer are refreshed, and endpoints
that are accessing resources through resource access policies are temporarily
interrupted.
With ScreenOS Release 6.2 or later, the Policy Secure gateway supports vsys. Vsys do not
inherit resource access policies from the root-vsys. If you have a resource access policy
configured for an existing ScreenOS Enforcer, and subsequently create one or more
vsys, you need to add new policies for the vsys if you want to allow users to access
resources within the vsys.
If you are using ScreenOS Release 6.2 or later or on the Junos Enforcer, you can configure
customized messages for authenticated users who attempt to access a resource to
which they are denied access.
When you specify the deny/reject action in a resource access policy for a role or roles, a
text field is displayed. Use the following variables to display information for the user:
 <USER> the login name of the user
 <SOURCEIP> the source IP of the packet
 <DESTIP> the destination IP of the packet
 <PROTOCOL> the protocol of the packet
 <DESTPORT> the destination port of the packet
You can use these variables along with your own text to compose the deny/reject message
that you send to OAC or Pulse users. When the message is sent to the user, the applicable
information about the session or the resource is substituted. The information is displayed
on the user’s endpoint in a balloon in the system tray icon.
Using the Juniper Networks EX Series Ethernet Switch as an Enforcer with a Resource Access
Policy
With Pulse Policy Secure Release 4.2 and Junos OS Release 12.2, you can use a Juniper
Networks EX Series Ethernet switch as an Enforcer. You add the EX Series as an
Infranet Enforcer in the admin console through the Infranet Enforcer Connection page,
and the EX Series becomes available as a selection on the Resource Access Policy
page. See “Pulse Policy Secure and EX Series Switch Configuration Task Summary” on
page 159
In addition to existing resource options, you can add MAC addresses as a resource.
Related Configuring Resource Access Policies on page 147

Documentation
 Infranet Enforcer Policies Overview on page 144


Configuring Resource Access Policies
To configure Infranet Enforcer resource access policies:
1. In the Policy Secure gateway admin console, select UAC > Enforcer > Resource Access
Policy.
a. For Name, enter a name to label this Infranet Enforcer resource access policy.
4. For Resources, specify the protocol, IP address, network mask, and port of each
resource (or range of addresses) for which this Infranet Enforcer resource access
policy applies, one per line. Do not insert any spaces in your entries, or the policy may
not be applied correctly.
You cannot specify a host name in a resource access policy. You can specify only an
IP address. You can use TCP, UDP, or ICMP.
5. Under Infranet Enforcer, specify the Infranet Enforcer to which this policy applies by
using Add.
6. Specify one of the following in the Roles section:
 Policy applies to ALL roles—To apply this Infranet Enforcer resource access policy
to all users.
 Policy applies to SELECTED roles—To apply this Infranet Enforcer resource access
policy only to users who are mapped to roles in the Selected roles list. Be sure to
add roles to this list from the Available roles list.
 Policy applies to all roles OTHER THAN those selected below— To apply this
Infranet Enforcer resource access policy to all users except those who map to the
roles in the Selected roles list. Be sure to add roles to this list from the Available
roles list.
7. In the Action section, specify whether you want to use this Infranet Enforcer resource
access policy to allow or deny access to the specified resources.
If you select deny, a text box is displayed that allows you to customize a deny message
for users.
With ScreenOS Enforcer Release 6.3 r13 or later, you can also select Reject Access.
The customized deny message is available with the reject action.
The reject action is designed for clients that hang for a long period of time while waiting
for connection initiations that the firewall is blocking. With the deny action, the Enforcer
drops traffic in accordance with the UAC policy, but does not send back reject
information. The policy action of "reject" denies the traffic and sends a TCP RST to
the traffic originator for TCP traffic, or ICMP unreachable for UDP traffic. In earlier
versions of ScreenOS and on the Junos Enforcer, the selection of reject results in a
deny action.

To record deny actions in the User Access Log, select the Infranet Enforcer Deny
Messages check box on the Log/monitoring > User Access > Settings page. The log
records the user, source IP, destination IP, protocol, and destination port.
8. For ScreenOS Enforcers, in the ScreenOS Options section, use the option buttons to
select the policy options that you want to apply to selected roles. Use the Add and
Remove buttons to specify antispam, logging, IDP, web filtering, antivirus, and deep
inspection.
By default, all policy options are enabled on the Policy Secure gateway. To enforce
the policies, you must create corresponding policies on the ScreenOS Enforcer. If the
Policy Secure gateway is upgraded from a previous version, all ScreenOS options are
enabled for the resource access policies that were available prior to the upgrade.
9. If you have created a vsys on a ScreenOS Enforcer, enter the name of the vsys in the
VSYS text box, if applicable. The main UAC > Infranet Enforcer > Resource Access
Policy page displays the Enforcers and/or vsys that are associated with each policy.

Documentation

User Role Policies on the Junos Enforcer
With Junos OS Release 12.1 or greater, and Pulse Policy Secure Release
4.2 or greater, you can use Junos security policies to control user access to protected
resources.
You configure user roles on the Pulse Policy Secure device, and security policies on the
SRX Series device. The user role security policies on the SRX Series device should use
the same roles names as those on the Pulse Policy Secure device. See the Junos OS
Initial Configuration Guide for Security Devices.
User role policies can be used in place of resource access policies, or in addition to resource
access policies.

Documentation

Understanding Infranet Enforcer Source IP Security Policies
This topic provides an overview of Infranet Enforcer source IP security policies. It includes
 Source IP Security Policy Overview on page 149

 ScreenOS Infranet Enforcer Configuration Summary on page 150
 Junos Infranet Enforcer Configuration Summary on page 150

Source IP Security Policy Overview

Source IP enforcement permits users to access resources that are protected by the
Infranet Enforcer. IPsec provides an encrypted tunnel for bidirectional traffic, while source
IP enforcement allows unencrypted (clear text) traffic between endpoints and the Infranet
Enforcer. You can use source IP enforcement alone on the Infranet Enforcer to protect
resources alone, or with IPsec on the ScreenOS Enforcer.
To use source IP enforcement, you configure infranet auth Enforcer policies for the
ScreenOS Enforcer and for vsys on the ScreenOS Enforcer, and you configure security
policies on the Junos Enforcer. Infranet auth policies and security policies control which
zones use Infranet Enforcer resource access policies to allow or deny traffic. By default,
traffic is denied through the Infranet Enforcer. With infranet auth policies and security
policies you control the traffic that is permitted to pass.
When you first set up the Infranet Enforcer and the Policy Secure gateway, you bind
zones to interfaces. Infranet-auth policies and security policies control the traffic flow
between zones. For example, you can configure an infranet auth policy on the
ScreenOS Enforcer to enforce traffic from the Untrust zone to the Trust zone. Then, you
configure resource access policies and specify resources that are within the Trust
zone. The roles that you assign to the resource access policy are permitted to access
the specified resources.
NOTE: Source IP enforcement does not work if there is a NAT device between
the endpoint and the Policy Secure gateway.
In a case where the endpoint is behind a NAT device and the Policy Secure gateway
and the Infranet Enforcer are both on the other side of the NAT device, only one
configuration is supported. Source IP enforcement with agentless access works only if
it is "one-to-one" NAT, since the Policy Secure gateway and the Infranet Enforcer both
see the external (translated) address, and there will be only one user session per IP
address.
Source IP enforcement with agentless access may appear to work, but will not operate
properly, if endpoint is behind a NAT device performing is "many-to-one" NAT. The first
user that authenticates from behind the NAT external IP address will get access but only
as long asf they are the only authenticated user. If a second user authenticates from
behind the same external (translated) IP address, the previous user's session is
terminated. The web browser would show that their session was terminated, the same
as if a Policy Secure gateway administrator deleted their session from the active user
table.
If the endpoint is behind a NAT device, Source IP enforcement with Pulse Secure client
or OAC access does not work at all, regardless of the type of NAT. The agent reports the
internal IP address of the endpoint, but the IC will see the external IP of the endpoint.
The user can authenticate, and the active user table displays X.X.X.X-Y.Y.Y.Y, where
X.X.X.X is the IP address reported by the agent and Y.Y.Y.Y is the IP address detected by
the IC. However no auth table entry is pushed to the firewall, since the Policy Secure
gateway detects that the endpoint is behind a NAT. The IPsec enforcement section
provides instructions on how to accommodate users in this use case.

IPsec enforcement must be used to provide access for Pulse Secure client or OAC users
behind a NAT device.
ScreenOS Infranet Enforcer Configuration Summary

You can configure basic infranet auth Enforcer policies that specify a source zone and a
destination zone on the Policy Secure gateway and then push the policies to the
ScreenOS Enforcer to add additional policy details, or you can use the ScreenOS
Enforcer to configure the policies with the CLI or Web UI. We recommend that you use
the Policy Secure gateway to set up the policies for source IP enforcement on the
Infranet Enforcer.
Before setting a policy, you must create address book entries for the destination and
source addresses unless you use address book entries that already exist, such as Any.
The following example, sets an infranet auth policy and adds it to the top of the list of
policies using Any. The policy allows all traffic of any type from any host to another host.
The policy allows traffic according to the Infranet Enforcer resource access policies that
you configure on the Policy Secure gateway.
set policy top from untrust to trust any any permit infranet-auth
The following example sets two address book entries and a policy between them for
anyone in the 10.64.0.0/16 range can reach the 10.65.0.0/16 range.
set address Trust “10.64 Range” 10.64.0.0 255.255.0.0

set address Untrust “10.65 Range” 10.65.0.0 255.255.0.0
set policy from trust to untrust “10.64 Range” “10.65 Range” any permit infranet-auth
Junos Infranet Enforcer Configuration Summary

On the Junos Enforcer, security policies enforce rules for the transit traffic. From the
perspective of security policies, traffic enters one security zone and exits another. This
combination of a from-zone and a to-zone is called a context on the Junos Enforcer.
A security zone is a logical group of interfaces with identical security requirements. Each
security zone contains an address book. Before you can set up policies between two
zones, you must define the addresses for each of the zone’s address books. A zone’s
address book must contain entries for the addressable networks and end hosts belonging
to the zone.
Each security policy that you create must contain at a minimum match criteria and an
action. You can specify additional policy options as required.
You can create security policies on the Junos Enforcer from the Junos Web interface, or
from the CLI. For details about setting up security policies on the Junos Enforcer, see
the Junos OS Initial Configuration Guide for Security Devices. For CLI instructions see
Junos OS CLI Reference.
Understanding Infranet Enforcer Auth Tables
The Infranet Enforcer holds auth tables for valid sessions on the Policy Secure gateway.
Auth tables consist of a unique identification number, the source IP address of the
endpoint that initiated the session, the username, and a list of roles that the user has been
assigned.

When a user with a username containing spaces or quotes authenticates with the
Policy Secure gateway, the device removes spaces and quotes from the username in
the authentication table entry that is sent to Infranet Enforcers.
You can allow the Infranet Enforcer to automatically generate auth tables whenever
users are authenticated, or you can configure dynamic auth table allocation. With dynamic
auth table allocation, auth tables are provisioned only as a response to a valid request
from an authenticated user for a resource behind the Infranet Enforcer.
Dynamic auth table allocation is available on all Junos Enforcers, and on ScreenOS
Enforcers with Release 6.1 or later.
Dynamic auth table allocation is required to use IF-MAP Federation.
Related Understanding Dynamic Auth Table Allocation on page 151

Documentation

 Configuring Auth Table Mapping Policies on page 154
Understanding Dynamic Auth Table Allocation
Prior to ScreenOS Release 6.1, you manually created auth table mapping policies to use
Source IP enforcement. Each authenticated user had an auth table entry on the Infranet
Enforcer, whether they were accessing resources or not. With the Junos Enforcer and
ScreenOS 6.1 or greater on the ScreenOS Enforcer you can dynamically create auth table
entries when a user attempts to access a protected resource, eliminating the need to
manually create Auth Table Mapping Policies.
Dynamic auth table allocation reduces auth table entries to only those that are needed,
enabling you to deploy smaller firewalls with a larger user population. After the user
disconnects, the Infranet Enforcer automatically expires the auth table entry.
Dynamic auth table allocation does not work with http traffic if the ScreenOS Enforcer’s
captive portal feature is configured to redirect user traffic to an external web server other
than the Policy Secure gateway. If you permit dynamic auth table allocation on the
Policy Secure gateway, and the DNS server for the network is behind the Infranet
Enforcer, endpoints may occasionally experience DNS time-out issues before
resources are provisioned.
In most deployments, Pulse Secure recommends that you use dynamic auth table
allocation. The benefits of dynamic auth table allocation are based on many factors
within the network deployment: the number of Infranet Enforcers, the anticipated number
of sessions, and the persistence of user sessions.
One scenario in which static auth tables are more practical are in deployments that force
every endpoint to go through a single Infranet Enforcer for all access. In this case, static
auth tables can reduce overall traffic between Policy Secure gateways and Infranet
Enforcers.
For deployments that use static auth table mapping policies (for example, if you are
using a ScreenOS Release 6.1 or earlier), we recommend no more than 100 connected

Infranet Enforcers. For deployment scenarios with more than 100 Infranet Enforcers, We
recommend a deployment strategy using dynamic auth table allocation.
Testing has shown that with 5,000 active sessions, performance is impacted significantly
when dynamic auth table allocation is not configured and 100 connected firewalls are
deployed.
Performance metrics vary for each UAC release. For current performance information,
refer to Pulse Secure or your strategic partner for.
Dynamic auth table allocation must use IF-MAP Federation.
Related Configuring Dynamic Auth Table Allocation on page 152

Documentation

Configuring Dynamic Auth Table Allocation
To enable dynamic auth table allocation:
1. Select UAC > Enforcer > Auth Table Mapping in the admin console. Either delete the
Default Policy or specify an Enforcer for which you do not want to configure this feature.
3. Configure a source IP policy for all traffic, whether source IP or IPsec.

Documentation

Configuring Auth Table Mapping Policies for Source IP Enforcement
NOTE: If you are using the Junos Enforcer or ScreenOS Release 6.1 or later
on the ScreenOS Enforcer, and you have permitted dynamic auth table
allocation, you do not need to configure auth table mapping policies. You
can use dynamic auth table allocation.
The Policy Secure gateway configuration includes one default auth table mapping
policy. When the default auth table mapping policy is enabled, the Policy Secure
gateway pushes one auth table entry for each authenticated user to all Infranet
Enforcer devices connected to the Policy Secure gateway. An auth table entry consists
of the user’s name, a set of roles, and the IP address of the wired adapter, wireless
adapter, or virtual adapter in the user’s computer. If your deployment includes a mixture
of low and high-capacity Infranet Enforcer devices, the lower capacity Infranet Enforcer
devices might reach the limit of concurrent auth table entries and prevent additional
users from accessing protected resources behind the lower-capacity Infranet Enforcer
devices.
Figure 14 on page 153 illustrates an example of a deployment that includes a

higher-capacity ScreenOS Enforcer ISG 2000 and a lower-capacity SSG 5 in two branch
offices. If the default auth table mapping policy is enabled and the number of users who
attempt to access protected resources behind the ISG 2000 in Branch Office 1 exceeds

the limit of concurrent auth table entries on the SSG 5, then additional users are unable
to access protected resources behind the SSG 5 in Branch Office 2.
You can prevent overloading of the lower-capacity Infranet Enforcer devices in mixed
deployments by deleting the default auth table mapping policy and creating new policies.
An auth table mapping policy specifies which Infranet Enforcer device each user role is
allowed to use when the endpoint is using source IP enforcement. These policies prevent
the Policy Secure gateway from creating unnecessary auth table entries on all connected
Infranet Enforcer devices. In the example in Figure 8, auth table entries for users
assigned the Branch1-Role are mapped to the ISG 2000 in Branch Office 1 only, which
avoids overloading the SSG 5in Branch Office 2. Similarly, the auth table entries for users
assigned the HQ-Role are mapped to the ISG 2000 in HQ Office only, and auth table
entries for users assigned the Branch2- Role are mapped to the SSG 5 in Branch Office
2 only.
Figure 14: Using Auth Table Mapping Policies
You can also use auth table mapping policies to restrict users from accessing resources
behind an Infranet Enforcer based on the user’s assigned role.
If your deployment does not use source IP enforcement, or if you have configured dynamic
provisioning of auth tables, you do not need to create auth table mapping policies. For
IPsec enforcement with the ScreenOS Enforcer, the Policy Secure gateway pushes auth
table entries only to the Infranet Enforcer devices you specify in IPsec routing policies. If
you are using a combination of source IP enforcement and IPsec enforcement, you only
need to create auth table mapping policies for the endpoints that use source IP
enforcement.
With ScreenOS Release 6.2 or later, the Policy Secure gateway supports Virtual systems
vsys. Vsys do not inherit auth table mapping policies from the root-vsyv. If you have an
auth

table mapping policy configured for an existing ScreenOS Enforcer, and subsequently
create one or more VSYS, you need to add new policies for the vsys if you want to allow
users to access resources behind the vsys.
Auth table mapping policies apply to OAC, Pulse, and agentless deployments.
Related Understanding Infranet Enforcer Auth Tables on page 150

Documentation

Configuring Auth Table Mapping Policies
To configure auth table mapping policies:
1. In the Policy Secure gateway admin console, select UAC > Enforcer > Auth Table
Mapping.
2. Select the default auth table mapping policy called Default Policy and click Delete.
a. For Name, enter a name to label this auth table mapping policy.
c. In the Enforcer section, specify the Infranet Enforcer device(s) to which you want
to apply this auth table mapping policy.
d. In the Roles section, specify:
 Policy applies to ALL roles—To apply this auth table mapping policy to all users.
 Policy applies to SELECTED roles—To apply this auth table mapping policy only
to users who are mapped to roles in the Selected roles list. Be sure to add roles
to this list from the Available roles list.
 Policy applies to all roles OTHER THAN those selected below—To apply this
auth table mapping policy to all users except for those who map to the roles in
the Selected roles list. Be sure to add roles to this list from the Available roles
list.
e. In the Action section, specify auth table mapping rules for the specified Infranet
Enforcer device:
 Always Provision Auth Table—To automatically provision auth table entries for
chosen roles on the specified Infranet Enforcer.
 Provision Auth Table as Needed—To provision auth table entries only when a
user with a chosen role attempts to access a resource behind the specified
Infranet Enforcer.
 Never Provision Auth Table—To prevent chosen roles from accessing resources
behind the specified Infranet Enforcer.
4. Make sure you delete the Default Policy if you configure any of your own auth table
mapping policies. The Policy Secure gateway includes this default auth table mapping
policy that allows all source IP endpoints to use all Infranet Enforcer devices.

5. If you created a vsys on a ScreenOS Enforcer, enter the name of the vsys in the vsys
text box. To view the enforcers or vsys that are associated with each policy, select
UAC > Infranet Enforcer > Auth Table Mapping .
Related Understanding Infranet Enforcer Auth Tables on page 150

Documentation  Understanding Dynamic Auth Table Allocation on page 151



CHAPTER 4
Deployments with EX Series Ethernet

Switches
 Pulse Policy Secure and Using the EX Series Switch as an Infranet Enforcer on
page 157
 Using the EX Series Switch as an Infranet Enforcer on page 158
 Pulse Policy Secure and EX Series Switch Configuration Task Summary on
page 159
 Connecting Pulse Policy Secure and the EX Series Switch on page 160
 Understanding Captive Portal with Pulse Policy Secure and the EX Series Switch
on page 160
 Understanding Auth Tables with the EX Series Switch on page 161
 Using Resource Access Policies with the EX Series Switch on page 161
Pulse Policy Secure and Using the EX Series Switch as an Infranet Enforcer
With Pulse Policy Secure Release 4.2 and JunosOS Release 12.2, you can deploy the EX
Series switch as an Infranet Enforcer.
In earlier releases, Pulse Policy Secure functioned as an authentication mechanism for

802.1X. Beginning with this release Pulse Policy Secure provides authorization in
addition to authentication.
With this solution, the EX Series switch serves as a policy enforcement point. Pulse
Policy Secure sends auth table entries and resource access policies when an endpoint
successfully completes 802.1X authentication or MAC authentication (unmanaged
devices). Access for any endpoint is governed by the resource access policies that you
configure on Pulse Policy Secure. Because resource access policies are employed,
firewall filters are not required for the EX Series switch configuration.
You configure captive portal on the EX Series switch to redirect users to a sign-in page
configured from the Pulse Policy Secure admin UI. Users can enter their credentials on
this page, and, if they are successfully authenticated, they can access the resources
that are associated with their assigned roles. Pulse Policy Secure sends an auth table

entry to the EX Series switch, and access is allowed or denied based on the resource
access polices applicable to that role.
NOTE: The captive portal feature is required only for user authentication.
Unmanaged devices, for example printers or phones, can authenticate with
802.1X and MAC address authentication.
Related Connecting Pulse Policy Secure and the EX Series Switch on page 160
Documentation
 Understanding Captive Portal with Pulse Policy Secure and the EX

Series Switch on page 160
 Understanding Auth Tables with the EX Series Switch on page 161
 Using Resource Access Policies with the EX Series Switch on page 161
Using the EX Series Switch as an Infranet Enforcer
The EX Series switch can be used as an Infranet Enforcer with Pulse Policy Secure. With
this solution, Pulse Policy Secure is the policy decision point, while the switch is the
policy enforcement point. In prior releases, Layer 3 firewalls were the only option for
policy enforcement points. This scenario allows enforcement with 802.1X deployments.
To employ the switch as an Infranet Enforcer, you configure a connection between the
EX Series switch and the IC Series or MAG device, establish communication, set up 802.1X,
configure Pulse Policy Secure parameters for admission to the network, and configure
resource access policies.
Upon successful configuration, the following occurs:
 The EX Series switch sends a connection request to Pulse Policy Secure.
 The EX Series switch shares its RADIUS configuration with Pulse Policy Secure from
the CLI configuration on the switch.
 Pulse Policy Secure creates the RADIUS client for the EX Series switch using the
information provided.
 When a user successfully authenticates, Pulse Policy Secure provides an auth table
entry to the connected EX Series switch. The auth table includes the MAC address of
the user, the assigned roles and the port index.
 Pulse Policy Secure must receive the attributes Calling Station ID and Network
Access Server (NAS) Port from the switch to successfully make the connection.
Related Pulse Policy Secure and EX Series Switch Configuration Task Summary on page 159
Documentation


Chapter 4: Deployments with EX Series Ethernet Switches
Pulse Policy Secure and EX Series Switch Configuration Task Summary
The following list is an overview of the configuration tasks involved in connecting a device
running Pulse Policy Secure to an EX Series switch to employ the switch as an Infranet
Enforcer:
 Set up and install the EX Series switch. See the applicable hardware guide at
http://www.juniper.net/techpubs/en_US/release-independent/junos/information-products/pathway-pages/ex-series/product/.
 Set up the IC Series or MAG Series device. See

http://www.juniper.net/support/products/mag/ for hardware installation and initial
network configuration.
 Connect the EX Series switch and Pulse Policy Secure. See Configuring an EX Series
Switch to Use Pulse Policy Secure for Network Access Control (CLI Procedure).
 Configure an authentication server instance. See “AAA Server Overview” on page 279.
 Configure roles on Pulse Policy Secure. See “Understanding User Roles” on page 261.
 Configure realms on Pulse Policy Secure, and create role mapping rules to associate
user roles with user realms. See “Specifying Role Mapping Rules for an
Authentication Realm” on page 433.
 Configure a location group for the EX Series switch. See “Configuring a Location Group”
on page 182.
 Configure Host Checker policies on Pulse Policy Secure. See “Creating Global Host
Checker Policies” on page 493.
 Configure a sign-in policy and a sign-in page for redirection. See “About Sign-In Policies”
on page 471.
 Configure a captive portal on the EX Series switch to redirect users to the Pulse Policy
Secure sign-in page. See Configuring the EX Series Switch for Captive Portal
Authentication with Pulse Policy Secure (CLI Procedure).
NOTE: Captive portal, as configured on the EX Series switch, redirects

users to the Pulse Policy Secure Web portal. See “Understanding the
Infranet Enforcer Captive Portal Feature” on page 109.
 Configure resource access policies on Pulse Policy Secure. See “Configuring

Resource Access Policies” on page 147.
Related Connecting Pulse Policy Secure and the EX Series Switch on page 160
Documentation


Connecting Pulse Policy Secure and the EX Series Switch
You must configure the EX Series switch and Pulse Policy Secure (either a Policy
Secure gateway or a MAG Series device) to communicate using 802.1X to employ this
solution.
To connect Pulse Policy Secure with the EX Series switch:
Perform the following steps to configure Pulse Policy Secure to accept a connection
from the EX Series switch:
2. Click New Enforcer. The New Infranet Enforcer dialog box appears. By default, the new
ScreenOS Enforcer page is displayed.
3. Select the Junos EX option button. The New Infranet Enforcer page is displayed.
4. Enter the name of the EX Series switch in the Name box.
5. Enter the password for the EX Series switch. This password is a shared secret that
administrators of both the switch and Pulse Policy Secure can use for connectivity
between the two devices.
6. Enter the serial number of the EX Series switch.
On the EX Series switch, you use the CLI to configure the connection with Pulse Policy
Secure. See Configuring an EX Series Switch to Use Pulse Policy Secure for Network
Access Control (CLI Procedure).
Documentation

Understanding Captive Portal with Pulse Policy Secure and the EX Series Switch
When you deploy Pulse Policy Secure and an EX Series switch, users might not know
that they must first sign into Pulse Policy Secure for authentication and endpoint
security checking before they can access a protected resource behind the EX Series
switch.
To facilitate sign-in, you can configure a redirect policy on the EX Series switch to
automatically redirect HTTP traffic destined for protected resources to Pulse Policy
Secure. This feature is called captive portal. When the sign-in page for the Pulse Policy
Secure is displayed, the user signs in, and Host Checker for OAC or Pulse or agentless
Host Checker examines the endpoint for compliance with security policies; and if the
endpoint passes the security check, access is granted to the protected resource.

NOTE: With captive portal, the user is redirected to the sign-in page that is
configured under the location group used for the EX connection.
Documentation

Understanding Auth Tables with the EX Series Switch
The EX Series switch receives and maintains auth tables for valid user sessions with
Pulse Policy Secure. An auth tables consist of a unique identification number, the MAC
address of the endpoint that initiated the session, and a list of roles that the user has
been assigned.
Auth tables are sent from Pulse Policy Secure to the EX Series switch when a user is
authenticated on the network.
NOTE: Auth table mapping policies are not supported for the EX Series switch.
Auth table entries on a Layer 3 device allow you to provision auth tables
based on policies that you configure. With the EX Series switch, an auth table
entry is only provisioned when the client for that auth table entry is connected
to the network through the EX Series switch.
Documentation

Using Resource Access Policies with the EX Series Switch
Using resource access policies with an EX Series switch you can configure authorization
for protected resources.
If you have configured the EX Series switch as an Infranet Enforcer, select the switch in
the resource access policy.
A resource is a single entry in the resource field of the resource access policy. This could
be a MAC address, or it could be a combination of IP address ranges, ports, and protocol.
A filter term is the access/deny detail for a single resource. The number of terms you can
configure per firewall filter will vary, depending on which EX Series switch you are
configuring. Table 13 shows the number of terms allowed per firewall filter for different
EX Series switches.
Table 15: EX Series Switches and Filter Term Limitations
EX Switch Number of Terms Allowed
EX2200 switch 512

Table 15: EX Series Switches and Filter Term Limitations (continued)
EX Switch Number of Terms Allowed
EX3200 and 4200 switches 7,042 (As allocated by the dynamic allocation of ternary content
addressable memory (TCAM) for port, VLAN, and router firewall filters.)
EX4500 switch 1,536
EX8200 switch 32,768
EX3300 switch 1,436
EX6200 switch 1,400
If you create resource access policies with the number of resources greater than the
maximum number of filter terms allowed, the filter is not installed, and 802.1X
authentication fails.
The following example describes 3 resource access policies: policy A contains 3 resources
(0a:22:33:fd:44:34, tcp://*:1-1024, 10.10.10.0/24); policy B contains 2 resources; and
policy C contains 5 resources.
In this example, the maximum number of filter terms allowed is 15. The switch receives
an auth table entry for a session for which policy A alone applies. Then, for that auth
table entry you would have to use $ filter terms (corresponding to 3 resources of policy
A + 1). Since 4 < 15 (maximum limit), the auth table entry is provisioned, and the 802.1X
authentication is successful. Next, the switch receives another auth table entry for which
policy C applies, so for that auth table entry you would use 6 filter terms (corresponding
to 5 resources of policy C + 1). At this point,, the total filter terms used is 4+6 = 10. This
is still less than 15, so the auth table entry is provisioned, and the 802.1X auth for this user
succeeds. Next, the EX Series switch receives another auth table entry for which both
policy B and C apply. Therefore, for that auth table entry you would use 8 filter terms
(corresponding to 2 resources for policy B + 5 resources for policy C + 1). So, the total
number of filter terms used is 10 + 8=18, which is greater than the maximum limit of 15.
In this case, the EX Series switch cannot provision this auth table entry, and the 802.1X
authentication for this user fails.
The switch has 2 daemons: one to handle the Pulse Policy Secure connection and the
actual provisioning of auth table entries, and another to handle 802.1X authentication.
The second daemon waits for a message from the first, indicating that the auth table
entry has been provisioned. Only after the second daemon receives this message is 802.1X
authentication successful. The switch opens the port for the end user.
If there is no message from the first daemon, the port is in an unauthenticated state until
timeout, after which a new 802.1X authentication is allowed. In the case where filter
installation is not successful (because the maximum limit is reached or some other error
occurs), the first daemon informs Pulse Policy Secure that the auth table entry could
not be provisioned with the appropriate reason string. This is displayed in the

Pulse Policy Secure event logs in the admin UI. Pulse Policy Secure will not send a
success message to the second daemon, and the 802.1X authentication fails and
times out.
NOTE: All Address Resolution Protocol (ARP) traffic is allowed to flow for
each Auth table entry unless there is a resource access policy which
specifically denies all ARP traffic.

Documentation  Configuring Resource Access Policies on page 147

 Pulse Policy Secure and EX Series Switch Configuration Task Summary on page 159


CHAPTER 5
Layer 2 Network Access Control Policies
 Using the Pulse Policy Secure RADIUS Server on page 166

 Understanding Pulse Policy Secure RADIUS Server Features on page 167
 Using Pulse Policy Secure Authentication Protocol Sets on page 170
 Configuring Authentication Protocol Sets on page 173
 Using RADIUS Proxy on page 174
 Understanding RADIUS Authentication and Accounting Time Limits on page 176
 Task Summary: Configuring the Policy Secure gateway as a RADIUS Server for an
802.1X Network Access Device on page 180
 Using Location Groups with Network Access Devices on page 180
 Configuring a Location Group on page 182
 Understanding the RADIUS Client Configuration on page 183
 Before Configuring a RADIUS Client on page 184
 Configuring a RADIUS Client on page 185
 Using RADIUS Client Dictionary Files on page 186
 Uploading a New RADIUS Client Dictionary on page 187
 Creating a RADIUS Dictionary Based on an Existing Model on page 187
 Creating RADIUS Dictionary Files on page 188
 Understanding RADIUS Attributes Policies on page 190
 RADIUS Attributes Policy Configuration Guidelines on page 191
 Creating a RADIUS Attributes Policy on page 192
 Understanding RADIUS Request Attribute Policies on page 194
 Configuring a RADIUS Request Attribute Policy on page 195
 Understanding RADIUS Attribute Logging on page 195
 Configuring RADIUS Attribute Logging on page 196
 Using RADIUS Attributes in Access Policies on page 196
 Use Case: Using an EX Series Ethernet Switch as a RADIUS Client on page 199

 Associating an Infranet Enforcer with the Pulse Policy Secure RADIUS

Server on page 202
 Use Case: Using a Non-Pulse Secure 802.1X Supplicant on page 203
 Before Configuring a Non-Pulse Secure supplicant on page 204
 Configuring Access to Switches and Access Points from a Browser on page 206
 Authenticating Users with Non-Tunneled Protocols on page 206
 Enabling Endpoints to Connect to VLANs behind the Policy Secure gateway on page
207
Using the Pulse Policy Secure RADIUS Server
A Network Access Device (NAD) or Ethernet switch is the client for the Pulse Policy
Secure. The NAD passes user connection requests (supported supplicant endpoints
include OAC, Pulse, and noappliance-Juniper supplicants) to the IC Series Appliance,
and then acts upon the response received from the Policy Secure gateway.
NOTE: The Pulse 802.1X access method interacts with the native wired and
wireless 802.1X supplicant on the client PC.
The IC Series appliance receives the endpoint connection request, authenticates the
user, and then returns the configuration parameters required to provision the connection
using RADIUS attributes. The IC Series appliance can also serve as a proxy client to
external RADIUS servers to offload authentication requests.
All transactions between the NAD and the Policy Secure gateway utilize a shared
secret, which is configured on each device. Additionally, passwords are encrypted
between the NAD and the Policy Secure gateway.
The IC Series supports a variety of authentication protocols that can be configured to

permit a number of different authentication types for authentication of a variety of devices
and endpoints.
Using the IC Series internal RADIUS server, you can provision 802.1X authentication for
endpoints. Layer 2 authentication and enforcement is used to control network access
policies at the edge of the network using an 802.1X enabled switch or access point such
as a Juniper Networks EX Series switch.
The user’s identity and the endpoint health assessment are used to determine which
VLAN to use for the switch port that the endpoint is connected to. Typically, if the endpoint
does not meet minimum criteria for health assessment as defined by the administrator,
the endpoint will be placed on a restricted VLAN which allows access to servers which
can aid in remediating the endpoint.
You define VLAN policies for endpoints that access switches via 802.1X. After an
authenticated endpoint has been mapped to a set of roles, the VLAN policies are
evaluated and the VLAN information is communicated to the switch through RADIUS

Chapter 5: Layer 2 Network Access Control Policies
attributes. RADIUS attributes vary by make and model of switch. You specify the make
and model when configuring a RADIUS client on the Policy Secure gateway.
In addition to authenticating endpoints with 802.1X the Policy Secure gateway’s

RADIUS server can be used to authenticate 802.1X IP phones, switches, and the Policy
Secure gateway can perform non-802.1X MAC Address based authentication for
unmanageable devices.
The UAC ScreenOS Enforcer and the Junos Enforcer use the Policy Secure gateway’s
RADIUS server for IPsec XAUTH authentication.
Related Understanding Pulse Policy Secure RADIUS Server Features on page 167
Documentation

Understanding Pulse Policy Secure RADIUS Server Features
In addition to performing 802.1X port-based authentication, you can configure the IC

Series internal RADIUS server for various authentication methods using a variety of
authentication protocols including Extensible Authentication Protocol (EAP) EAP inner
and outer authentication, nontunneled web authentication without EAP, and MAC address
authentication. EAP provides for extensibility and is a standard for communication
between NADs and servers, and EAP is also used for Statement of Health (SOH) Host
Checker policies.
EAP allows specialized knowledge about authentication protocols to be taken out of the
NAD so that it acts solely as a conduit between the authentication server and the client.
With EAP, new types of authentication can be supported by adding the appropriate
functionality to the server and client without any changes to the NAD or the protocol.
The use of EAP can facilitate 802.1X access as well as traditional RADIUS authentication
for non 802.1X access.
The Policy Secure gateway supports a variety of authentication protocols. In addition to

Tunneled Transport Layer Security (EAP-TTLS) and Protected EAP (EAP-PEAP), which
the Policy Secure gateway uses for OAC and Pulse 802.1X connectivity, the Policy
Secure gateway RADIUS server supports nontunneled protocols that permit different
methods of authentication. For example, MAC address authentication, 802.1X
connectivity with non-Pulse Secure supplicants and Challenge Handshake
Authentication Protocol (CHAP) authentication (to allow Web access to switches) can
be configured on the Policy Secure gateway.
Using the Policy Secure gateway RADIUS server and the supported EAP protocols, you
can configure a NAD to support any combination of the following uses:
 Unmanageable device authentication
 Switch authentication using traditional RADIUS
 Non-Pulse Secure 802.1X supplicant authentication

 OAC or Pulse 802.1X authentication
 802.1X IP phone authentication
The NAD’s location group and sign-in policy govern which users are allowed. The following
sections present a broader view of the configurable parameters on the Policy Secure
gateway.
Related Using the Pulse Policy Secure RADIUS Server on page 166
Documentation

Understanding Pulse Policy Secure Authentication Protocols
The Policy Secure gateway supports a variety of EAP and non-EAP authentication
methods to allow you to determine how endpoints authenticate. Authentication
methods can have different purposes. For example, you can use the default EAP
methods with OAC and Pulse, or you can use different methods to permit authentication
with different endpoints, such as non-Pulse Secure 802.1X supplicants and IP
phones.
For UAC agents (OAC, Pulse, the Java agent, and Host Checker agentless access),
authentication is supported via EAP-TTLS and EAP-PEAP as the outer protocols and
EAP-JUAC (a proprietary protocol) by default.
EAP-TTLS first authenticates the server and sets up an encrypted Transport Layer Security
(TLS) tunnel for secure transport of authentication information. Within the TLS tunnel,
a second authentication protocol is used to authenticate the user. EAP-TTLS is the “outer”
authentication, while the second protocol is the “inner” authentication.
EAP-TTLS consists of two phases. In the first phase, the the X.509 digital certificate of
the authentication server is used by the supplicant to verify its identity, and to validate
the network’s authenticity.
The authentication server is required to present a digital certificate. This digital certificate
is used in the outer authentication to establish the TLS tunnel from the supplicant to a
AAA Server. If there are certificate restrictions, or if the inner protocol is EAP-TLS, a user
certificate is also used.
EAP-PEAP is similar to EAP-TTLS, with a difference being that the inner authentication
must be another EAP exchange. PEAP can only use EAP-compatible authentication
methods. PEAP starts the TLS tunnel, then uses EAP again, encapsulated inside the
tunnel to perform the authentication.
EAP-TTLS and EAP-PEAP authenticate the user and the network, and produce dynamic
keys that can be used to encrypt communications between the endpoint and access
point. With mutual authentication, not only does the network authenticate the user
credentials, but the supplicant also authenticates the authentication server.
Requiring mutual authentication is an important security precaution with wireless

networking. Verifying the identity of the authentication server ensures that you connect
to your intended network, and not to an access point that is pretending to be the network.

You can authenticate with OAC or a third-party 802.1X supplicant when you configure
the endpoint to validate the certificate of the authentication server. If the certificate
identifies a server that you trust, and if the authentication server can prove that it is the
owner of that certificate, then you can safely connect to the network.
For Pulse with 802.1X you select a certificate when you create a Pulse connection set.
The user can accept or reject the certificate.
EAP-TLS, EAP-TTLS, and EAP-PEAP all employ TLS, the successor of Secure Socket
Layer (SSL). TLS is the protocol used to secure communications between Web browsers
and secure Web servers. In general, the outer protocol ensures that the client or agent is
communicating with a valid, trusted server, and the inner protocol proves your identity
to the Policy Secure gateway.
The EAP-JUAC inner protocol allows OAC and Pulse to take advantage of the full set of
Policy Secure gateway features, including Host Checker, firewall provisioning and IP
address restrictions.
In addition to EAP-TTLS and EAP-PEAP, the following standard protocols are supported
for interactivation with RADIUS clients other than OAC and Pulse:
 Password Authentication Protocol (PAP) with plain-text passwords
 EAP Generic Token Card (EAP-GTC)
 CHAP and the CHAP family, including MS-CHAP, MS-CHAP-V2, EAP-MD5-Challenge,

and EAP-MS-CHAP-V2
 EAP Transport Layer Security (EAP-TLS)—The Policy Secure gateway supports EAP-
TLS to allow non-Pulse Secure 802.1X supplicants to authenticate via a certificate
authentication server.
 EAP State of Health (EAP-SOH)
The Policy Secure gateway supports these authentication protocols as nontunneled

authentication methods as well as inner authentication methods, subject to the policies
that you configure. You can configure protocol sets with or without EAP, with the exception
of MD5, EAP-GTC, EAP-TLS, and EAP-SOH, which are supported only for EAP.
EAP-SOH is a special protocol used only with Windows Vista and Windows XP Service
Pack 3 802.1X supplicants in a Statement of Health Host Checker policy. The EAP-SOH
protocol allows the endpoint to exchange state of health messages with the Policy
Secure gateway to assess endpoint qualification for passing Statement of Health rules
in a Host Checker policy. To use EAP-SOH, you must use EAP-PEAP as an outer
authentication protocol.
If you use a protocol set with inner and outer authentication, both protocols must match
the inner and outer protocol that is configured for the endpoint.
Related Using Pulse Policy Secure Authentication Protocol Sets on page 170
Documentation


Using Pulse Policy Secure Authentication Protocol Sets
You can access the Policy Secure gateway in several ways. The method and the
protocols you select determine the realm(s) through which endpoints are
authenticated. Any authentication methods that are incompatible with the
authentication server being used are not even attempted. You associate realms with
authentication protocols when you configure a sign-in policy. For information about
configuring realms and sign-in policies, see Access Management Framework.
You can configure any combination of authentication protocols on the Policy Secure
gateway for use with non-Pulse Secure 802.1X supplicants, or compatible IP phones, or
for non-tunneled access (for example, Web access to a switch).
There are two default preconfigured protocol sets on the Policy Secure gateway. The
802.1X protocol set is used by default with UAC agents. 802.1X-Phones protocol set is
used for authenticating 802.1X IP phones. When you configure a new sign-in policy,
you must associate realms that you have configured with authentication protocol sets.
You can select a protocol set you have created, or you can use one of the default
protocol sets, depending on the endpoint. Endpoints can access only realms that are
configured with compatible authentication protocol sets.
You can select several authentication protocols for each protocol set. If you select more
than one protocol for inner and outer authentication, the order in which you list the
protocols is important. The EAP protocols are evaluated in order by the Policy Secure
gateway, with selections at the top of the list considered first for each connection
attempt. If you select EAP-TTLS or EAP-PEAP as primary authentication protocols, you
must select separate inner authentication protocols.
You can duplicate an existing protocol set and make changes, and you can delete protocol
sets you have created. You cannot delete the default 802.1X protocol set, but you can
delete the 802.1X-Phone protocol set.
When an endpoint requests authentication, realm selection is based on which

authentication protocols match. For example, if a client and the Policy Secure gateway
do not agree on using a selected protocol set, the realm not considered. Clients that
connect to the Policy Secure gateway include OAC, Pulse Secure, non- Pulse Secure
802.1X supplicants, 802.1X IP phones, and switches. The Policy Secure gateway can
accept authentication requests from all
of these endpoints from a single Network Access Server and route the traffic depending
on authentication protocols that are configured for individual realms. Table 16 on page 170
lists the available authentication protocol combinations and provides usage
recommendations for various combinations.
Table 16: Authentication Protocols
Outer Inner Basis Usage recommendation
PAP [1] n/a Password Local auth server, Active Directory,

LDAP [2] Cisco switch authentication

Table 16: Authentication Protocols (continued)
CHAP [1] n/a Password Captive portal or authentication of

switch administrators for HP
ProCurve switch
EAP-MD5-Challenge n/a Password Captive portal or authentication of

[1] switch administrators, some IP
phones
MS-CHAP [1] n/a Password -
MS-CHAP-V2 [1] n/a Password -
EAP-MS-CHAP-V2 n/a Password -

[1]
EAP-GTC [1] n/a Token -
EAP-TLS n/a User Certificate 802.1X supplicant, some IP phones
EAP-PEAP Non-Pulse Secure 802.1X supplicant
EAP-MS-CHAP-V2 Password Local or Active Directory server
EAP-GTC Token 802.1 X supplicant
EAP-TLS User Certificate -
EAP-JUAC Various OAC
EAP-SOH Password Windows supplicant with Statement

of Health Host Checker policy
EAP-TTLS OAC, Pulse, other supplicant
PAP LDAP authentication server
CHAP -
EAP-MD5-Challenge -
MS-CHAP -
MS-CHAP-V2 -
EAP-MS-CHAP-V2 Local or Active Directory server
EAP-GTC 802.1X supplicant

Table 16: Authentication Protocols (continued)
EAP-JUAC OAC, Pulse
NOTE: Pulse always uses EAP-TTLS/EAP-JUAC.
 If the supplicant or client supports EAP-TTLS or EAP-PEAP, we recommend putting

this protocol into one of those tunnels for added security.
 With LDAP, there are 3 protocol possibilities:
 If the LDAP server is also an Active Directory server, configure the server on the
Policy Secure gateway as an Active Directory server, not as an LDAP server. On
the Policy Secure gateway, PEAP-MS-CHAP-V2 is enabled by default. You can
also enable MS-CHAP and MS-CHAP-V2 if necessary.
 If passwords in the LDAP server are stored irreversibly hashed, CHAP family protocols
will not work, only PAP and TTLS-PAP will work. On the Policy Secure gateway
TTLS-PAP is enabled by default. You can enable PAP if required, but this is the least
secure protocol.
 Some LDAP servers allow you to store the passwords in cleartext or reversibly
encrypted. In this situation, all of the CHAP family protocols will work.
The following table summarizes additional usage guidelines.
Table 17: Authentication Protocol Set Configuration Guidelines
Topic Details
Password Changing The protocols that support password changing on the Policy Secure
gateway include JUAC, MS-CHAP-V2 (only within a TTLS tunnel),
EAP-MS-CHAP-V2 (only within a PEAP or TTLS tunnel), and EAP-GTC.
If you use CHAP, PAP or MS-CHAP for a Layer 2 connection (for example,
with an Active Directory Server), password changing is not supported
through the Policy Secure gateway.
Expired passwords You can direct users with expired passwords to a Web interface to access
a default VLAN to allow users to log in with a cleartext password and
change their password.
Password restrictions Password restrictions (for example, password length) cannot be

enforced if you use the CHAP family protocols for authentication.
Default protocols for OAC and Pulse The 802.1X protocol set is used by default for endpoints that connects
with OAC or Pulse. If you disable the JUAC protocol (a proprietary Juniper
protocol) on OAC or Pulse or on the Policy Secure gateway, OAC and
Pulse have only the features of a standard non-Pulse Secure
supplicant.

Using an 802.1X IP Phone with the IC Series

IP telephones that support 802.1X support EAP, either as EAP-MD-5-Challenge or
EAP-TLS, depending on the manufacturer. You can associate a realm with the default
802.1X-Phones protocol, and then use role-mapping to assign phones to a role within
the realm. The Policy Secure gateway automatically directs phones that attempt to
authenticate using the 802.1X-Phones protocol to the associated realm. See Access
Management Framework for information about configuring sign-in policies.
If you are planning to use 802.1X IP phones on a network segment that also
accommodates switches using Web-based authentication, you will assign role-mapping
rules to ensure that phones are recognized, since a switch using MD-5 Challenge would
automatically be authenticated through the same realm. For example, Avaya phones
can be recognized by the expression [0-9afA-F]*. You can create a role-mapping rule
that specifies if user = [0-9afA-F]*, then assign to a role specific to IP phones.
Related Understanding 802.1X Network Access Control Deployments on page 178

Documentation

Configuring Authentication Protocol Sets
You configure authentication protocols sets from the sign-in pages.
To configure an authentication protocol set:
1. In the Policy Secure gateway admin console, select Authentication > Signing In >
Authentication Protocols.
NOTE: The default 802.1X protocol set is configured to work with

EAP-TTLS or EAP-PEAP as primary (outer) authentication protocols, and
with EAP-JUAC or with EAP-MSCHAP- V2 for inner authentication (if
EAP-PEAP is used) and EAP-JUAC, PAP, MSCHAP- V2, EAP-MS-CHAP-V2,
or EAP-GenericTokenCard (if EAP-TTLS is used).
2. To create a new protocol set, click New Authentication Protocol, or select the check
box beside the existing 802.1X protocol set and click Duplicate.
3. Enter a name, and optionally al description for the new authentication protocol set.
You select the protocol set by name when you create a sign-in policy.
4. Under Authentication Protocol, select authentication protocol(s) from the Available

Protocol list. Click Add.
5. If you select EAP-PEAP as the main authentication protocol, under PEAP select an
inner authentication protocol from the Available Protocol list. Click Add.

NOTE: If you are configuring a protocol set to work with the Windows
client and a Host Checker Statement of Health policy, you must select
the EAP-SOH protocol as the inner authentication method within a PEAP
tunnel.
6. If you select EAP-TTLS as the main authentication protocol, under TTLS select an
inner authentication protocol from the Available Protocol list. Click Add.
7. If you are using inner RADIUS proxy, do not select an inner protocol with EAP-PEAP
or EAP-TTLS.
8. Click Save Changes. to save your selections. When you configure a sign-in policy, you
associate this authentication protocol set with an authentication realm. See Access
Management Framework for information about configuring realms.
Related Using Pulse Policy Secure Authentication Protocol Sets on page 170
Documentation

Using RADIUS Proxy
In environments with many distributed users, it can be difficult or impossible to maintain

a centralized database of users. With RADIUS proxy, the Policy Secure gateway RADIUS
server can forward authentication requests from a network access device (NAD) to an
external RADIUS server. The proxy target receives the request, performs the
authentication and returns the results. The Policy Secure gateway RADIUS server then
passes the results to the NAD.
You can configure the Policy Secure gateway to proxy RADIUS inner or outer
authentication to an external RADIUS server. Proxying inner or outer authentication
gives you the flexibility to direct requests for authentication through whatever realm is
most appropriate for each user. Whether you proxy inner or outer RADIUS
authentication depends on where you want the authentication tunnel to terminate.
RADIUS proxy can permit greater flexibility in network design and can accommodate
existing topologies. In many networks, authentication data for different workgroups is
grouped in different ways. For example, authentication groups might be configured by
department, by subsidiary, or by acquired company. You can configure the local NAD to
use the Policy Secure gateway for authentication of local endpoints, and you can use
second-tier RADIUS servers (proxy targets) to handle the different groups.
One advantage of this setup is in the simplified configuration. The NADs and each RADIUS
server must share a secret passcode. The Policy Secure gateway does not require
NADs to communicate directly with each RADIUS server, and second-tier RADIUS
servers do not have to share a secret with every NAD in the company. The Policy
Secure gateway handles the shared secrets.
If the network components (Policy Secure gateway, authentication server, NAD, and
RADIUS server) are managed by different individuals, the local administrators can
configure authentication servers to communicate with local RADIUS servers without
the overhead

of connecting each authentication server to Policy Secure gateways or Policy

Secure gateway clusters throughout the company.
With RADIUS proxy you can easily transition using a RADIUS-based AAA service,
eliminating the need to enter users on the Policy Secure gateway. Using your
existing RADIUS server gives you access to powerful RADIUS features that are not
supported on the Policy Secure gateway RADIUS server.
With inner proxy, the proxy target specializes in authentication, and the Policy
Secure gateway specializes in access control.
The Policy Secure gateway has local knowledge that is critical to controlling user
access to the network. The Policy Secure gateway can be configured to determine
what VLAN numbers and ACL identifiers are relevant at each site. This data could differ
on remote sites.
With outer proxy, you can use outer protocols that are not supported on the Policy
Secure gateway (for example, EAP-PEAPv1 or EAP POTP).
If the proxy target has capabilities that the Policy Secure gateway does not (such
as communicate with SQL), the Policy Secure gateway can offload to a proxy server
that can communicate with SQL.
NOTE: When RADIUS proxy is used, realm or role restrictions cannot be

enforced. Host Checker policies, Source IP restrictions, and any other assigned
limits are bypassed. Use RADIUS proxy only if no restrictions have been
applied. The exception is that session limitations can be enforced for inner
proxy. With outer proxy, no session is established.
You configure RADIUS proxy at the realm level. If the authentication server for the realm
is a RADIUS server, you can select inner proxy, outer proxy or do not proxy. Do not proxy
is selected by default. If the authentication server is not a RADIUS server, the proxy option
buttons are hidden. If an incoming RADIUS authentication or accounting request is
assigned to a realm that uses RADIUS proxy, the Policy Secure gateway proxies the
request to the external RADIUS server.
With outer proxy, all RADIUS attributes are passed from the Policy Secure gateway
RADIUS server to the NAD.
NOTE: The UAC RADIUS server provides a variety of differentiated services.

For example, these services include enforcing concurrent user session limits
at the realm level. If a realm specifies user session limits, and outer proxy is
used for the realm, these limits will not be enforced. The Policy Secure
gateway does not monitor user sessions when outer proxy is used.
With inner proxy, the NAD sends tunneled authentication requests and the Policy
Secure gateway decrypts the TLS traffic and forwards the inner traffic to another
RADIUS server, the proxy target. The Policy Secure gateway receives the responses
from the second RADIUS server, encrypts the responses using TLS, and sends the
response back to the NAD inside

the tunnel. If you use inner proxy, traffic between the Policy Secure gateway and the
external RADIUS server should be well-protected with physical security or some other
means.
With a tunneled request, inner proxy allows the Policy Secure gateway to inspect the
inner traffic to obtain the username and RADIUS return attributes.
With outer proxy, the NAD sends tunneled or bare authentication requests, and the
Policy Secure gateway forwards the requests without TLS processing. With outer
proxy, the Policy Secure gateway acts as a conduit between the NAD and the proxy
target.
You cannot use outer proxy if a role-mapping rule based on usernames is being used,
because the Policy Secure gateway cannot see the username and a session cannot be
created.
If the authentication server selected for a realm is a RADIUS server, the Proxy Outer
Authentication option button controls whether outer authentication is proxied. The Proxy
Inner Authentication option button controls whether inner authentication is proxied.
You can also select the Do not proxy option button if you do not want inner or outer
authentication to be proxied. In this case, the Policy Secure gateway handles both inner
and outer authentication. You must enable the JUAC protocol for this option.
There are special considerations for RADIUS proxy with respect to realm selection. See
Access Management Framework for information about configuring sign-in policies.
Related Task Summary: Configuring the Policy Secure gateway as a RADIUS Server for an
Documentation 802.1X Network Access Device on page 180
Understanding RADIUS Authentication and Accounting Time Limits
All requests for authentication have a time limit. Depending on the endpoint, the
authentication protocols used, the NAD (NAD) settings, and the Host Checker policies
configured at the role and realm level, RADIUS time limits could affect the success or
failure of authentication and the performance and memory allocation of the RADIUS
server.
Table 18 on page 176 displays network events and the device or endpoint response when
the timeout is exceeded. You can use this information along with the RADIUS Diagnostic
Log and User Log as a guide for troubleshooting the Policy Secure gateway. See
Monitoring and Troubleshooting for information about using logs.
Table 18: RADIUS Event Time Limits
Interval Starts: Interval Ends: Limited by: Effect of Timeout
When the NAD sends When the NAD NAD: Sometimes 5 NAD resends an exact
a single RADIUS receives the RADIUS seconds, usually copy of the RADIUS
request to the Policy response configurable request (if configured
Secure gateway to do so). RADIUS
Diagnostic Log
indicates that a
duplicate was
received.

Table 18: RADIUS Event Time Limits (continued)
When the NAD sends When the NAD NAD: (the timeout The NAD assumes a
the first copy of a receives the RADIUS interval above) x (the communication
RADIUS request to the response maximum number of failure with the
Policy Secure gateway. retries +1) The RADIUS server. It
maximum number of might record the
retries is typically 2 or event in the log and
3 and is usually report it to the
configurable endpoint. The Policy
Secure gateway
RADIUS diagnostic
log shows
turnaround times
longer than the NAD’s
limit.
When NAD forwards When the NAD NAD: (this may be The Policy Secure
an EAP request from receives an EAP limited by a gateway user log
the Policy Secure response from the configuration setting reports timeout while
gateway to an endpoint on the NAD, or the waiting for a RADIUS
endpoint NAD may honor the continuation request.
Session Timeout
attribute that the
Policy Secure
gateway included in
the
Access-Challenge
packet - see next row)
When the IC Series When the IC Series Policy Secure gateway: This The Policy
device sends the first device receives the Secure gateway
EAP message of an last EAP response limit was two minutes User Log reports
EAP exchange to the and has been timeout while waiting
NAD for forwarding to increased to 4 for a RADIUS
the endpoint minutes continuation request.
” “ NAD: Some NADs “

limit this. The limit is
not always
configurable
When the IC Series The NAD takes the NAD: This may be Endpoint loses
device sends a endpoint off the fixed in the NADs network connectivity.
RADIUS network unless it has configuration or NAD sends a RADIUS
Access-Accept packet been reauthenticated. controlled by the Accounting-Stop
to the NAD and the Session Timeout packet (if configured
NAD lets the endpoint attributes that the to do so). The Policy
onto the network. Policy Secure Secure gateway
gateway sends as records in the user
part of the log.
Access-Accept
packet. The
Session-Timeout
attribute is set by the
roles assigned to the
user, or by the RADIUS
attributes policy.

Table 18: RADIUS Event Time Limits (continued)
When the Policy OAC automatically OAC: the Policy OAC automatically
Secure gateway initiates Secure gateway initiates
finishes reauthentication. sends a time limit reauthentication. User
authenticating OAC equal to the session intervention is
using EAP-JUAC. timeout fixed by the typically needed for a
roles assigned to the SecureID card only. If
user minus 2 reauthentication
minutes succeeds, the
endpoint retains
network access.
  Understanding 802.1X Network Access Control Deployments on page 178
Understanding 802.1X Network Access Control Deployments
The IEEE 802.1X protocol provides authenticated access to a LAN. This standard applies
to both wireless and wired networks. In a wireless network, the 802.1X authentication
occurs after the client has associated to an access point using an 802.11 association
method. Wired networks use the 802.1X standard without any 802.11 association by
connecting to a port on an 802.1X enabled switch. See the Juniper Networks Application
note 3rd Party Switch Configurations.
With 802.1X, the user is authenticated to the network by means of user credentials, such
as a password, certificate, or a token card. The keys used for data encryption are generated
dynamically. The authentication is not performed by the NAD, but rather by the Policy
Secure gateway as the RADIUS server.
The 802.1X method uses EAP messages to perform authentication. Newer EAP protocols
can dynamically generate the WEP, TKIP, or AES keys that encrypt data between the
client and the wireless access point. Dynamically created keys are more difficult to break
than preconfigured keys because their lifetime is much shorter. Known cryptographic
attacks against WEP can be thwarted by reducing the length of time that an encryption
key remains in use. Furthermore, encryption keys generated using EAP protocols are
generated on a per-user and per-session basis. The keys are not shared among users, as
they must be with preconfigured keys or preshared passphrases.
NOTE: 802.1X authentication is supported on OAC, Pulse, and endpoints

running non-Pulse Secure 802.1X supplicants. With non-Pulse Secure
supplicants, you cannot use an Infranet Enforcer in the configuration.
The Policy Secure gateway RADIUS server can fulfill RADIUS authentication requests
from RADIUS clients that support 802.1X. (If you are using an external RADIUS
server for authentication, you can use the Policy Secure gateway RADIUS proxy
feature.

A RADIUS client, the NAD, accepts EAPOL (EAP over LAN) connection requests from
802.1X supplicants.
The NAD, which can be a wired switch or a wireless access point, uses the RADIUS protocol
to communicate with the Policy Secure gateway to authenticate and authorize endpoints
before allowing them access to the network.
The Policy Secure gateway RADIUS server receives requests for authentication from the
NAD and authenticates the endpoint. The Policy Secure gateway then sends the
response back to the NAD The NAD and the Policy Secure gateway exchange messages
in a series of request/response transactions.
The NAD sends a request and expects a response from the Policy Secure gateway. If the
response does not arrive, the NAD can retry the request periodically.
Figure 15 on page 179 illustrates how the Policy Secure gateway functions as a RADIUS
server for an 802.1X NAD within the UAC solution with OAC.
Figure 15: Policy Secure gateway as a RADIUS Server for an 802.1X

Network Access Device
 The endpoint connects to an 802.1X NAD. The endpoint and the Policy Secure
gateway exchange EAP messages by means of 802.1X and RADIUS through the
NAD. The EAP messages contain information about user credentials and the health
of the endpoint.
 The Policy Secure gateway uses its local server or an external authentication server
to verify the user’s identity.
 If the Policy Secure gateway successfully authenticates the user, the Policy Secure
gateway sends
a message to the NAD to allow the endpoint access to the network. The type of access
granted depends on the user’s identity and the health of the endpoint. For example, if
the endpoint meets the requirements of all Host Checker policies, the user can have
full network access. If the endpoint does not meet some security requirements, the
user can be granted access to a remediation server. If the endpoint is using OAC or
Pulse as its 802.1X supplicant, the Policy Secure gateway and the endpoint exchange
messages as necessary throughout a session (for example, to monitor the endpoint’s
security

compliance). If the endpoint is using a non-Pulse Secure supplicant, Host Checker is

not supported.
 If the endpoint is using OAC or Pulse, and the endpoint meets the requirements of all
Host Checker policies when the user attempts to access a protected resource, the
Policy Secure gateway sends auth table entries to the Infranet Enforcer to allow the
user access to the protected resources. If the endpoint is using a non-Pulse Secure
supplicant, the Policy Secure gateway opens the network port.
Task Summary: Configuring the Policy Secure gateway as a RADIUS Server for an
802.1X Network Access Device
To configure the Policy Secure gateway as a RADIUS server for an 802.1X NAD, perform
these tasks:
1. Create a location group by selecting UAC > Network Access > Location Group in the
admin console. A location group associates a sign-in policy with a group of NADs.
2. Create a RADIUS client by selecting UAC > Network Access > RADIUS Client in the
admin console. A RADIUS client specifies NAD parameters such as the IP address
that enables the Policy Secure gateway to respond to the device.
3. Optionally, create a RADIUS attribute policy by selecting UAC > Network Access >
RADIUS Attributes in the admin console. A RADIUS attribute policy associates RADIUS
return attributes such as VLAN tunnel assignment with user roles. RADIUS return
attributes determine how the endpoint is allowed to access the network.
NOTE: To use a ScreenOS Enforcer as a RADIUS client of the Policy Secure

gateway, do not configure a RADIUS client for the ScreenOS Enforcer.
Related Understanding RADIUS Authentication and Accounting Time Limits on page 176
Documentation
 Using Location Groups with Network Access Devices on page 180

 Understanding RADIUS Attributes Policies on page 190
 Use Case: Using an EX Series Ethernet Switch as a RADIUS Client on page 199
Using Location Groups with Network Access Devices
Location groups let you organize or logically group NADs by associating the devices with
specific sign-in policies. Sign-in policies provide a way to define and direct independent
access control policies with the network. Location groups associate sign-in policies with
NADs.

A sign-in policy defines the realm that the NAD users can use to access the Policy
Secure gateway. When creating a sign-in policy, you associate it with the appropriate
realm. When creating a realm, you associate it with an authentication server. Thus, by
associating a location group with a sign-in policy, you can associate a group of NADs
with an authentication server along with the other realm settings, such as an
authentication policy and role-mapping.
For example, you might create location group policies to logically group the NADs in each
building at a corporate campus. You can also use location group policies to specify a
special realm for MAC address authentication.
As shown in Figure 16 on page 182, you can create two location group policies, called Wired
and Wireless, to require different levels of authentication credentials from wired versus
wireless endpoints. You might do this because you require the strictest authentication
modes for your wireless access points, while your wired networks have an acceptable
level of physical security.
In this example, each location group is associated with a different sign-in policy, each
sign-in policy uses a different realm, and each realm uses a different authentication
server.
 The Wired location group for wired switches is associated with a sign-in policy that
uses an Active Directory authentication server. Users who connect to the network
through wired switches must sign in using Active Directory credentials.
 For stricter authentication, the Wireless location group for wireless access points is
associated with a sign-in policy that uses an ACE authentication server. Users who
connect to the network through wireless access points must sign in using their ACE
server credentials. These credentials are a username and password that consists of
the concatenation of a PIN and the current value of an RSA SecurID hardware token’s
current value.
NOTE: With location groups, you can block Layer 2 endpoints in specific
locations from using particular authentication protocols, realms, and roles.
As an example, you can block endpoints in unsecure locations from accessing
sensitive roles. However, RADIUS clients should not be placed in insecure
locations. To ensure that RADIUS clients are not compromised and do not
violate these policies, all of the network RADIUS clients should be securely
protected.

Figure 16: Using Location Groups to Group Network Access Devices
Related Configuring a Location Group on page 182

Documentation

Configuring a Location Group
To configure a location group on the Policy Secure gateway:
1. Create a sign-in policy to associate with the location group.
2. In the Policy Secure gateway admin console, select UAC > Network Access > Location
Group.
3. On the New Location Group page, enter a name to label this location group and
optionally a l Description.
4. For Sign-in Policy, select the sign-in policy associate with the location group.
5. If this location group is for controlling an unmanageable device using MAC address
authentication, select a MAC Authentication Realm that you created from the list.
Related Using Location Groups with Network Access Devices on page 180
Documentation
 802.1X
Network Access Device on page 180

Understanding the RADIUS Client Configuration
This topic provides an overview of the RADIUS client configuration in an 802.1X

deployment. It includes the following information:
 RADIUS Client Configuration Overview on page 183

 Sending Disconnect Requests to NADs (Dynamic Authorization Support) Using a
RADIUS Client Policy on page 184
RADIUS Client Configuration Overview

You configure RADIUS clients on the Policy Secure gateway to provide the connection
information required to allow communication with the 802.1X NAD.
When you configure a RADIUS client in the Policy Secure gateway you must supply the
following information about the device:
 The IP address of the NAD
In large-scale deployments, if several NADs use the same RADIUS attributes and have
contiguous IP addresses, you can specify a group of NADs by using a contiguous range
of IP addresses instead of an IP address for each device. When the Policy Secure
gateway receives a RADIUS request that includes a source IP address in this range, it
uses the RADIUS client policy for the range to determine the appropriate shared
secret, make and model, and location group.
 The shared secret used by both the Policy Secure gateway and the NAD
 The make and model of the NAD, which you select from a list of devices in the Policy
Secure gateway admin console
The Policy Secure gateway supports a large number of specific NADs by using its
built-in standard RADIUS and vendor-specific, proprietary dictionary files. You can
upload new dictionaries to add new RADIUS clients. The Policy Secure gateway uses
the dictionary files to store lists of RADIUS attributes, parse authentication requests,
and generate responses.
When you select the device’s make and model in a RADIUS client policy, you are
selecting a dictionary file that contains the vendor-specific attributes (VSAs) for that
device. Whenever the Policy Secure gateway receives a RADIUS packet from that
device, it consults the dictionary file for any nonstandard attributes that it
encounters in the packet. If you do not know the make and model of a device, you
can use the standard RADIUS attributes by choosing the Standard RADIUS setting in
a RADIUS client policy.
In addition to the configuration on the Policy Secure gateway, you must configure the
Network Access Device with information about the Policy Secure gateway, including:
 The IP address of the Policy Secure gateway
 The shared secret you specified in the RADIUS client policy for the device
For configuration instructions, see the documentation provided with the NAD.

You can use Network and Security Manager (NSM) to configure the Policy Secure
gateway to communicate with the Juniper Networks EX Series switch. If you use NSM,
the RADIUS client is automatically created for the connection.
Sending Disconnect Requests to NADs (Dynamic Authorization Support) Using a RADIUS Client
Policy
You can configure a RADIUS client policy to send terminate session requests to NADs
that support RFC 3576. Using disconnect requests, you can terminate sessions for OAC,
Pulse, or non-Pulse Secure supplicant Layer 2 endpoints that have already
authenticated.
If you configure this option on the RADIUS client policy, you permit the Policy Secure
gateway to send unsolicited disconnect requests to the NAD. When a user session is
deleted on the Policy Secure gateway, the disconnect messages cause the user’s
session to be terminated immediately and all session information is to be removed.
The Policy Secure gateway can also send disconnect messages upon a role event that
includes a VLAN change or a change in RADIUS attributes.
Requests are provided only for sessions that were initiated with Layer 2 authentication
through a NAD that support RFC 3576, including Juniper Networks EX Series.
Disconnect requests for switches always come from the IP address that was used for
authentication. The software automatically sends the correct IP address for Policy
Secure gateways that are in a cluster.
You must have RADIUS accounting enabled on the NAD to allow the device to uniquely
identify a session.
The Policy Secure gateway makes a log entry for the following events:
 Successful completion of a request
 The NAK of a request
 When a request times out
 When the number of retries expires
Related Before Configuring a RADIUS Client on page 184

Documentation
 Configuring a RADIUS Client on page 185

 Using RADIUS Client Dictionary Files on page 186
Before Configuring a RADIUS Client
Topic Details
Overlapping IP address ranges The address range assigned to one group of NADs in a RADIUS client
cannot overlap the address ranges assigned in another RADIUS client.

Topic Details
Starting IP address range restrictions The starting address of the address range assigned to a group of NADs
cannot be the same as the IP address of an individual NAD. The starting
address of the address range assigned to a group of NADs cannot be
the same as the IP address of an individual NAD.
IP address range restrictions If an individual NAD has an IP address that falls within an address range
assigned to a group of NADs, the Policy Secure gateway uses the
RADIUS client for the individual NAD.
For example, suppose an individual NAD is configured in the NAD1

RADIUS client policy with IP address 192.168.21.55, and a group of NADs
is configured in the BLDG1 RADIUS client policy with an IP address range
of 192.168.21.50–192.168.21.60. If the Policy Secure gateway receives a
RADIUS request from 192.168.21.55, it uses the NAD1 RADIUS client
information. If the Policy Secure gateway receives a RADIUS request
from 192.168.21.56, it uses the BLDG1 RADIUS client information.
IP address limitations A RADIUS client for a group of NADs cannot use a Class D, E, or F IP
address (that is, an address greater than 223.255.255.0).
Shared secret You must configure the NAD with the same shared secret that you enter
in the Policy Secure gateway.
If you change a shared secret, your connection is disrupted. Select a

complex password initially in accordance with your security policies.
RADIUS dictionary If you are not sure which make and model switch you are using or if your
device is not in the list, select - Standard RADIUS - for Make/Model.
Alternately, you can upload additional dictionaries to add a new NAD.
RFC3680 If the NAD is not fully RFC compliant and does not accept RFC3680
Tunnel Attributes with tags, select - Standard RADIUS: No VLAN tags
- for Make/Model.
Related  Configuring a RADIUS Client on page 185

Documentation
Configuring a RADIUS Client
To create a RADIUS client on the Policy Secure gateway:
1. If you have not already done so, configure a location group. At least one location group
is required before you can configure a RADIUS client.
2. In the Policy Secure gateway admin console, select UAC > Network Access > RADIUS
Client.
3. Click New RADIUS Client.
4. On the RADIUS Client page, enter a name to label this RADIUS client. Although you
can assign any name to a RADIUS client entry, use the device's SSID or IPv4 address
to avoid confusion.

5. For (Optional) Description, enter a description.
6. For IP Address, enter the IP address of the NAD.
7. (Optional) For IP Address Range, enter the number of IP addresses in the IP address
range for the NADs, starting with the address you specified for IP Address. You can
specify a range up to a maximum of 32,768 addresses.
8. For Shared Secret, enter the RADIUS shared secret. A RADIUS shared secret is a
case-sensitive password used to validate communications between the IC Series
device and NAD. The Policy Secure gateway supports shared secrets of up to 127
alphanumeric characters, including spaces and the following special characters:
~!@#$%^&*()_+|\=-‘{}[]:”’;<>?/.,
9. For Make/Model, select the make and model of the NAD. The make/model selection
tells the Policy Secure gateway which dictionary of RADIUS attributes to use when
communicating with this client.
10. For Location Group, select the location group to use with this NAD.
11. Select the Support Disconnect Messages check box to enable disconnect messages.
If this check box is selected, a disconnect request is sent to the NAD any time a session
is deleted on the Policy Secure gateway. This feature is not supported on every
manufacturer’s NAD. Consult the manufacturer for details.
a. (Optional) Enter a new Dynamic Authorization Port (the default port is 3799). Some
switches use a different default port.
Related Using RADIUS Client Dictionary Files on page 186

Documentation

 Associating an Infranet Enforcer with the Pulse Policy Secure RADIUS Server on
page 202
Using RADIUS Client Dictionary Files
The Policy Secure gateway uses dictionary files to store lists of RADIUS attributes. The
Policy Secure gateway uses these dictionaries to parse authentication and accounting
requests and to generate responses.
The main dictionary file (radius.dct) lists attributes defined by the RADIUS standard.
In addition to the standard attributes, many NADs use Vendor-Specific Attributes (VSAs)
to complete a connection. The Policy Secure gateway supports a large number of specific
NADs by providing vendor-specific, proprietary dictionary files.
During configuration of a Policy Secure gateway, when you make a selection in the
RADIUS Client Make/Model field, you are telling the server which dictionary file contains
the VSAs for this client device. Thereafter, whenever the server receives a RADIUS
packet from this client device, it can consult this dictionary file for any nonstandard
attributes that it

encounters in the packet. Standard RADIUS attributes are always defined by the radius.dct
file.
You can display all of the built-in RADIUS dictionaries by selecting UAC > Network Access
> RADIUS Dictionary on the Policy Secure gateway. You can upload new dictionaries to
define makes and models that are not preconfigured on the Policy Secure gateway,
and you can copy and modify existing dictionaries.
Related Understanding the RADIUS Client Configuration on page 183

Documentation

 Creating a RADIUS Dictionary Based on an Existing Model on page 187
Uploading a New RADIUS Client Dictionary
To upload a new RADIUS client dictionary to the Policy Secure gateway:
1. In the admin console, select UAC > Network Access > RADIUS Dictionary to display the
preconfigured dictionaries and their associated vendors.
2. Click New RADIUS dictionary.
3. Enter a Name and optionally a description for the new dictionary.
4. Use the Browse button to search for the dictionary file (.dct) on a local or connected
drive, then click Save Changes. The uploaded dictionary is displayed on the main
RADIUS Dictionary page, and in the Make/Model list on the RADIUS Client page.
NOTE:
 You can only remove dictionaries that are not associated with a vendor.
 You can download any dictionary from the list, including preinstalled
dictionaries. You can modify the downloaded dictionary and then upload
it as a new make/model.
Related Configuring a RADIUS Client on page 185

Documentation

Creating a RADIUS Dictionary Based on an Existing Model
To create a new RADIUS dictionary based on an existing manufacturer’s model:
1. In the admin console, select UAC > Network Access > RADIUS Dictionary to display the
listing of preconfigured dictionaries on the Policy Secure gateway and their
associated vendors.
2. Select the dictionary to copy.
3. Click the .dct file to download the existing dictionary.

4. Modify the downloaded .dct file and rename the file.
5. Select UAC > Network Access > RADIUS Dictionary and click New RADIUS Dictionary.
6. Browse for the file you have modified, and enter a new name and optional description
for the new dictionary.
7. Click Save Changes to upload the modified.dct file. The modified file is displayed on
the RADIUS Dictionary page. Note that there is no vendor associated with the new
dictionary.
8. Select UAC > Network Access RADIUS Vendor and click New RADIUS Vendor.
9. Enter a new name and optional description for the new RADIUS vendor.
10. Select the new dictionary you created from the list.
11. Click Save Changes. The new vendor and the associated dictionary will appear on the
RADIUS Vendor page.
Related Understanding the RADIUS Client Configuration on page 183

Documentation

Creating RADIUS Dictionary Files
The dictionary format is derived from the RADIUS 5 specification (July 1996).
This section contains dictionary translations for parsing requests and generating
responses. All transactions are composed of Attribute/Value Pairs. The value of each
attribute is specified as one of these valid data types shown in Table 19 on page 188.
Table 19: Valid Data Types
Data Description
hexadecimal Hexadecimal string
hex1, hex4 1- or 4-byte hexadecimal number
string 0-254 octets (includes null terminator)
stringnz 0-254 octets (without null terminator)
ipv6addr 16 octets in network byte order (per RFC-3162)
ipv6prefix 2-18 octets in network byte order (per RFC-3162)
ipv6interface 8 octets in network byte order (per RFC-3162)
ipaddr 4 octets in network byte order
ipaddr-pool IP address selected from an IP address pool

Table 19: Valid Data Types (continued)
Data Description
ipxaddr-pool IPX network number selected from an IPX address pool
integer 32-bit value in big endian order (high byte first)
int1, int4 1- or 4-byte decimal number (integer is equivalent to int4)
time 32-bit value in big endian order; seconds since 00:00:00 GMT, Jan. 1, 1970
All attribute names and value names in the supplied radius.dct dictionary are derived
from the RADIUS specification by replacing all nonalphanumeric characters with dashes
(-).
The following dictionary format provides a mechanism for including secondary dictionaries
from the text of a primary dictionary. For example, only the attribute/value definitions
that differ from the RADIUS specification need to be listed in a primary dictionary for a
vendor specific implementation. Definitions for the attribute/values that are common
to both are brought in by including the radius.dct dictionary anywhere within the vendor
dictionary.
The following rules apply to the creation and use of dictionaries:
 All comments begin with a pound sign (#) in column 0 OR appear on a attribute or
value line with <white space>#<white space> as the Mandatory delimiter between
dictionary data and comment text. (This is a simple parser.)
 Include another dictionary file with an at sign (@). The (@) character must be in column
0.
 All attribute and attribute value names and numeric codes must be unique within a
single dictionary. Conflicts between dictionaries are resolved according to the following
rules:
 Attributes and values have precedence over any that are parsed later, and parsing
is depth first.
For example, to override a baseline attribute, create a file with that attribute in it,
followed by an include of the baseline file. Because the baseline file is parsed later
than the desired override, the baseline file is ignored.
 When two secondary dictionary definitions of an attribute or value conflict, the earlier
include takes precedence.
 Other than include files, there are two meaningful line entry formats in a dictionary
-one for attributes and one for attribute values.
ATTRIBUTE_KEY ATTRIBUTE_NAME ATTRIBUTE_CODE DATA_TYPE FLAGS

[COMMENT_DELIMITER COMMENT_TEXT]

VALUE_KEY ATTRIBUTE_NAME VALUE_NAME VALUE_CODE [COMMENT_DELIMITER

COMMENT_TEXT]
 The legend for the last column of an attribute entry should be:
 'c' indicates a SINGLE value attribute that is a candidate for inclusion in a user's
checklist.
'C' indicates a MULTI value attribute that is a candidate for inclusion in a user's
checklist.
 'r' indicates a SINGLE value attribute that is a candidate for inclusion in a user's reply
list.
'R' indicates a MULTI valued attribute that is a candidate for inclusion in a user's
reply list.
 'o','O' ordered attribute, some attributes (such as Reply-Message) might need to

be presented in a particular order to make sense.
NOTE:
 The absence of {C,c,R,r} flags indicates an item that is neither a reply nor
a check list item (such as State, Proxy-State).
 All FLAG characters on a given attribute line must be clustered together

to parse properly. No white space is allowed between individual characters.
Related Using RADIUS Client Dictionary Files on page 186

Documentation

Understanding RADIUS Attributes Policies
You can configure RADIUS attributes policies on the Policy Secure gateway to send
return list attributes to an 802.1X NAD. For example, you can specify which VLAN
endpoints must be used to access the network. You can also configure other functions
on a NAD's port based on the role assigned to the user who is currently using that port.
For example, a particular switch might let you use return list attributes to configure
Quality-of-Service (QoS) functions (Bandwidth or Priority) on the device's port based
on the current user's role.
A return list is a set of attributes that the Policy Secure gateway returns to the NAD after
authentication. The return list usually provides additional parameters that the NAD needs
to complete the connection. Return list attributes are authorization configuration
parameters.
The specific attributes in each RADIUS packet depend upon the NAD or RADIUS server
that sent the packet. Different kinds of NADs may require different attributes to control
their behavior.
In the RADIUS attributes policy, you can select RADIUS attributes by name from a
predefined list. For each attribute, you specify values using strings or numbers.

By default, the Policy Secure gateway sends a session timeout value on all RADIUS
accepts that is equal to the timeout value of the configured session length. You can
bypass the default timeout.
If you do not want to either assign endpoints to a VLAN or, return any RADIUS attributes,
select the Open Port option. With this check box selected, the Policy Secure gateway will
not return any RADIUS attributes.
Related RADIUS Attributes Policy Configuration Guidelines on page 191

Documentation

RADIUS Attributes Policy Configuration Guidelines
Topic Details
Network access device and RADIUS attributes Be sure to select the correct make and model of the NAD. During
authentication, the Policy Secure gateway filters the return list based on
the dictionary for the NAD that sent the authentication request. The
Policy Secure gateway omits any return list attribute that is not valid for
the device.
Dictionaries You can return RADIUS attributes that are in the installed dictionaries
or in dictionaries you have uploaded to the Policy Secure gateway.
Matching the policy The RADIUS return attributes are based on the first RADIUS attributes
policy that matches both the location group of the NAD and the roles
assigned to the user.
Related  Creating a RADIUS Attributes Policy on page 192

Documentation

Creating a RADIUS Attributes Policy
Before you configure a RADIUS attributes policy, verify the following configuration on
the NADs you want to use with the Policy Secure gateway:
 The NAD supports RADIUS-based, dynamic VLAN assignment if the VLAN check box
is selected.
 The ports are 802.1X enabled.
 The VLAN IDs you want to use in the Policy Secure gateway RADIUS VLAN
policies are configured on the NADs if the VLAN check box is selected.
 The endpoints are able to obtain an IP address from a DHCP server that is in the VLAN
you are using.
Any modifications to the RADIUS attributes page causes endpoints with sessions
associated with the attributes policy to re-connect. We recommend that you schedule
any changes at a time when endpoints are not affected.
To configure a RADIUS attributes policy:
1. In the admin console, select UAC > Network Access > RADIUS Attributes.
a. For Name, enter a name to label this policy.
b. (Optional) For Description, enter al description for the policy.
4. Under Location Group, select the location groups to which you want to apply this
policy, and click Add. To apply the policy to all location groups, do not add any location
groups and use the default setting (all) listed in the Selected Location Groups list.
5. Under RADIUS Attributes, select from the following options:
 Open Port—Check this option if you do not want to assign endpoints to a VLAN or
return any RADIUS attributes. Selecting this check box disables all other RADIUS
Attributes options.
 VLAN—Select this option to configure VLAN assignment according to RFC 3580 by

returning the RADIUS tunnel attributes to the NAD. Specify the existing VLAN ID on
the network infrastructure that you want to use for the role(s) to which this policy
applies. Selecting this option is equivalent to manually specifying the three RFC
3580 RADIUS tunnel attributes in the Return Attribute section.
 Return Attribute—Select this option to specify the return attributes you want sent
to the NAD, select Return Attribute and then do the following:

 From the Attribute list, select the return attribute to send. For User Attribute, enter
the return user attribute to be matched against the user attributes obtained from
the authentication server. For Value, enter the value for the selected attribute.
Then click Add.
 You can specify multiple return attributes and values for this policy.
 To add an attribute, select a new attribute from the list and enter the appropriate
value. To change an attribute value, click the value, enter the appropriate value,
and then click the check mark icon next to the value.
 To rearrange the order in which you want to send the return attributes, select the
check box next to the attribute name and then click the up or down arrow.
 To delete an attribute, select the check box next to the attribute name. Then click
Delete.
 Add Session-Timeout attribute with value equal to the session lifetime—Clear this
check box to prevent the Policy Secure gateway from sending a session timeout
value equal to the timeout value of the configured session length on all RADIUS
accepts. This allows you to set the reauthentication timer statically on the switch
port, if required.
If you are using MAC address authentication (with an unmanageable device) and
you select the Add Session-Timeout attribute with value equal to the session lifetime,
the session timeout value that the Policy Secure gateway sends is 60 seconds less
than what is configured in Max session length for the role that is configured for
MAC authentication.
If you select this check box, you can select Add Termination-Action attribute with
value equal 1. The termination-action attribute indicates what action should be
taken when the session ends. The value 1 indicates that the session should attempt
reauthentication.
6. For Interface, specify the Policy Secure gateway network interface that endpoints
affected by this policy to use to connect to the Policy Secure gateway:
 Automatic (use configured VLANs)—Select this option to use VLAN tagging. You
must also connect the Policy Secure gateway internal interface to the trunk
port on a VLAN-enabled switch that sees all of the VLAN traffic.
 Internal— Select this option if the endpoints using this RADIUS attributes policy
should use the IP address of the Policy Secure gateway's internal interface to
communicate with the Policy Secure gateway.
 External—Select this option if the endpoints on the configured VLAN should use the
IP address of the Policy Secure gateway's external interface to communicate with
 Policy applies to ALL roles—To apply this policy to all users.
 Policy applies to SELECTED roles—To apply this policy only to users who are mapped
to roles in the Selected roles list. Be sure to add roles to this list from the Available
roles list.

 Policy applies to all roles OTHER THAN those selected below—To apply this policy
to all users except for those who map to the roles in the Selected roles list. Be sure
to add roles to this list from the Available roles list.
Related Understanding RADIUS Request Attribute Policies on page 194

Documentation

Understanding RADIUS Request Attribute Policies
You can configure RADIUS request attribute policies to enforce the action of processing
authentication requests based on information in the RADIUS packet before a connection
can be authenticated. You assign RADIUS request attribute policies as a realm restriction.
Any authentication request that comes from a realm with attribute policy requirements
must send the RADIUS attributes specified in the policy, otherwise the authentication
request is not granted. If multiple rules are configured in a policy, the user must pass all
of the rules, otherwise authentication fails.
When a user authentication fails because it did not meet the requirements specified in
the RADIUS request attribute policy, a user event log message is displayed that includes
information about which policies the user met or failed. Debug logs allow the administrator
to determine that a user met the policies, or indicate that the user failed a RADIUS return
attribute policy.
RADIUS request attribute policies consist of rules. Each rule consists of one attribute and
some number of values. The type of value depends on the type of rule chosen. For
example, if you select a rule with the User-Name attribute, you enter a string.
NOTE: Each request page includes guidance on what type of value is

expected.
If you select a rule with the Login-IP-Host attribute, you enter an IP address and an
optional netmask. The default netmask value is 255.255.255.255. The value of the
attribute must fall within the specified IP address and netmask to pass the policy.
For attributes that require an integer value, you can use a wildcard as the value to ensure
that these attributes exist in the request.
Wildcard values include the following:
 For a string: an asterisk (*) and (?) (The * matches multiple characters and the ?
matches a single character.)
 For an integer: the * matches any value for the attribute.

 For a hexadecimal type: Any hexadecimal value, or the * to match any value for the
attribute.
Related Configuring a RADIUS Request Attribute Policy on page 195

Documentation

Configuring a RADIUS Request Attribute Policy
To configure RADIUS request attribute policies:
Attributes
> Request Attributes.
2. Click New.
3. Enter a name in the Policy Name box. You select the policy when you create a realm.
4. Optionally, describe the policy in the Description box.
5. Select a Rule Setting ( attribute) from the list, then click Add. A new page opens that
allows you to enter values for the attribute type you selected.
6. Add values that are specific to the type of RADIUS attribute you have selected, then
click Add. You can add any number of values to the list. To delete a value, select the
check box and click Delete. Any RADIUS authentication request must contain one of
the values that you define.
For some rule types a list is displayed. Select the appropriate value from the list.
7. After you populat the list, click Save Changes.
You can add more RADIUS attribute requirements by adding new rule settings.
8. Click Save Changes. The policy is now visible on the User Realms > User > Authentication
Policy > RADIUS Request Policies page. Populate the Selected RADIUS Request
Attribute Policies list with the policies you created.
Related Understanding RADIUS Attribute Logging on page 195

Documentation

Understanding RADIUS Attribute Logging
You can configure the Policy Secure gateway to enable or disable authentication
reporting for RADIUS authentication events. With this feature, you can obtain a
granular record of authentication attempts using configurable, detailed authentication
reports.
You can selectively choose events to record based on both successful and unsuccessful
authentication attempts. If you select an attribute to be recorded and the value is not

present in the authentication request/response, an entry is made in the debug log and
in the RADIUS log.
You can also specify accounting log messages.
The byte limit for log entries is 2048. If a message exceeds this limit, the last value is
trimmed to fall within the maximum, and an entry is made in the debug and RADIUS logs.
Related Configuring RADIUS Attribute Logging on page 196

Documentation

Configuring RADIUS Attribute Logging
To configure RADIUS attribute logging:
Attributes
> Attribute Logging.
2. Select the Authentication Success Log Message and Authentication Reject Log Message
check boxes.
3. To specify accounting log messages, select the Accounting Log Message check box.
4. Select Available attributes from the lists, and click Add to populate the Selected
Attributes lists.
5. Select Save Changes.
Related Understanding RADIUS Attribute Logging on page 195

Documentation

Using RADIUS Attributes in Access Policies
This topic describes how to use the RADIUS attributes options in RADIUS attributes
policies. It describes the following use cases:
 Use Case 1: Configuring VLAN Assignment by Returning RADIUS Tunnel

Attributes on page 196
 Use Case 2: Configuring VLAN Assignment Along with Other Attributes on page 197
 Use Case 3: Configuring VLAN Assignment or Policies by using the Filter-ID Return
Attribute on page 197
 Use Case 4: Configuring VLAN Assignment in a Heterogeneous Environment on page 197
 Use Case 5: Using RADIUS Attributes with OAC to Avoid Disconnecting Concurrent
Network Connections on page 198
Use Case 1: Configuring VLAN Assignment by Returning RADIUS Tunnel Attributes

This use case describes how to configure VLAN assignment on NADs by returning RADIUS
tunnel attributes according to RFC 3580.
1. Select UAC > Network Access > RADIUS Attributes, select VLAN.

2. Specify a VLAN ID.
Use Case 2: Configuring VLAN Assignment Along with Other Attributes

This use case describes how to configure VLAN assignment and other features on NADs
by returning RADIUS tunnel attributes in addition to returning other attributes.
1. On the UAC > Network Access > RADIUS Attributes, select VLAN.
2. Specify a VLAN ID.
3. Select Return Attribute.
4. Select the attribute you want to return from the Attribute list.
5. For Value, specify an attribute value.
Use Case 3: Configuring VLAN Assignment or Policies by using the Filter-ID Return Attribute
This use case describes how to configure VLAN assignment or other policies on NADs by
using the Filter-ID return attribute.
1. Select UAC > Network Access > RADIUS Attributes > Return Attribute.
2. Select Filter-ID from the Attribute list.
3. For value, specify the policy name.
4. Configure the filter on the NAD.
Use Case 4: Configuring VLAN Assignment in a Heterogeneous Environment

For this use case, you must have a heterogeneous network environment that includes
NADs from a variety of vendors. For example, you might have one type of switch that
supports RADIUS tunnel attributes only, a second type of switch that supports the Filter-ID
return attribute only, and a third type of switch that supports both.
1. Select UAC > Network Access > Location Group and create a location group policy for
each type of NAD.
a. Create a location group policy for switches that support RADIUS tunnel attributes
only.
b. Create a second location group policy for switches that support the Filter-ID return
attribute only.
c. Create a third location group policy for switches that support both RADIUS tunnel
attributes and the Filter-ID return attribute.
2. Select UAC > Network Access > RADIUS Client. Then, follow these steps to create a
RADIUS client policy for each type of NAD and associate each RADIUS client policy
with the appropriate location group.
a. Create a RADIUS client policy and specify a make/model for Make/Model that
supports the RADIUS tunnel attributes. Associate this policy with the location group
policy for switches that support RADIUS tunnel attributes only.

b. Create a second RADIUS client policy and specify a make/model that supports
the Filter-ID return attribute. Associate this policy with the location group policy
for switches that support the Filter-ID return attribute only.
c. Create a third RADIUS client policy and specify a make/model that supports the
both RADIUS tunnel attributes and the Filter-ID return attribute. Associate this
policy with the location group policy for switches that support both RADIUS tunnel
attributes and the Filter-ID return attribute.
3. Select UAC > Network Access > RADIUS Attributes. Then, follow these steps:
a. Create a RADIUS Attributes policy that specifies only the VLAN option and a value
for VLAN ID. Associate this policy with the location group policy for switches that
support RADIUS tunnel attributes only.
b. Create a second RADIUS Attributes policy that specifies only the Filter-ID option
from the Attribute list and a policy name for Value. Associate this policy with the
location group policy for switches that support the Filter-ID return attribute only.
c. Create a third RADIUS Attributes policy that specifies both the VLAN option and
a value for VLAN ID, and the Filter-ID option with a policy name for Value. Associate
this policy with the location group policy for switches that support both RADIUS
tunnel attributes and the Filter-ID return attribute.
NOTE: If all the dictionaries are correct, you do not need to create three
separate RADIUS attributes policies. The Policy Secure gateway will strip
out attributes that do not conform to the RADIUS client’s dictionaries.
Use Case 5: Using RADIUS Attributes with OAC to Avoid Disconnecting Concurrent Network
Connections
You can configure RADIUS attributes to work with a connected switch to prevent expired
sessions from disconnecting concurrent network connections.
When a Policy Secure gateway session reaches its maximum lifetime (as specified on
the Session Options tab on the Role settings configuration page), all access to the
network through UAC is terminated. If OAC is used for access, OAC logs off the network
(via EAPoL-LogOff). Any access provisioned through the Infranet Enforcer is removed.
OAC then initiates a new session. If a new session is established, network connection is
reprovisioned. However, in most cases any TCP connections that were established prior
to the end of the Policy Secure gateway session expire and must be re-established. For
example, any remote desktop or Telnet sessions ends and the user must restart them.
You can configure a timeout that is shorter than the Policy Secure gateway session
lifetime so that the Policy Secure gateway can periodically verify that OAC is still
operating correctly. You can configure a shorter session timeout on a switch or wireless
access point in a number of ways.

 Configure a shorter Session-Timeout RADIUS return attribute in RADIUS Attributes

policies. Depending on the switch or wireless access point. You might also have to
configure a Timeout-Action RADIUS return attribute. In addition, you might have to
configure the switch or wireless access point so that it will respond to these attributes.
 You can configure the switch or wireless access point with a shorter session timeout.
You must also configure the switch or wireless access point to ignore Session-Timeout
RADIUS return attributes from the Policy Secure gateway.
When the switch or wireless access point times out a session, OAC can resume the
Policy Secure gateway session by interacting in one or two ways with the Policy Secure
gateway without interrupting network access.
 TTLS session resumption—OAC accesses the Policy Secure gateway based on TLS
keying material from the previous session.
 DSID session resumption—The TTLS session fails to resume but the Policy Secure
gateway session is still valid. TTLS session resumption can fail if OAC is configured for
a shorter TTLS session resumption maximum than the length of the IC session. In
DSID session resumption, OAC accesses the Policy Secure gateway using new TLS
keying material, but does not create a new IC session. You configure Session
Resumption on the OAC Tools
> Options panel.
Related Understanding RADIUS Attributes Policies on page 190

Documentation
 RADIUS Attributes Policy Configuration Guidelines on page 191

Use Case: Using an EX Series Ethernet Switch as a RADIUS Client
This topic shows how to configure the Juniper Networks EX Series switch as a RADIUS
client in a Pulse Policy Secure deployment. It includes the following information:
 Hardware and Software Requirements on page 199

 Topology and Overview on page 200
 Configuration on page 201
Hardware and Software Requirements

Ensure the following:
 JunosOS Release 9.0 or later for EX Series switches
 One EX4200 switch acting as an authenticator. The ports on the authenticator serve
as a control gate that blocks all traffic to and from supplicants until users or devices
are authenticated.
 The Policy Secure gateway, which acts as the authentication server with access to
credential information for users that have permission to access the network.
 Before you connect the devices, be sure to do the following:

 Install the switch. For more information see Installing and Connecting an EX4200
Switch.
 Perform the initial switch configuration. See the Connecting and Configuring an EX
Series Switch (J-Web Procedure).
 Set up basic bridging and VLAN configuration on the switch. For more information
see Example: Setting Up Basic Bridging and a VLAN for an EX Series Switch.
 Configure the Policy Secure gateway as a RADIUS server and configure

users on an authentication server.
Topology and Overview

Figure 17 on page 201 shows the EX4200 switch connected to the Policy Secure gateway
and to assorted endpoints and network devices.
Switch Settings—EX4200 access switch, 24 Gigabit Ethernet ports, 8 authenticator

ports, (ge-0/0/0 through ge-0/0/7) and 16 nonauthenticator ports (ge-0/0/8 - ge-
0/0/23).
VLAN name—default.
Policy Secure gateway Settings—IP address 10.0.0.100, connected to switch at port ge-
0/0/10, Juniper Networks Client (Junos) selected as the RADIUS client.
In this example, connect the Policy Secure gateway to access port ge-0/0/10 on the
switch. The switch acts as the authenticator and forwards credentials from the
supplicant to the Policy Secure gateway. You must configure connectivity between
the EX4200 switch and the Policy Secure gateway by specifying the IP address of the
Policy Secure gateway and the shared secret from the RADIUS client. This information
is configured on the switch. For more information, see the Junos OS System Basics
Configuration Guide.

Figure 17: 802.1X Deployment with the EX4200 Switch
Configuration
Step-by-Step To connect the Policy Secure gateway to the switch:
Procedure
1. Define the IP address of the Policy Secure gateway and configure the shared secret.
[edit access]
user@switch# set radius-server 10.0.0.100 secret juniper
2. Configure the authentication order, making the RADIUS the first method of
authentication.
[edit access]
set profile profile1 authentication-order radius
3. Configure a list of IP addresses for authenticating the supplicant.
[edit access]
user@switch# set profile1 radius authentication-server 10.0.0.100 10.2.14.200
4. Display the results of the configuration.
user@switch> show configuration access
radius server {
10.0.0.100
port 1812;

secret "$9$qPT3ApBSrv69rvWLVb.P5"; ## SECRET-DATA
profile profile1{
authentication-order radius;
radius {
authentication-server 10.0.0.100 10.2.14.200;
Verification
Step-by-Step To confirm that the configuration is working properly:

Procedure
1. Verify the connection by pinging the switch:
user@switch ping 10.0.0.100

You should receive ICMP echo responses from the Policy Secure gateway.
Related  Understanding Pulse Policy Secure RADIUS Server Features on page 167
Documentation
802.1X Network Access Device on page 180
Associating an Infranet Enforcer with the Pulse Policy Secure RADIUS Server
If desired, you can use the Pulse Policy Secure RADIUS server for admin auth to an
Infranet Enforcer (ScreenOS or Junos OS). On the Pulse Policy Secure side, the
configuration is simple, and the RADIUS client configuration for the Infranet Enforcer is
created automatically.
To associate an Infranet Enforcer with the Pulse Policy Secure RADIUS server:
1. Configure the firewall to use the Pulse Policy Secure RADIUS server for
administrator access.
On Junos Enforcers, the commands are similar to the following example:
On ScreenOS Enforcers, the commands are similar to the following example:
2. Log into the Pulse Policy Secure admin console, and :
Authentication realm

Sign-in policy
Location group
a.
3. :
4. :
a. Select UAC > Network Access > Location Group.
b. Click New Location Group.
c. On the New Location Group page, enter a name to label this location group policy.
d. (Optional) For Description, enter a description.
e. For Sign-in Policy, select the sign-in policy to associate with the location group.
f. Click Save Changes.
5. Associate the location group with the Infranet Enforcer:
a. Select UAC > Enforcer > Connection. In the Enforcer column, click the name of the
Infranet Enforcer you want to configure.
b. Select the location group from the Location Group list.
c. Click Save Changes.
6. Create a RADIUS attribute return policy:
a.
7. Test your configuration by attempting to log into the Infranet Enforcer as an admin
user. Use the Pulse Policy Secure event logs to help you troubleshoot unexpected
results.
Related Understanding Pulse Policy Secure RADIUS Server Features on page 167
Documentation

Use Case: Using a Non-Pulse Secure 802.1X Supplicant
You can configure 802.1X access to the Policy Secure gateway with OAC, Pulse, or you
can use a non-Pulse Secure 802.1X supplicant. OAC and Pulse are preconfigured with
standard protocols to work with the Policy Secure gateway. To use a non-Pulse Secure
supplicant you must configure the authentication protocols manually. A non-Pulse
Secure supplicant is any client that is configured without the JUAC protocol.
For example, the Microsoft Vista built-in supplicant allows you to select authentication
protocols for inner and outer authentication. To permit the client to access the IC Series

device, you choose the protocols on the endpoint, then select corresponding protocol
sets on the Policy Secure gateway, depending on the authentication server type you are
using.
You must also install a certificate on the client machine and select the certificate as a
trusted root CA. The certificate should be generated from the same CA that the Policy
Secure gateway is using for trusted client CAs.
If you configure endpoints to connect through Layer 2 with non-Pulse Secure supplicants,
Layer 3 functionality of the Policy Secure gateway is not supported, and the user
cannot choose a realm or a role interactively. Configuration options like Host Checker,
session limits, and other restrictions are not applied.
For non-Pulse Secure supplicants, a username suffix can be used to select a realm in
the form user@realm. If a suffix is not used, there are additional options for specifying a
realm.
Windows Vista and Windows XP Service Pack 3 supplicants are supported. If you use
these clients, you can use Statement of Health (SOH) policies in a Host Checker policy.

Documentation
 802.1X
 Before Configuring a Non-Pulse Secure Supplicant on page 204
Before Configuring a Non-Pulse Secure Supplicant
Topic Details
Certificate installation With OAC or Pulse, when users connect with a Policy Secure gateway
that they have not connected with before, certificate information is
presented for the user to accept and trust dynamically. With non-Pulse
Secure 802.1X supplicants, you must install the certificate before
attempting to connect to the Policy Secure gateway.
Realm selection at sign-in When a non-Pulse Secure supplicant attempts to connect to the IC
Series
device and more than one realm is available, the user can select a realm
by adding a suffix to the outer username with @realmname. If no suffix
is present, and you have configured a sign-in policy with more than one
realm, the Policy Secure gateway searches for a realm whose
authentication server supports the authentication protocol that the
endpoint requests. For example, if CHAP is requested, the Policy
Secure gateway skips realms that use an Active Directory server.
Outer proxy realms Host Checker is not downloaded to endpoints that connect with
non-Pulse Secure supplicants. If a realm or a role includes Host
Checker restrictions, only endpoints with OAC can pass the
restrictions.
Non-Pulse Secure clients cannot sign in to the role or realm.

Accounting stops You must configure the access point to send accounting stops so that
the Policy Secure gateway can log when a session ends and update the
session tables.

Topic Details
Username suffixes By default, the User may specify the realm name as a username suffix
check box is not selected. If you choose this option, non-UAC endpoints
access the Policy Secure gateway by entering their credentials in the
format user@realm.
Proxy realm sign-in If you configure a sign-in policy with multiple realms, and one of the
realms is a proxy realm, the user must append a suffix to the username
to access the proxy realm.
Configuring a Non-Pulse Secure Supplicant for 802.1X
To configure a non-Pulse Secure supplicant:
1. Configure authentication protocols on the non-Pulse Secure supplicant according

to the instructions in the vendor’s documentation.
2. Configure corresponding protocols on the Policy Secure gateway by selecting

Authentication
> Signing In > Authentication Protocol Sets in the admin console.
3. Install the certificate from the CA that the Policy Secure gateway is using for trusted
Client CAs.
4. Configure a Certificate Server by selecting Authentication > Auth. Servers.
5. Create a role for the user to access the Policy Secure gateway using a non- Pulse Secure
supplicant.
6. Create a realm for the endpoint by selecting Users > User Realms. Use role-mapping
to associate the role you created for non-Pulse Secure supplicants with the realm.
For the authentication server, select the Certificate Server you created.
7. Create a new sign-in policy by selecting Authentication > Signing In > Sign-In Policies
in the admin console. Associate the authentication protocol set you created with the
realm you created for this connection.
8. Configure a new location group by selecting UAC > Network Access > Location Group
and select the sign-in policy that you created from the Sign-in Policy list.
9. Create a new RADIUS client by selecting UAC > Network Access > RADIUS Client and
select the location group that you created from the Location Group list.
10. Configure a RADIUS attributes policy by selecting UAC > Network Access > RADIUS
Attributes and select the location group created for this connection from the Location
Group section, then select the role(s) configured for this access in the Roles section.
11. Complete the remaining steps to configure 802.1X on the Policy Secure gateway.

Documentation
 802.1X
 Use Case: Using a Non-Pulse Secure 802.1X Supplicant on page 203
 Before Configuring a Non-Pulse Secure Supplicant on page 204

Configuring Access to Switches and Access Points from a Browser
Some switches support Web-based port authentication with CHAP, PAP, or EAP-MD5
Challenge (nontunneled) authentication. You can configure the Policy Secure gateway
RADIUS server to support this functionality.
When a PC is connected to a port via captive portal, the PC receives an IP address from
the local DHCP server resident on the switch.
If a user browses to a properly configured switch, the switch displays an authentication

page. After the user submits the proper credentials, the switch queries the Policy Secure
gateway RADIUS server.
On successful authentication, the temporary IP address expires, and the port is opened
to the user. The PC then gets an IP address from the network DHCP server and the user
is granted access to the network.
Additionally, some switches can authenticate the administrator by querying a RADIUS

server using these protocols.
Related Using the Pulse Policy Secure RADIUS Server on page 166
Documentation
 Understanding Pulse Policy Secure RADIUS Server Features on page 167

 Authenticating Users with Non-Tunneled Protocols on page 206
Authenticating Users with Non-Tunneled Protocols
Follow these basic instructions to configure the Policy Secure gateway to authenticate
users through a switch using nontunneled protocols:
1. Configure an external server or the local authentication server to include authentication

credentials for the device.
2. Create a new authentication server instance on the Policy Secure gateway by

selecting
Authentication > Authentication Servers.
3. Create a new role. It is not necessary to specify detailed role options.
4. Create a new realm that references the authentication server by selecting Users >
User Realms.
5. Create a new protocol set to include CHAP, PAP or EAP-MD5 Challenge by selecting
Authentication > Signing In > Authentication Protocols.
6. Create a sign-in policy by selecting Authentication > Signing In > Sign-In Policy and
specify the default sign-in page, the protocol set you have created, and the new realm.
7. Create a location group by selecting UAC > Network Access > Location Groupand set
the sign-in policy to the sign-in policy created for CHAP authentication.

8. Configure a RADIUS client by selecting UAC > Network Access > RADIUS Client and
specify the new location group.
9. Configure the switch according to the manufacturer’s instructions.
Related Configuring Access to Switches and Access Points from a Browser on page 206
Documentation

Enabling Endpoints to Connect to VLANs behind the Policy Secure gateway
After an endpoint successfully accesses the Policy Secure gateway and the network,
the Policy Secure gateway can continuously monitor the health status of the endpoint
and apply any policy changes.
To enable endpoints to connect to the Policy Secure gateway, use one of the following
configurations:
 If you are using more than two VLANs, connect the Policy Secure gateway internal
interface to the trunk port on a VLAN-enabled switch that sees all of the VLAN traffic.
You must also configure a RADIUS attributes policy with the Automatic setting,
which enables the Policy Secure gateway to take advantage of VLAN tagging. When
connected to a trunk port on a VLAN-enabled switch, the Policy Secure gateway
detects traffic from all VLANs. This is useful if you want to configure separate VLANs
for separate classes of users or endpoints, and you want to make the Policy Secure
gateway accessible from all VLANs.
 In this configuration, you must also create VLAN ports on the Policy Secure
gateway and specify an existing VLAN ID on the network infrastructure.
 You can also configure routing on the network to enable endpoints to access the
Policy Secure gateway over the network. In this case, you must configure RADIUS
attributes policies with the VLAN IDs you are using for endpoints, but you do not need
to configure any VLAN ports on the Policy Secure gateway.
Figure 18 on page 208illustrates an example of using a RADIUS attributes policy to specify

VLANs for endpoints.

Figure 18: Using a RADIUS Attributes Policy to Specify VLANs for Endpoints
Because user 1 is authenticated and the endpoint complies with Host Checker security
policies, the user is assigned a role on the Full Access VLAN that allows full network
access and access to protected resources.
Although User 2 is authenticated, the endpoint does not comply with Host Checker
security policies. The user is assigned a role on the Quarantine VLAN that only allows
access to a remediation server.
Related Understanding RADIUS Attributes Policies on page 190

Documentation


CHAPTER 6
Deployments with Network and Security

Manager
 Understanding Network and Security Manager Support for Policy Secure gateways on page
209
 Configuring the Policy Secure gateway for the Initial DMI Connection on page 212
 General NSM Operations on page 214
Understanding Network and Security Manager Support for Policy Secure gateways
Network and Security Manager (NSM) is a Juniper Networks network management tool
that allows distributed administration of network appliances.
You can use the NSM application to centralize status monitoring, logging, and reporting,
and to administer Policy Secure gateway configurations. You can also manage the
Infranet Enforcer and IDP using NSM. In short, you can manage the complete UAC
solution can be accomplished from a single management interface.
With NSM, you can manage most of the parameters that you can configure through the
Policy Secure gateway admin console. The configuration screens rendered through NSM
are similar to the Policy Secure gateway’s native interface.
NSM incorporates a broad configuration management framework that allows

comanagement using other methods. You can import and export XML from the Policy
Secure gateway’s admin console interface, or you can manage from the Policy Secure
gateway’s admin console.
How the IC Series and NSM Communicate

The Policy Secure gateway and the NSM application communicate through the Device
Management Interface (DMI). DMI is a collection of schema-driven protocols that run
on a common transport (TCP). DMI is designed to work with Pulse Secure platforms to
make device management consistent across all administrative realms. The DMI
protocols that are supported include NetConf (for inventory management, XML-based
configuration, text-based configuration, alarm monitoring, and device-specific
commands), structured syslog, and threat flow for network profiling. DMI supports
third-party network management systems that incorporate the DMI standard However,
only one DMI-based agent per device is supported.

The Policy Secure gateway’s configuration is represented as a hierarchical tree of

configuration items. This structure is expressed in XML that can be manipulated with
NetConf. NetConf is a network management protocol that uses XML. DMI uses
NetConf’s generic configuration management capability and applies it to allow remote
configuration of the device.
To allow NSM to manage the Policy Secure gateway using the DMI protocol, NSM must
import the schema and metadata files from the Pulse Secure Schema Repository, a
publicly accessible resource that is updated with each device release. In addition to
downloading the Policy Secure gateway’s current schema, NSM can also download
upgraded software. The Schema Repository enables access to XSD and XML files
defined for each device, model, and software version.
Before attempting to communicate with NSM, you must first complete the initial
configuration of the Policy Secure gateway. Initial configuration includes network
interface settings, DNS settings, licensing, and password administration.
If you have several Policy Secure gateways to configure in a clustering environment, the
cluster abstraction must first be created in the NSM Cluster Manager. Then, you can add
individual nodes.
After you complete the initial network configuration, you can configure the Policy
Secure gateway to communicate with NSM using the appropriate network information.
Once the Policy Secure gateway has been configured to communicate with NSM, the
Policy Secure gateway contacts NSM and establishes a DMI session through an initial
TCP handshake. All communications between the Policy Secure gateway and NSM
occur over SSH to ensure data integrity.
After the Policy Secure gateway initially contacts NSM and a TCP session is established,
interaction between the Policy Secure gateway and NSM is driven from NSM, which
issues commands to get hardware, software, and license details of the Policy Secure
gateway. NSM connects to the Schema Repository to download the configuration
schema that is particular to the Policy Secure gateway.
NSM then issues a command to retrieve configuration information from the Policy
Secure gateway. If NSM is contacted by more than one Policy Secure gateway as a
member of a cluster, information from only one of the cluster devices is gathered. NSM
attempts to validate the configuration received from the Policy Secure gateway against
the schema from Pulse Secure. Once the Policy Secure gateway and NSM are
communicating, the Policy Secure gateway delivers syslog and event information to
NSM.
After NSM and the Policy Secure gateway are connected, you can make any
configuration changes directly on the Policy Secure gateway, bypassing NSM. NSM
automatically detects these changes and imports the new configuration data.
Changes to Policy Secure gateway cluster members are similarly detected by NSM.
When you make changes to the Policy Secure gateway configuration through NSM you
must push the changes to the device by performing an Update Device operation.

Chapter 6: Deployments with Network and Security Manager
When you double-click the Policy Secure gateway “device” icon in the Device Manager
and select the Config tab, the configuration tree is displayed in the main display area in
the same orientation as items are displayed on the Policy Secure gateway interface.
Available Services and Configuration Options

The following services and options are provided to NSM by the Policy Secure gateway:
 Inventory management service—inventory management service enables management

of the Policy Secure gateways software, hardware, and licensing details. Adding or
deleting licenses or upgrading/downgrading software are not supported.
 Status monitoring service—status monitoring service allows the Policy Secure

gateway’s status to be obtained, including name, domain, OS version,
synchronization status, connection details, and current alarms.
 Logging service—logging service allow the Policy Secure gateways logs to be

obtained in a time-generated order. Logging configuration details that are set on the
Policy Secure gateway will apply to NSM.
 XML-based configuration management service—configuration management service

enables NSM to manage the configuration of the Policy Secure gateway. NSM uses
the same XML Schema as the Policy Secure gateway, so you can troubleshoot NSM
using XML files downloaded from the Policy Secure gateway.
The following device configuration items are not supported:
 Editing licensing information, (though licenses can be viewed)
 Creating clusters, joining nodes to clusters, or enabling or disabling cluster nodes
 Packaging log files or debug files for remote analysis
DMI Communication with the IC Series

To configure the Policy Secure gateway to communicate with NSM you must coordinate
actions between the Policy Secure gateway and NSM administrators. Items such as IP
address, password, HMAC key (a one-time password), and the device ID must be
shared between administrators of both the Policy Secure gateway and NSM.
To connect the Policy Secure gateway and NSM, perform these tasks:
 Install and configure the Policy Secure gateway.
 Add the Policy Secure gateway as a device in NSM.
 Configure and activate the DMI agent on the Policy Secure gateway.
 Confirm connectivity and import the Policy Secure gateway configuration into NSM.
Related Configuring the Policy Secure gateway for the Initial DMI Connection on page 212
Documentation


Configuring the Policy Secure gateway for the Initial DMI Connection
To permit the Policy Secure gateway and NSM to make an initial connection, you must
add an NSM administrative user to the Policy Secure gateway configuration. This
section provides a summary of adding the NSM administrator and configuring the DMI
agent to allow the Policy Secure gateway and NSM to communicate. Complete
configuration of the Policy Secure gateway for authenticating users is outside the scope
of this section.
To initiate a DMI session for communication between the Policy Secure gateway and
NSM:
1. Ensure that basic connection information is configured on the Policy Secure gateway
(network address, DNS, password).
2. Ensure that the proper licenses are installed on the Policy Secure gateway.
3. (Optional) From the Policy Secure gateway admin console, select Authentication >
Auth. servers. Select the Administrator authentication server if you want to use that
server for authentication of NSM's Policy Secure gateway administrator, and create
an admin user to allow NSM to use these credentials to connect to manage the
device.
NOTE: Only password-based authentication servers can be used. One-time

password authentication is not supported.
4. (Optional) Select Administrators > Admin Roles and create a DMI agent administrator
role.
5. (Optional) Select Administrators > Admin Realms and create a new DMI agent admin
realm for the DMI agent on the Policy Secure gateway and use role-mapping to
associate the DMI agent role and realm.
6. On the NSM interface, select the Domain menu and choose the domain to which the
Policy Secure gateway will be added.
7. In Device Manager, click the Add icon and select Device to open the Add Device wizard.
Enter the applicable information required to add a Policy Secure gateway to NSM.
See http://www.juniper.net/techpubs/en_US/nsm2011.4/information-products/pathway-
pages/nsmxpress/2011.4/index.html.
NOTE: You must enter a unique NSM admin username and password on
the NSM UI client. This username will be used on the Policy Secure
gateway as the username for the administrator account that will be
used to manage the Policy Secure gateway. NSM must have a unique
account login to avoid interrupting the communication with the Policy
Secure gateway. NSM automatically generates a unique ID which is used
for the HMAC key.

Chapter 6: Deployments with Network and Security Manager
NOTE:
 In a clustering environment, each cluster node must have its own unique
DMI agent and its own device ID and HMAC key, as each cluster node
maintains its own persistent DMI connection to the management
application.
 The HMAC key and the device id are hashed to identify individual devices
to the application. Pulse Secure recommends that you use a strong
password for the HMAC key value to ensure that the key isn’t guessed.
8. After you have added the Policy Secure gateway to NSM, select System >
Configuration > DMI Agent on the Policy Secure gateway admin console.
9. Under DMI connection, select the:
 Inbound Enabled check box if you are using an SSH secure shell CLI to manage the
Policy Secure gateway. The device can also be managed by integrating an SSH-
aware NetConf that complies with DMI specification.
 Outbound Enabled check box if you are configuring the Policy Secure
gateway to communicate with NSM.
NOTE: When you enable or disable a connection, it takes a few minutes

for the connection state to be updated.
10. Under DMI settings for inbound connections, enter the TCP port in which the Policy
Secure gateway is to accept connections. This TCP port should not be used by any
other Policy Secure gateway processes. We recommend that you use the default port or
a port number larger than 1024.
11. Under DMI settings for outbound connection, enter the NSM Primary Server IP address
or hostname, Primary Port, Backup Server and Backup Port (if applicable), the Device
ID, and the HMAC Key.
12. Select the Admin realm that you have configured for the DMI agent.
The Policy Secure gateway initiates a TCP connection to NSM. After the Policy Secure
gateway is identified to NSM through the HMAC key and device ID hash, The Policy
Secure gateway and NSM negotiate an SSH tunnel, and NSM requests authentication
to the Policy Secure gateway based on the username and password.
If you need to disconnect the device from NSM either disable the DMI agent from the
device, or you can delete the device from the NSM interface. If the DMI connection is later
reestablished, NSM automatically retrieves any configuration changes as well as logs
that have accumulated in the interim.
Related Understanding Network and Security Manager Support for Policy Secure gateways on page
209
Documentation


General NSM Operations
Using NSM with the IC Series and the Infranet Enforcer

To manage Policy Secure gateways and Infranet Enforcers together with NSM, you must
manually perform the initial configuration on the devices, and then import the devices
through the NSM interface.
Managing IPsec with the Infranet Enforcer Through NSM

After an Infranet Enforcer has been imported into NSM, perform all configuration of the
device through NSM, not the Policy Secure gateway.
To use the Policy Secure gateway Enforcer policies to configure IPsec, configure these
policies before managing the Infranet Enforcer with NSM Following this sequence:
 Configure IPsec on the Policy Secure gateway.
 Import the Policy Secure gateway.
 Update the device from NSM.
 Refresh the ScreenOS policies.
When you update the Policy Secure gateway, NSM renames various objects. Refresh the
Infranet Enforcer policies to synchronize the policies. Once NSM and the Infranet
Enforcer are in agreement with the names of objects for IPsec, updates can occur with no
further changes. If any changes to policies on the Policy Secure gateway are made, it
is necessary each time to refresh the policies. It might also be necessary to disconnect
and then reconnect the Policy Secure gateway.
Adding IC Series Clusters

To add a Policy Secure gateway cluster in NSM, first add the cluster, then add each
member. Adding a member is similar to adding a standalone Policy Secure gateway.
You must have a cluster object and all of the cluster members defined in NSM to allow
NSM to access the cluster.
Related Understanding Network and Security Manager Support for Policy Secure gateways on page
209
Documentation

 Configuring the Policy Secure gateway for the Initial DMI Connection on page 212

CHAPTER 7
User Role Access with the SRX Series

Firewall
 User Role Firewall Policies on page 215

 Licensing Restrictions and Disabled Features on page 216
 Terminology for Active Directory SPNEGO Authentication with User Role
Policies on page 217
 User Authentication Sequence for Active Directory on page 219
 Supported Versions on page 220
 Configure an Active Directory Instance on Pulse Policy Secure on page 222
 Active Directory Integration Notes on page 223
 Create the Keytab File and Enable Single Sign-on on page 225
 Configuring SPNEGO Authentication in Browsers on page 226
User Role Firewall Policies
NOTE: For this service, the Junos Enforcer is an SRX Series device.
UAC Release 4.2 introduces two new features that can be used with a
MAGx600-UAC-SRX license:
 A user role firewall policy that does not require an agent on endpoints that provides
user role support on the SRX Series device for specific applications
 Active Directory support that allows authenticated users with Kerberos single sign on
(SSO) to access different resources without passing through Pulse Policy Secure for
reauthentication.
In a standard Pulse Policy Secure (UAC) deployment, users authenticate to the MAG
Series Pulse Secure Gateway device (MAG Series) or a Policy Secure gateway through
a sign-in page, and typically download a client, or are provisioned with agentless access
through a browser.

With a MAGx600-UAC-SRX license, you can use the SRX Series device and the MAG
Series device or the Policy Secure gateway to authorize users at Layer 7 using a
Kerberos ticket.
NOTE:
 For purposes of this documentation, the MAG Series device is referenced.
 You can use SRX Series user role policies with or without the
MAGx600-UAC-SRX license as an alternative to resource access policies
with a standard UAC license.
You create user role policies for a group on the SRX Series device. This allows you to
match policies to a subset of users to specific resources or services.
You create realms and roles on the MAG Series device, and then assign users to roles
through role mapping. When a SRX Series device connects with a MAG Series device,
the roles you have configured are pushed to the firewall. Role-based policies on the SRX
Series device match users with resources. For example, a policy could state that engineers
from a particular group, or role, have access to a specific set of servers.
NOTE: You can also use SRX Series device user role policies without the
MAGx600-UAC-SRX license. There is no single sign-on capability without
the license.
This topic provides an overview of the solution. For complete details see UAC Solution
Guide for SRX Series Services Gateways.
Related Licensing Restrictions and Disabled Features on page 216

Documentation
 Supported Versions on page 220

Licensing Restrictions and Disabled Features
The following licenses are available for the Pulse Policy Secure as a policy decision
point with the SRX Series device:
 MAGx600-UAC-SRX-250U (250 users)
 MAGx600-UAC-SRX-500U (500 users)
 MAGx600-UAC-SRX-5KU (5,000 users)
 MAGx600-UAC-SRX-15KU (15,000 users)
 MAGx600-UAC-SRX-EVAL (250 users, eight week evaluation)

Chapter 7: User Role Access with the SRX Series Firewall
The following admin UI pages are hidden when the MAGx600-UAC-SRX license is applied:
 UAC: Infranet Enforcer: IPsec Routing, IP Address Pools
 Authentication Servers: all are hidden except for Active Directory and local
authentication
 Endpoint Security and Host Checker
 UAC: Network Access (Layer 2 options)
 UAC: Host Enforcer
 IF-MAP Federation
 Pulse Secure client and Odyssey Access Client installation option
 Agent settings for user roles
To learn more about these features please see the referenced topics in this guide.
Please note the following licensing restrictions:
 When a MAGx600-UAC-SRX license is attempted to be installed, no other licenses

may exist (license count must be zero).
 When a MAGx600-UAC-SRX license is installed, no other licenses can be applied.
 The exception to the first two requirements is to allow installation of additional

MAGx600-UAC-SRX licenses (user count is additive).
 There is no change to the default behavior in a cluster. The user count is shared and
added across nodes, so the licenses should be installed in a way that balances the
user count (in the event a node goes down).
NOTE: You can upgrade to a full-featured UAC by applying the appropriate

license, but you must first remove the MAGx600-UAC-SRX license.
Related Configuration Summary on page 221

Documentation

Terminology for Active Directory SPNEGO Authentication with User Role Policies
This section details terminology that is applicable for using Active Directory with the MAG
Series device to permit single sign-on for users.
NOTE: Only Internet Explorer, Firefox (Windows and MacOS), and Google
Chrome browsers are supported with SPNEGO.
Term Description

Generic Security Service Application Program The GSS-API is a generic API for performing client-server authentication.
Interface (GSS-API) Every security system has a unique API, and the effort involved with
adding different security systems to applications is extremely difficult
with the variation between security APIs. With a common API, enterprises
can write to the generic API, and work with any number of security
systems.
The GSS-API is included with most Kerberos 5 distributions. If a particular

application or protocol supports GSS-API, then Kerberos is supported.
Simple and Protected GSS-API Negotiation A security mechanism that enables GSS-API peers to determine whether
(SPNEGO) their credentials support a common set of one or more GSS-API security
mechanisms. If so, it invokes the normal security context establishment
for a selected common security mechanism. This is most useful for
applications that depend on GSS-API implementations and share
multiple mechanisms between the peers.
You must enable SPNEGO for supported browsers.
Keytab A keytab is a file that contains pairs of Kerberos principals and encrypted
keys (derived from the Kerberos password). You use this file to log in to
a Kerberos system without being prompted for a password.
You upload the keytab file when you create the Active Directory instance
on the Junos Pulse Access Service device and enable SPNEGO.
Key Distribution Center (KDC) Part of a system intended to reduce the risk of exchanging keys. A KDC
consists of a an authentication server and a Ticket Granting Server (TGS).
Service Principal Name (SPN) An SPN is the name by which a client uniquely identifies an instance of
a service, in this case a Pulse Policy Secure. If you install multiple
instances of a service on computers throughout a forest, each instance
must have its own SPN. A given service instance can have multiple
SPNs if there are multiple names that clients might use for
authentication. An SPN includes the hostname of the Junos Pulse Access
Control device.
NOTE:
 A running domain controller is required for this solution.
 You must create a machine account or user account on
 You must create a KTPass (keytab) token and import it into the Mag Series
device.
Related Configuration Summary on page 221

Documentation


User Authentication Sequence for Active Directory
Figure 19: Example Configuration
The sequence that permits users to access protected resources is as follows:
 The Pulse Policy Secure gateway connects to the SRX Series device and pushes all of
the configured roles to the firewall.
 The user endpoint connects to the domain by authentication with the Domain Controller.
 The user attempts to access an HTTP resource protected by the SRX Series device.
 There is initially no auth table entry for the user, so the SRX Series device sends a drop
notification to the Pulse Policy Secure gateway, and the endpoint is redirected (via a
HTTP Error 302 - Moved temporarily) through a captive portal.
 The endpoint sends an HTTP GET request to the Pulse Policy Secure gateway for
authentication.
 The Pulse Policy Secure gateway sends the endpoint an HTTP Error 401
Unauthorized with a SPNEGO challenge.
 The endpoint retrieves a service ticket from the key distribution center for a service
principle name (SPN) that matches the Pulse Policy Secure gateway hostname.
 The endpoint resubmits an HTTP GET request to the Pulse Policy Secure gateway
with a SPNEGO authentication token.
 After successful SPNEGO authentication, a session is created on the Pulse Policy Secure
gateway, and an auth table entry is pushed to the SRX Series device.

NOTE: The Pulse Policy Secure gateway permits single sign on by

implementing the Kerberos protocol and SPNEGO.
 The Pulse Policy Secure gateway redirects the endpoint back to the protected
resource, and the endpoint successfully accesses the protected resource.
NOTE:
 The end user should disable pop-up blockers for the browser.
 The browser must be left open to ensure continued access to the

This service enhances integration with Active Directory. When the Pulse Policy Secure
challenges the endpoint with a 401 error for SPNEGO authentication, the endpoint
requests a ticket from Active Directory.
The SPN used for the ticket is the Pulse Policy Secure hostname. The SPN used by the
browser is in the form http/hostname. For this transaction to be successful, the SPN
must be registered with Active Directory as an HTTP service using the hostname
(FQDN).
NOTE: The MAG Series device hostname must be used for the SPN.
The SPN created on the Pulse Policy Secure is composed as

service/<FQDN>@<REALM>.
A sample SPN: HTTP/users.resources.company.com@TESTLAB.COMPANY.COM.
When a ticket arrives in an HTTP header for validation, the SPN is used to load the
password from the keytab file. This password is then used to validate the ticket.
Supported Versions
The Junos Enforcer is an SRX Series device. The Pulse Policy Secure runs on the MAG
Series device or the Policy Secure gateway.
To use the SRX Series device with the Pulse Policy Secure gateway for Layer 7
protection, the SRX Series device must have JunosOS Release 12.1 or greater, and the
Pulse Policy Secure must have Release 4.2 or greater.
Related Licensing Restrictions and Disabled Features on page 216

Documentation


Following is an overview of the configuration details for this solution:
 Ensure that your Active Directory server is properly set up with a domain. Add a user
and SPN that match the MAG Series device hostname. Do not select "User must change
password at next logon.
NOTE: If you are not using Active Directory as an authentication server,

users must log in through the MAG Series device portal. See “About Sign-In
Policies” on page 471.
 Set up and install the SRX Series device. See the applicable hardware guide at
http://www.juniper.net/techpubs.
 Set up the MAG Series device. See http://www.juniper.net/support/products/mag/ for

hardware installation and initial network configuration.
 Connect the MAG Series device and the Junos Enforcer. See “Configuring the Junos
Enforcer to Communicate with the Pulse Policy Secure” on page 86.
 Configure an Active Directory instance on the MAG Series device. See “Using Active
Directory” on page 290.
 Enable Kerberos for users.
 Enable SPNEGO for supported browsers. Supported browsers include:
 Internet Explorer 5.5 and later
 Firefox 1.0 and later
 Apache Mozilla 1.7.3 and later
 Upload a keytab file through the Active Directory configuration page in the admin
console.
NOTE: Task Guidance, on the Pulse Policy Secure admin console can
guide you through the basic configuration steps. Refer to the referenced
topics for more detailed information.
(Optional) Configure another type of authentication server. Note that SSO is not an
option unless Active Directory is used. See “AAA Server Overview” on page 279.
 Configure Roles on the MAG Series device. See “Understanding User Roles” on page 261.
 Configure Realms on the MAG Series device. See “Specifying Role Mapping Rules for
an Authentication Realm” on page 433.

 Configure Security Policies on the SRX Series device.
 Configure Captive Portal on the SRX Series device. The MAG Series device address
must match the AD SPN. See “Understanding the Infranet Enforcer Captive Portal
Feature” on page 109.
Related User Authentication Sequence for Active Directory on page 219

Documentation

Configure an Active Directory Instance on Pulse Policy Secure
To define an Active Directory server:
1. Specify a Name to identify the server instance.
2. Enter the Domain. This is the NetBIOS domain name for the organization. The NetBIOS
short name can be found within Active Directory, under Users and Computers.
3. Enter the Kerberos Realm name. This name should be the same as the domain name
in all capital letters.
4. In the Domain Join Configuration section, enter your Username. This is required if a
machine account has not already been created.
5. Enter the corresponding Password.
6. Select the Save credentials check box. If you do not save these credentials, they are
not remembered after the domain join.
7. Enter the Container Name. This is the name of the container in active directory in which
to create the machine name.
8. Enter the Computer Name. The computer name field is where you specify the name
that the Policy Secure gateway uses to join the specified Active Directory domain as
a computer. Otherwise, leave the default identifier that uniquely identifies your
system.
You may notice that the computer name is prepopulated with an entry in the format
vc0000HHHHHHHH, where HHHHHHHH is a hex representation of the IP address of
the Policy Secure gateway. With unique name (either the one provided by default or
one of your choice) you can more easily identify your systems in the Active Directory.
For example, the name csan be something like vc0000a1018dF2.
In a clustered environment with the same Active Directory authentication server, this
name is also unique among all cluster nodes. The Policy Secure gateway displays
all of the identifiers for all attached cluster nodes.
9. The Join Status check box.
10. Specify the authentication protocol you are using by selecting the following check
boxes:
 Kerberos - This is the most secure method and is required for Kerberos Single Sign-on
authentication.

 Enable NTLM protocol - (This is required for password management.) Kerberos

authentication is attempted first. Select one of the following options as the fallback
protocol.
 NTLMv2 - This is a moderately secure method required for MS-CHAP

authentication.
 NTLMv1 - This is a less secure method which you can select for existing legacy
servers.
11. In the Trusts section, select the Allow trusted domains check box if you are allowing
members of trusted domains to authenticate.
12. In the Nested Group Search Depth field, enter the maximum number of levels to search
through when flattening nested group memberships. Note that the higher the number
you use here the more impacted performance may be.
13. In the SPNEGO Single Sign On section, select the Enable SPNEGO check box to use
the Pulse Policy Secure user role firewall policy feature. Enable SPNEGO if you are
configuring the SSO feature for users. The option to upload a keytab file appears.
14. Upload the keytab that you created on the Active Directory server.
16. Verify that you have made a successful connection with the Active Directory server
by clicking the Test Configuration button.
Active Directory Integration Notes
On Active Directory, there are two steps that must be performed:
 Create a dedicated user for the SPN.
NOTE: You must set a password for the user. User must change password
on next logon should not be enabled, and Password never expires should be
enabled.
 Add the SPN to this user using 'ktpass.exe' (this will generate the keytab).

NOTE:
The SPN must be added in this format: HTTP/hostname@REALM. The
SPN is case sensitive. Note the order of upper case, lower case and upper
case.
 For Active Directory 2008, the commands 'ktpass' and 'setspn' are
already installed. For Active Directory 2003, an add-on pack is required.
Before adding the SPN, it's a good idea to make sure it doesn't already
exist. This will help avoid ticket decryption issues on Pulse Policy Secure.
On the endpoint, the MAG Series device must be added as a trusted host
(with Internet Explorer or Firefox). This can also be done with an Active
Directory group policy. Without this, the browser will not participate in
SPNEGO.
On the MAG Series device, you must upload the keytab file and verify that
the diode turns green (indicating a successful join). SPNEGO does not work
unless the diode is green.
Sample Active Directory Commands

To search for a particular SPN:
C:\>setspn -Q HTTP/dev94.abc-domain.lab.test.com
To search for all the SPNs of user 'spnuser':
C:\>setspn -L spnuser
To delete this SPN of user 'spnuser':
C:\>setspn -d HTTP/dev94.abc-domain.lab.test.com spnuser
In this example, the MAG Series device FQDN is: xyz.abc-domain.lab.test.com and the
AD realm is: ABC-DOMAIN.LAB.JUNIPER.NET. This adds an SPN to the user:
Additional Information
The 'kerbtray.exe' program is helpful for viewing and deleting Kerberos tickets on the
endpoint. Old tickets must be purged from the endpoint if SPNs are updated or passwords
are changed (assuming the endpoint still has a cached copy of the ticket from a prior
SPNEGO request to the MAG Series device. During testing, you should purge tickets before
each authentication request.
A similar program to 'kerbtray.exe' is klist.exe. This is a command line program to view

and purge tickets. This can be downloaded from Microsoft's site.
When troubleshooting, Pulse Secure recommends that you restart the browser
between auth requests to avoid cache issues.

If Internet Explorer pops-up a Windows dialog box during authentication, this signifies
that the IC isn't trusted for SPNEGO. You should add the MAG Series device FQDN under
Options -> Security -> Local Intranet -> Sites -> Advanced.
In Firefox, you can install the 'Live HTTP Headers' plug-in to monitor HTTP traffic. You
should verify that the ticket is being sent as base64 data. To add the MAG Series device
as a trusted host in Firefox, load URL about:config in the address window and set:
network.negotiate-auth.trusted-uris.
User Log Messages on the MAG Series Device
Table 20: Understanding Log Messages Related to Active Directory and SPNEGO
Log Message: AUT30832 2012-01-30 08:41:15 - asgic15 - Possible Causes:The SPN does not exist on Active
[10.64.105.112] System(Users)[] - Kerberos ticket decode failure (An Directory. Note the small number of bytes sent (56). This
unsupported mechanism was requested) value is normally closer to 2K bytes.
AUT30845 2012-01-30 08:41:15 - asgic15 - [10.64.105.112]

System(Users)[] - SPNEGO SSO: received 56 bytes in HTTP header
'Authorization' from 10.64.105.112
Log Message: AUT30831 2012-01-30 08:44:45 - asgic15 - Possible Causes: This log indicates that the Pulse
[10.64.105.112] System(Users)[] - Cannot load SPN Policy Secure requested from the browser was
'HTTP/icvip.juniper.net@JUNIPER.NET' from keytab file (No principal not found in the keytab.
in keytab matches desired name)
Log Message:AUT30832 2012-01-30 09:52:15 - asgic15 - Possible Causes: This log may indicate that the SPN
[10.64.105.112] System(Users)[] - Kerberos ticket decode failure was updated on Active Directory, but Pulse Policy
(Unknown code FF 163) Secure is still using an older keytab.
Log Message:AUT30832 2012-01-30 08:34:58 - asgic15 - Possible Causes: The Active Directory user's password
[10.64.105.112] System(Users)[] - Kerberos ticket decode failure associated with the SPN has changed. Pulse Policy
(Unknown code FF 161) Secure cannot join the domain; the diode must be green
(if you are using Windows 2008).
Related 
Documentation
Create the Keytab File and Enable Single Sign-on
This Active Directory configuration serves two purposes. First, the server must know the
name of the service provided by Pulse Policy Secure, and the shared key used between
the Active Directory server and Pulse Policy Secure. These two operations are
performed using the ktpass command. This command also creates the keytab file,
storing the shared secret.
1. On the Active Directory server, open a command line and use the ktpass command
in the following format:
ktpass -out<filename> -mapuser(username>@<DOMAIN> -princ HTTP/<server

FQDN>@<DOMAIN> -pass<password>

For example, if the FQDN name of Pulse Policy Secure is ic6000.ucdc.com, Users
belong to the UCDC.COM domain, and the account created above, the command is:
ktpass -out ic.ktpass -mapuser icuser@UCDC.COM - princ

HTTP/ic6000.ucdc.com@UCDC.COM - pass Juniper
This creates a file named ic.ktkpass.
2. Upload the ic.ktpass to the Pulse Policy Secure gateway when you enable
SPNEGO in the Active Directory server instance.
3. Navigate to the realm(s) that you have created at Users > User Realms and select the
Enable SSO check box.
Configuring SPNEGO Authentication in Browsers
SPNEGO provides single sign-on capability for users when protected resources are
accessed using a supported browser. SPNEGO performs the server side (Pulse Policy
Secure) of the negotiation, the browser performs the client side negotiation.
When a user requests access to protected resources, the browser uses the login
credentials to negotiate with Pulse Policy Secure to validate the user. After the device
(through an association with an Active Directory server) has confirmed the user, they
are granted access if the user is a member of the domain, SPNEGO has been enabled
in the Active Directory admin page, and the SRX Series device permits access through
the appropriate policies.
The Pulse Policy Secure supports Kerberos sent in SPNEGO tokens.
NOTE: Internet Explorer, Firefox (Windows and Macintosh), and Chrome

browsers are supported.
Browser Configuration
Browsers require setup to enable SPNEGO authentication. SPNEGO configuration for
individual browsers differs.
For Internet Explorer, go to Tools > Internet Options > Security > Local Intranet > Sites
> Advanced and enter the Pulse Policy Secure URL.
Active Directory supports the concept of Group Policies to push configuration to endpoints
when they join the domain. This is an alternative to manual configuration. This can be
used to configure a group of Internet Explorer browsers to set Pulse Policy Secure as a
trusted site.
In Active Directory 2008, the executable ‘gpms.msc’ can be used to create a Group Policy.
This path shows how to navigate the program to add a url under ‘Local Intranet’:

Domains > [DOMAIN] > Group Policy Objects > Default Domain Policy > Edit
Computer Configuration > Policies > Admin Templates > Windows Components > IE >
Internet Control Panel > Security Page > Site to Zone Assignment List > Show
Value name: [DOMAIN]
Value: 1
Google’s Chrome browser shares the same configuration with Internet Explorer. Once
the trusted URL is added in Internet Explorer, Chrome works with SPNEGO. Chrome does
not have a configuration mechanism.
For Firefox, type in “about:config” and search for “trusted”. The required key is a comma
separated parameter named “network.negotiate-auth.trusted-uris”.
For a complete configuration example, see UAC Solution Guide for SRX Series Services
Gateways.


PART 2
Access Management Framework

 General Access Management on page 231
 User Roles on page 261
 AAA Servers on page 279
 Authentication Realms on page 425
 IF-MAP Federation on page 443
 Sign-in Policies on page 471


CHAPTER 8
General Access Management
 Access Management Overview on page 231

 Understanding Realm and Role Restrictions on page 232
 Understanding the Evaluation Process for Policies, Rules, Restrictions, and
Conditions on page 234
 Using the Dynamic Policy Evaluation Feature on page 239
 Using Source IP Access Restrictions on page 241
 Specifying Browser Access Restrictions on page 243
 Specifying Certificate Access Restrictions on page 244
 Specifying Password Access Restrictions on page 245
 Specifying Host Checker Access Restrictions on page 246
 Specifying RADIUS Request Attributes on page 247
 Selecting Single Sign-on on page 247
 Specifying Session Limits on page 248
 Specifying Resources for User Access Control on page 249
 Task Summary: Configuring Session Migration on page 259
 Configuring Session Migration for the Pulse Client on page 260
Access Management Overview
You can use an Infranet Enforcer or an 802.1X NAD (NAD) as the primary policy
enforcement point for the network. You can also use Juniper Networks Intrusion Detection
and Prevention (IDP) product as a policy enforcement measure. In addition to using these
devices to control access, the Policy Secure gateway provides numerous options that
allow you to create more granular access management. Many of these options can be
configured at the role level or the realm level, giving you the flexibility to control user
access before authentication (apply policies at the realm level) or after authentication
(apply policies at the role level).
If you do not have an Infranet Enforcer to protect resources, you can use the Host Enforcer
tool to enforce restrictions on endpoints using OAC. Host Enforcer is a stateful packet

filter built into OAC. You create Host Enforcer policies on the Policy Secure gateway by
specifying resources for access control. Then designate the roles that are allowed or
denied access to those resources.
Related Understanding User Roles on page 261

Documentation

Understanding Realm and Role Restrictions
This topic describes access restrictions you can enforce per realm or per role. It includes
 Restrictions Overview on page 232

 Accessing Authentication Realms on page 233
 Accessing User Roles on page 233
 Realm and Role Restrictions Sequence on page 234
Restrictions Overview
The Policy Secure gateway enables you to secure your company resources using
authentication realms and user roles. This flexibility allows you to control access from a
broad level (controlling who can sign into the Policy Secure gateway) to a granular level
(controlling which authenticated users can access a particular URL or file).
You create policies on the Policy Secure gateway that permit or deny access to
resources and services based on a user’s role and the security compliance of the
endpoint device. With OAC and Pulse, you can incorporate the Infranet Enforcer to
control access more effectively.
The Policy Secure gateway manages the user authentication and roles and stores the
policies. The Policy Secure gateway assigns the user a set of roles. These roles, in
turn, specify what resources the endpoint can access. The Policy Secure gateway
pushes the allow or deny information for the user in the form of firewall policies to the
Infranet Enforcer, OAC, and Pulse. When the Infranet Enforcer and the client have
policies that allow access for the endpoint, the Infranet Enforcer allows traffic between
the endpoint and the protected resources.
Realm and role restrictions are not supported for deployments in which users access the
Policy Secure gateway using non-UAC agents, such as non-Pulse Secure 802.1X
supplicants.

Chapter 8: General Access Management
Accessing Authentication Realms

Resource access begins with the authentication realm. An authentication realm is a
grouping of authentication resources and includes:
 An authentication server—Verifies that the user is who they claim to be. The Policy
Secure gateway forwards the user’s credentials by way of OAC or Pulse, or by using a
sign-in page for agentless and Java agent deployments to an authentication server.
 An authentication policy—Specifies realm security requirements that must be met

before the Policy Secure gateway submits a user's credentials to an authentication
server for verification.
 A directory server—Provides user and group information to the Policy Secure

gateway that the Policy Secure gateway uses to map users to one or more user
roles.
 Role-mapping rules—Specify conditions a user must meet for the Policy Secure
gateway to map the user to one or more user roles. These conditions are based on
either user information returned by the realm's directory server or the user's
username.
 Session Migration—Lets you configure session migration for authentication realms to

allow Pulse users to access multiple devices (Policy Secure gateways and Connect
Secure gateways) without reauthentication.
You can associate one or more authentication realms with a Policy Secure gateway
sign-in page. If a sign-page has more than one realm, the user can specify a realm.
When the user submits credentials, the Policy Secure gateway checks the
authentication policy defined for the realm. The user and the endpoint must meet the
security requirements you define for a realm's authentication policy. Otherwise, the
Policy Secure gateway does not forward the user's credentials to the authentication
server.
At the realm level, you can specify security requirements based on elements, such as the
user's source IP address or the possession of a client-side certificate. If the user meets
the requirements specified by the realm's authentication policy, the Policy Secure
gateway forwards the user's credentials to the appropriate authentication server. If the
server successfully authenticates the user, then the Policy Secure gateway evaluates
the role-mapping rules defined for the realm to determine which roles to assign to the
user.
Accessing User Roles

A role specifies Policy Secure gateway session properties for users who are mapped to
the role. These session properties include information such as session time-outs,
limitations, and restrictions. A role's configuration serves as the second level of user
access control. Not only does a role specify the access mechanisms available to a user,
but you can also specify restrictions with which users must comply before they are
mapped to a role.
At the role level, you can specify security requirements based on elements such as the
user's source IP address and possession of a client-side certificate. If the user meets the
requirements specified either by a role-mapping rule or role restrictions, then the Policy
Secure gateway maps the user to the role. When a user makes a request to the backend

resources available to the role, the Infranet Enforcer or OAC, or Pulse, evaluates the
corresponding resource policies.

You can specify security requirements for a role in two places—in the role-mapping rules
of an authentication realm (using custom expressions) or by defining restrictions in the
role definition. The Policy Secure gateway evaluates the requirements specified in both
areas to make sure the user complies before it maps the user to a role.
Realm and Role Restrictions Sequence

Figure 20 on page 234 shows the order in which the Policy Secure gateway evaluates
realm and role restrictions after a user submits credentials on a sign-in page.
Figure 20: Access Management Sequence for Realm and Role Restrictions
Related Understanding the Evaluation Process for Policies, Rules, Restrictions, and Conditions
  Using the Dynamic Policy Evaluation Feature on page 239
Understanding the Evaluation Process for Policies, Rules, Restrictions, and Conditions
The figures in this section show the transactions that take place between a user and the
Policy Secure gateway and the between Policy Secure gateway and an authentication
server or Infranet Enforcer. The flowcharts begin with a user signing in and end with the
user ending the session by exiting the client or signing out (agentless access
deployments).

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

Figure 22: IC Series Authorizes User
Figure 23: IC Series Maps User to One or More User Roles and Pushes
Policies

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

Pulse Policy Secure Adminis!ration Guide
USER Odyssey Access Client Intranet Enforcer
User requests a resource

selected resource?
YES
User denied access

to resource
•
YES
Odyssey Access Client evaluates Host

Enforcer pol cies
The Odyssey Aooess Client onthe endpoint
evaluates Host Enforcer policies related to the
user's request,sequentially processing each polcy
untilit finds the policy whooe resouroelist and
designated roles match the user's requesl
The Odyssey Acoess Cl ent then allows access to
theresource \Ila foc'. ::! 1
cifiedin the Host
e
NO
OdySS<>y N:,t:,essCliG<'lt
uses IPsec tunnel to
connect to Intranet
Enforcer
Intranet Enforcer firewall evaluates

Intranet Enforcer policies
TheIntranet Enforcer evaluates lnfranet Enforcer
policies related to the user's request,sequentially
processing each polcy until it finds the pol cy whose
User denied access resource list anddesgl\ated roles matchthe us&r's
to resource request.
Th& Intranet Enforc&r tnen p&rfonns theaction
specified-allow 0t deny access 10 th& resourc&.
YES
+
Intranet Enforcer allows access
User accesses resource
or application server The Intranet Enforcer forwards packets between the
endpoint and tne appropriate SGN&r.
User ends session* "At any point during a user session,theIC may force the user out if the
user session reaches the maximum session length,orif dynamic policy
Signs out Qf IC by exiting the Odyssey Access Client. evaluation is enabled and the user falls a policy.

Figure 25: Infranet Enforcer Allows or Denies Access Based on Policy

Match
Related Using the Dynamic Policy Evaluation Feature on page 239

Documentation

Using the Dynamic Policy Evaluation Feature
This topic describes the dynamic policy evaluation feature. It includes the following
information:
 Dynamic Policy Evaluation Overview on page 239

 Understanding Dynamic Policy Evaluation on page 240
 Understanding Standard Policy Evaluation on page 240
 Enabling Dynamic Policy Evaluation on page 240
Dynamic Policy Evaluation Overview

Dynamic policy evaluation allows you to automatically or manually refresh the assigned
roles of users by evaluating a realm’s authentication policy, role-mappings, role
restrictions, and resource policies. When the Policy Secure gateway performs a dynamic
evaluation, it verifies whether the client’s status is changed. (For instance, the client’s
Host Checker status might change, or, if the user is roaming, the computer’s IP address
might change.) If the status has changed, the Policy Secure gateway allows or denies
the user access to the dependent realms, roles, or resource policies accordingly.
The Policy Secure gateway does not monitor changes in user attributes from a RADIUS,
LDAP, or SiteMinder server during dynamic policy evaluation. Instead, the Policy Secure
gateway
re-evaluates rules and policies based on the original user attributes that it obtained when
the user signed in to the Policy Secure gateway.

Understanding Dynamic Policy Evaluation

If the Policy Secure gateway determines after a dynamic policy evaluation that a user no
longer meets the security requirements of a role, the Policy Secure gateway terminates
the connection immediately with the user. The user must take the necessary steps to
meet the security requirements of the role, and then sign in to the Policy Secure
gateway again.
The Policy Secure gateway logs information about policy evaluation and changes in
roles or access in the Event log.
Understanding Standard Policy Evaluation

If you do not use dynamic policy evaluation, the Policy Secure gateway evaluates
policies and roles only when the following events occur:
 When the user first tries to access the Policy Secure gateway sign-in page, the Policy
Secure gateway evaluates the Host Checker policies for a realm.
 Immediately after the user’s initial authentication, the Policy Secure gateway
evaluates the user’s realm restrictions in the authentication policy, role-mapping
rules, and role restrictions.
 When the user requests for resource, the Infranet Enforcer evaluates resource access
policies to determine whether the associated role is allowed to access the resource.
 When the Host Checker status of the user’s machine changes, the Policy Secure
gateway evaluates the Host Checker policies for the role.
If you do not use dynamic policy evaluation and you make changes to an authentication
policy, role-mapping rules, role restrictions, or resource policies, the Policy Secure
gateway enforces those changes if the preceding events occur.
If you use dynamic policy evaluation, the Policy Secure gateway enforces changes if the
preceding events occur, and it enforces changes at the times you specify.
Enabling Dynamic Policy Evaluation

You can use dynamic policy evaluation in the following ways:
 Evaluate all signed-in users in a realm—You can automatically or manually refresh

the roles of all currently signed-in users of a realm by using the General tab of the
Administrators > Admin Realms > Select Realm or Users > User Realms > Select Realm
page. You can trigger the Policy Secure gateway to perform a dynamic policy
evaluation at the realm level based on:
 An automatic timer—You can specify a refresh interval that determines how often
the Policy Secure gateway performs an automatic policy evaluation of all currently
signed-in realm users, such as every 30 minutes. When using the refresh interval,
you can also fine-tune Policy Secure gateway performance by specifying whether
or not you want to refresh roles and resource policies as well as the authentication
policy, role-mapping rules, and role restrictions.
 On-demand—At any time, you can manually evaluate the authentication policy,
role-mapping rules, role restrictions, and resource policies of all currently signed-in

realm users. This technique is especially useful if you make changes to an

authentication policy, role-mapping rules, role restrictions, or resource policies and
you want to immediately refresh the roles of a realm’s users.
 Evaluate all signed-in users in all realms—At any time, you can manually refresh the
roles of all currently signed-in users in all realms by using settings in the System >
Status >Active Users page.
Related Displaying Active Users on page 738

Documentation

Using Source IP Access Restrictions
This topic describes how to use the source IP access restriction feature. It includes the
 Source IP Access Restriction Overview on page 241

 Specifying Source IP Restrictions on page 242
Source IP Access Restriction Overview

Use a source IP restriction at the role or realm level to control from which IP addresses
users can access a Policy Secure gateway sign-in page, be mapped to a role, or access
a resource.
Use a source IP restriction to control from which IP addresses users can access a Policy
Secure gateway sign-in page, be mapped to a role, or access a resource.
You can restrict resource access by source IP:
 When administrators or users try to sign in to the Policy Secure gateway—The user
must sign in from a machine whose IP address/netmask combination meets the
source IP requirements for the authentication realm. If the user's machine does not
have the IP address/netmask combination required by the realm, the Policy Secure
gateway does not forward the user's credentials to the authentication server and the
user is denied access to the Policy Secure gateway. You can allow or deny access to
any IP address/netmask combination. For example, you can deny access to all users
on a wireless network (10.64.4.100), or you can allow access to all other network
users (0.0.0.0).
 When administrators or users are mapped to a role—The authenticated user must

be signed in from a machine whose IP address/netmask combination meets the Source
IP requirements for each role to which the Policy Secure gateway might map the
user. If not, then the Policy Secure gateway does not map the user to that role.
You can also use a source IP restriction in the following ways:
 Source IP restriction on realms—Suppose an Infranet Enforcer is installed between a

particular access network and the rest of the network, and the Policy Secure gateway
routes all traffic through this Infranet Enforcer. You can use a source IP restriction to
allow users to log in from only the access network, because logging in from any other
network results in denial of network access. For example, you can use this
configuration to

prevent users from logging in to the Policy Secure gateway from networks other than a
wireless network.
 Source IP restriction on roles—You can use source IP restrictions to set up different

roles for different access networks. Only endpoints from a particular access network
are assigned the role that corresponds to that network. You can then create Infranet
Enforcer IPsec routing policies and Infranet Enforcer source IP specifically for the that
role so that endpoints route network traffic through the appropriate Infranet Enforcer.
Specifying Source IP Restrictions

To specify source IP restrictions:
1. Select the level at which you want to implement IP restrictions:
 Realm level—Select:
 Administrators > Admin Realms > SelectRealm > Authentication Policy > Source
IP
 Users > User Realms > SelectRealm > Authentication Policy > Source IP
 Role level—Select:
 Administrators > Admin Roles > Select Role > General > Restrictions > Source IP
 Users > User Roles > Select Role > General > Restrictions > Source IP
2. Select one of the following options:
 Allow users to sign in from any IP address—Allows users to sign in to the Policy
Secure gateway from any IP address to satisfy the access management
requirement.
 Allow or deny users from the following IP addresses—Specifies whether to allow

or deny users access to the Policy Secure gateway from all of the listed IP
addresses, based on their settings. To specify access from an IP address:
a. Enter the IP address and netmask.
b. Select either Allow to allow users to sign in from the specified IP address, or Deny
to prevent users from signing in from the specified IP address.
3. Click Save Changes to save your settings.
Related Using Role Restrictions on page 268

Documentation
 Creating an Authentication Realm on page 427


 Understanding the Evaluation Process for Policies, Rules, Restrictions, and Conditions
on page 234
Specifying Browser Access Restrictions
Use a browser restriction to control from which Web browsers users can access a Policy
Secure gateway sign-in page or be mapped to a role. If a user tries to sign in to the
Policy Secure gateway using an unsupported browser, the sign-in attempt fails and a
message is displayed stating that an unsupported browser is being used. This feature
also enables you to ensure that users sign in to the Policy Secure gateway from
browsers that are compatible with corporate applications or that are approved by
corporate security policies.
You can restrict Policy Secure gateway and resource access by browser type:
must sign in from a browser whose user-agent string meets the specified user-agent
string pattern requirements for the selected authentication realm. If the realm
“allows” the browser's user-agent string, then the Policy Secure gateway submits
the user's credentials to the authentication server. If the realm “denies” the browser's
user-agent string, then the Policy Secure gateway does not submit the user's
credentials to the authentication server.

be signed in from a browser whose user-agent string meets the specified user-agent
string pattern requirements for each role to which the Policy Secure gateway might
map the user. If the user-agent string does not meet the “allowed” or “denied”
requirements for a role, then the Policy Secure gateway does not map the user to
that role.
The browser restrictions feature is not intended as a strict access control because a
technical user can change browser user-agent strings. Rather, this feature serves as an
advisory access control for normal usage scenarios.
To specify browser restrictions:
1. Select the level at which you want to implement browser restrictions:
 Realm level—Select:
 Administrators > Admin Realms > Select Realm > Authentication Policy > Browser
 Users > User Realms > Select Realm > Authentication Policy > Browser
 Role level—Select:
 Administrators > Admin Realms > Select Realm > Role Mapping > Select |Create
Rule > Custom Expressions
 Administrators > Admin Roles > Select Role > General > Restrictions > Browser
 Users > User Realms > Select Realm > Role Mapping > Select|Create Rule > Custom
Expression
 Users > User Roles > Select Role > General > Restrictions > Browser

 Allow all users matching any user-agent string sent by the browser— Allows users
to access the Policy Secure gateway or resources using any of the supported Web
browsers.
 Only allow users matching the following user-agent policy—Allows you to define
browser access control rules. To create a rule:
a. For the user-agent string pattern, enter a string in the format
*<browser_string>*
where asterisk (*) is an optional character used to match any character and
<browser_string> is a case-sensitive pattern that must match a substring in the
user-agent header sent by the browser. You cannot include escape characters
(\) in browser restrictions.
b. Select either:
 Allow to allow users to use a browser that has a user-agent header containing
the <browser_string> substring.
 Deny to prevent users from using a browser that has a user-agent header
containing the <browser_string> substring.
c. iii. Click Add.
Rules are applied in order, so the first matched rule applies. Literal characters in rules are
case sensitive, and spaces are allowed as literal characters. For example, the string
*Netscape* matches any user-agent string that contains the substring Netscape.
The following rule set grants resource access only when users are signed in using Internet
Explorer 5.5x or Internet Explorer 6.x. This example takes into account some major non-IE
browsers that send the 'MSIE' substring in their user-agent headers:
*Opera*Deny
*AOL*Deny
*MSIE 5.5*Allow
*MSIE 6.*Allow
* Deny
Specifying Certificate Access Restrictions
When you install a client-side certificate on the Policy Secure gateway, you can restrict
resource access by requiring client side certificates. Select System > Configuration >
Certificates
> Trusted Client CAs in the admin console.

must sign in from a machine that has the specified client-side certificate (from the
proper CA) and with any field/value pair requirements. If the user's machine does not
possess the certificate information required by the realm, the user can access the
sign-in page.
To implement certificate restrictions at the realm level, select:
 Administrators > Admin Realms > Select Realm > Authentication Policy > Certificate
 Users > User Realms > Select Realm > Authentication Policy > Certificate

be signed in from a machine that meets the specified client-side certificate requirements
(proper CA) and optionally field/value pair requirements for each role to which the
Policy Secure gateway might map the user. If the user's machine does not possess the
certificate information required by a role, then the Policy Secure gateway does not
map the user to that role. Select:
 Administrators > Admin Roles > Select Role > General > Restrictions > Certificate
 Users > User Realms > Select Realm Role Mapping > Select|CreateRule > Custom
Expression
 Users > User Roles > Select Role > General > Restrictions > Certificate
The value in the field depends on the naming attributes in the Relative Distinguished
Name(RDN) in the subject DN of the certificate.
For example, if the subject DN is cn=user1, uid=uid1, sn=lastname, E=user1@juniper.net,

OU=QA, O=juniper, C=US, you can use ‘cn’, ‘uid’, ‘sn’, ‘E’, ‘ou’, ‘o’, ‘c’.
But if you use ‘uid’ in a certificate where it does not exist, e.g. cn=user1, ou=QA, o=juniper,
c=us, it will not match. All of the naming attributes in X509 distinguished names are
supported. But to determine what you can use you must know what is in the certificate.
NOTE: This applies to (Admin/User) realm and role certificate restrictions,

but not for Role Mapping rules. With role mapping rules you can use additional
certificate attributes in the rule itself, or in custom expressions.
Specifying Password Access Restrictions
You can restrict Policy Secure gateway and resource access by password-length when
administrators or users try to sign in to a Policy Secure gateway. The user must enter a
password whose length meets the minimum password-length requirement specified
for the realm. Note that local user and administrator records are stored in the Policy
Secure gateway

authentication server. This server requires that passwords are a minimum length of 6
characters, regardless of the value you specify for the realm's authentication policy.
To specify password restrictions:
1. Select an administrator or user realm for which you want to implement password
restrictions:
 Administrators > Admin Realms > Select Realm > Authentication Policy > Password
 Users > User Realms > Select Realm > Authentication Policy > Password
 Allow all users (passwords of any length) — Does not apply password restrictions
on password length.
 Only allow users that have passwords of a minimum length — Requires the user
to enter a password with a minimum length that you specify.
3. Select Enable Password Management to enable password management. You must

also configure password management on the Policy Secure gateway
authentication server configuration page (local authentication server) or through
an LDAP server.
By default, the Policy Secure gateway requires that user passwords entered on the sign-
in page be a minimum of four characters. The authentication server used to validate a
user’s credentials might require a different minimum length. For example, the Policy
Secure gateway local authentication database requires user passwords to be a
minimum length of six characters.
Specifying Host Checker Access Restrictions
Host Checker is a client-side application that is downloaded to endpoints upon the initial
connection with the Policy Secure gateway.
 Predefined rules that check for antivirus software and up-to-date virus signatures,
firewalls, malware, spyware, and specific operating systems from a wide variety of
industry leaders. (On Windows machines only.)
 (Windows machines only) Custom rules that use integrity measurement collectors
(IMCs) and integrity measurement verifiers (IMVs) to perform customized client-side
checks.
 A variety of other checks to ensure that an endpoint meets the security policies that
you configure.
You can configure Host Checker at the role level or the realm level.

Specifying RADIUS Request Attributes
You can create RADIUS request attribute policies to require authentication requests to
contain specific RADIUS attribute values. If an endpoint attempts to access a realm with
a RADIUS request attribute policy, the endpoint must meet the conditions specified in
the policy.
To add a RADIUS request attribute policy to a realm:
1. Select a user realm on which you want to implement a RADIUS request attributes
policy by selecting Users > User Realms > Select Realm > Authentication Policy >
RADIUS Request Policies.
2. Populate the Selected RADIUS Request Attributes Policies list from the available
RADIUS Request Attribute Policies.
3. By default, all of the RADIUS request policies selected must be passed to allow users
to access a realm. Select the Allow access to realm if any ONE of the selected policies
are passed check box if you would like to allow access if any one of the selected
policies is passed.
 Configuring a RADIUS Request Attribute Policy on page 195
Selecting Single Sign-on
If you select an Active Directory authentication server for a realm, a new SSO option
becomes available under Authentication Policy.
By default, the SSO check box is selected.
When the Pulse Policy Secure realm and the endpoint use the same Active Directory
server, during authentication the endpoint obtains a Kerberos ticket from the Active
Directory server and sends the ticket instead of sending a username and password.
The Pulse Policy Secure verifies the Kerberos ticket and allows Pulse to connect
without prompting for a username and password from the user.

This feature requires the Domain Controller to be reachable to endpoints from where
the user is connecting to the device.
Specifying Session Limits
A session is a single authenticated connection between an endpoint and the Policy

Secure gateway. You can limit the number of sessions for a given realm. Setting the
minimum or maximum limit allows you to configure realms that are more likely to be
available when the Policy Secure gateway is nearing the maximum amount of licensed
users.
Valid numbers for the minimum amount of sessions are from 0 to the license limit. A
default of 0 means there are no limits. All of the realms minimum limits can total the
license limit but cannot exceed it. You cannot modify an existing realm’s minimum limit
or add a new realm’s minimum limit that exceeds the license limit. The maximum limit
can be equal to or greater than the minimum limit for a particular realm. A maximum
limit of 0 means that no users can log in to the realm.
You can also limit the number of concurrent users per session. A user can have multiple
sessions. For example, if a user logs in from two machines in the same realm, an additional
session is created.
Users who enter through a realm with this feature enabled must have no more than the
specified number of sessions open. If the user attempts to open a new session that
exceeds the limit, the client, or a browser dialog on agentless connections, displays a
message giving the user the option to continue or cancel. The current user sessions are
displayed in a table, and the user can delete individual sessions to reach compliance. If
the user’s session limit comes into compliance, the user is given access. If the user cancels,
the Policy Secure gateway does not create the session.
If a user who is connected with agentless access attempts to log in from the same source
IP, the dialog displays the IP address with an asterisk (*) and gives the agentless user
the option to delete the existing session.
If a user with agentless or Java agent access attempts to log in from a source IP from
which a session is established, the Policy Secure gateway automatically replaces the old
session with a new session.
Users can access different realms. If an endpoint accesses the Policy Secure gateway
through multiple realms, multiple sessions are possible. These sessions do not count
against individual realm session limits. The Policy Secure gateway verifies the session
limit check after authentication, but before a session is created.
If administrators reduce the session limits, existing sessions are not effected unless the
Dynamic policy evaluation option is enabled. With Dynamic policy evaluation enforced,
the oldest session(s) of a non-compliant user are silently dropped.
These limits will not be enforced if the realm is configured to proxy outer authentication.

To limit the number of simultaneous sessions:
1. Select Users > User Realms > Select Realm > Authentication Policy > Limits.
2. To limit the number of concurrent sessions, select the check box for Limit number of
concurrent sessions, and type either a Guaranteed minimum and/or Guaranteed
maximum.
3. To limit the number of sessions for users, select Limit the number of concurrent sessions
for users.
4. Specify the number of sessions permitted for users in the Session Limit text box. By
default, the number is 1 if the realm maximum is greater than 0; otherwise, the default
is 0. The maximum number must be no greater than the maximum number of
concurrent users for the realm.
Specifying Resources for User Access Control
When you create Host Enforcer policies (for OAC only) and Infranet Enforcer resource
access policies, you must specify the resources to which the policy applies.
The Policy Secure gateway’s engine that evaluates access policies requires that the
resources listed in a policy’s resources list follow a canonical format. This section
describes the canonical formats available for specifying resources in Host Enforcer
policies or resource access policies.
When a user attempts to access a resource, the Policy Secure gateway compares the
request with the resources specified in the corresponding policies, starting with the first
policy in the policy list. When the Policy Secure gateway matches a request, it then
evaluates policy constraints and returns the appropriate action (no further policies are
evaluated). If no policy applies, then the appliance performs the default action for the
policy, which is some cases may be to deny access by taking no action.
When specifying server resources for Policy Secure gateway resource policies, the
consider following guidelines:
protocol://IP address/net-mask:[ports]
The components are:
 Protocol (optional)—Possible case-insensitive values:
 tcp
 tcp_in and tcp_out (Host Enforcer policies only)
 udp

 udp_in and udp_out (Host Enforcer policies only)
 cmp
 icmp://*:*
The only allowed ICMP configuration in a Host Enforcer policy is: icmp://*:* That is, you
cannot specify icmp://ip-addr/net-mask:port as you can for the other protocols.
If the protocol is missing, then all protocols are assumed. If a protocol is specified, then
the delimiter “://” is required. No special characters are allowed.
 IP address/net-mask—The IP address is required, but the netmask is optional. You

can use an asterisk (*)to specify all IP addresses.
 Host (required)—Possible values:
Table 21: DNS Hostname Special Characters

* Matches all characters.
% Matches any character except dot (.).
? Matches exactly one character.
 Ports (optional)—Possible values:
Table 22: Port Possible Values

* Matches all ports; no other special characters are allowed.
port[,port]* A comma-delimited list of single ports. Valid port numbers are 1- 65535.
[port1]-[port2] A range of ports, from port1 through port2, inclusive.
You can mix port lists and port ranges. For example: 80,443,8080-8090.
If the port is missing, then the default port 80 is assigned for http, and 443 is assigned
for https. If a port is specified, then the delimite colon r “:” is required. For example:
tcp://10.10.149.149:22,23
tcp://10.11.0.10:80
udp://10.11.0.10:*

Documentation
 Configuring Resource Access Policies on page 147


Using Host Enforcer Policies
Host Enforcer is a stateful packet filter that is built into OAC. You configure Host Enforcer
policies on the Policy Secure gateway. Host Enforcer is not currently supported on Pulse.
You can use the Host Enforcer feature to protect endpoints and enforce access policies
on the endpoint itself. Host Enforcer is useful in situations where an Infranet Enforcer is
not deployed in front of resources that you want to protect. Host Enforcer is not a
replacement for a firewall.
To use the Host Enforcer feature, you enable the Host Enforcer option on a role. OAC
protects endpoints and resources by allowing only the incoming and outgoing traffic on
the endpoints that you specify in the Host Enforcer policies for that role, in addition to
the traffic allowed by default. You can configure Host Enforcer policies that allow users
access only to the resources you specify.
Host Enforcer provides these security functions:
 Protects endpoints from attacks coming from other endpoints and systems by allowing
only the incoming and outgoing traffic you specify in the Host Enforcer policies for a
role.
 Allows access to the resources you specify in the Host Enforcer policies for a role. This
feature is useful for protecting resources that are not already protected by the Infranet
Enforcer.
If you enable the Host Enforcer option on a role and you do not specify any Host Enforcer
policies for the role, OAC denies all traffic except for traffic that is explicitly allowed both
by default and by rules in the Default Global Policy.
The following types of traffic are allowed by default Host Enforcer internal rules. You
cannot override these rules.
 TCP traffic on port 443 to and from each connected Policy Secure gateway.
 UDP (IKE) traffic on port 500 to each Infranet Enforcer configured by the Policy
Secure gateway.
 UDP traffic on port 4500 to each configured Infranet Enforcer. This traffic is used for
NAT traversal.
 WINS, DNS, and DHCP traffic.
 ICMP Echo Request (Send) and ICMP Echo Reply (Receive)—You can send ping
requests from endpoints to other hosts, and you can receive ping replies from other
hosts back to endpoints for troubleshooting. Incoming echo requests and outgoing
echo replies are blocked on the endpoint. Other hosts cannot ping the endpoint.

 ICMP Destination Unreachable (Receive only), ICMP Source Quench (Receive only),
ICMP Time Exceeded (Receive only), ICMP Traceroute (Send only), ICMP Mobile IP
Reg. Request (Send only), and ICMP Mobile IP Reg. Reply (Receive only).
 NetBios on ports 137/138—If the NetBios name service is used instead of or in addition
to DNS, and NetBios datagram and session service for domain logins and file shares,
NetBios is allowed by default.
The following entries in the Default Global Rules policy can be modified.
 All ICMP and ESP traffic
 Outgoing TCP traffic on all ports
 Outgoing UDP traffic on ports 137 and 138
Since limited traffic is allowed by default, be sure to specify additional traffic you want
to allow for a particular role or for all roles. For example, be sure to configure Host Enforcer
policies to specify the incoming TCP traffic that you want to allow.
You can specify traffic by changing the Default Global Rules policy or creating new Host
Enforcer policies for particular roles. If you create a new policy, the Policy Secure
gateway positions it at the top of the policy list in the Host Enforcer Policies page to
allow your Host Enforcer policy settings to override the Default Global Rules policy or
other policies below it. Use the arrow buttons on the Host Enforcer Policies page to
rearrange the Host Enforcer policies in the order of enforcement priority.
You can also specify the traffic you want to deny on an endpoint. For example, you can
specify a policy that denies outgoing TCP traffic for a particular role, and then use the
Default Global Rules policy placed below that policy to allow outgoing TCP traffic on all
other roles. All of the Host Enforcer policies that apply to the current user’s role(s) are
enforced on the endpoint.
Table 23: Before you Configure a Host Enforcer Policy
Topic Detail
Supported Client OAC is required for Host Enforcer. Host Enforcer is not supported on
Pulse, Java agent, agentless endpoints, or non-Pulse Secure
supplicants
Default Global Rules If you delete the Default Global Rules policy and do not create any
additional policies, Host Enforcer allows the types of traffic specified
by the internal rules.
Access issues To avoid access problems on the endpoints, we recommend that you
configure Host Enforcer policies to allow the specific traffic on endpoints
before you enable the Host Enforcer option on a role
Host Enforcer policies and resource access policies. Avoid creating Host Enforcer policies and Infranet Enforcer resource
access policies that conflict with one another. For example, do not create
a Host Enforcer policy that denies access to resources and an Infranet
Enforcer policy that allows access.

Table 23: Before you Configure a Host Enforcer Policy (continued)
Topic Detail
Multiple roles and Host Enforcer policies If a user is assigned multiple roles and each role has different Host
Enforcer policies, the Policy Secure gateway pushes all of the Host
Enforcer policies that apply to the user to the endpoint. However, the
policies are evaluated in the order specified in the list in the Host
Enforcer Policies page, and the allow or deny action is enforced for the
first policy in the list that matches the resource and user’s role.
Updating Host Enforcer policies The Policy Secure gateway downloads the Host Enforcer policies to
the
endpoint after the user signs in and is authenticated for the first time. If
you change the Host Enforcer policies for the role while the user is signed
in, the Policy Secure gateway pushes the updated Host Enforcer
policies to the endpoint. Updates to the Host Enforcer policies only
occur while the user is signed in.
Host Enforcer and the Infranet Enforcer Avoid creating rules that block traffic to protected resources behind the
Infranet Enforcer.
OAC disconnect If the endpoint becomes disconnected from the Policy Secure
gateway and
OAC is still running, the Host Enforcer policies are no longer enforced
on the endpoint.
Multiple Policy Secure gateways in a You can enable the Require connection to this Policy Secure gateway
network option in the Odyssey Configuration page to require an endpoint
running OAC to connect to a particular Policy Secure gateway. This
allows you to require enforcement of the Host Enforcer policies
configured on that Policy Secure gateway.
ICMP traffic You can either allow all incoming and outgoing ICMP traffic to all hosts,
or use the default ICMP internal rules. That is, the only allowed ICMP
configuration is: icmp://*:* and you cannot specify
icmp://ip-addr/net-mask:port as you can for the other protocols.
UDP traffic If you allow udp_out traffic, Host Enforcer keeps the current state by
automatically allowing the corresponding UDP return traffic, even if
there is no udp_in rule in the policy.
Order of evaluation The resources are evaluated in the order specified in the Resources list
box.
To configure a Host Enforcer policy:
1. In the Policy Secure gateway admin console, select UAC > Host Enforcer.
 For Name, enter a name to label this Host Enforcer policy.
 For Description, optionally enter a description.
4. For Resources, specify the traffic to allow or deny on the endpoints where this Host
Enforcer policy applies to roles, one rule per line using the following syntax:

[<protocol>://']<host>['/'<net mask>]':'<DestinationPorts>[':'<SourcePorts>]
where:
protocol is either <ProtocolNumber> or <ProtocolText> ['_'<Direction>]
where:
ProtocolNumber is the IP protocol number. For example, the protocol number for UDP
is 17.
ProtocolText can be any of the following protocols specified as a text string: TCP,
ICMP, UDP, or ESP
If you do not specify a protocol, the rule applies to all of the allowed protocols.
Direction is the direction of the traffic and specified as one of these two text strings:
in or out. You can specify the traffic direction for TCP or UDP only. For example: tcp_out.
If you do not specify a direction, for example, tcp, the rule applies to both inbound and
outbound traffic.
host is the IP address of the remote host. If you do not specify an IP address, the rule
applies to all IP addresses. You cannot specify a host name in a Host Enforcer policy.
You can only specify an IP address.
netmask is the net-mask number or address of the remote host. If you do not specify
a net-mask, the rule applies to a single IP address.
DestinationPorts is a range or comma-delimited list of the destination ports for the

outgoing traffic.
SourcePorts is a range or comma-delimited list of the source ports of the incoming

traffic. If you do not specify the source ports, the rule applies to all ports.
Table 24: Examples of Specifying Resources in a Host Enforcer Policy
Specify this protocol To allow
tcp_out://*:21,80,443 Outgoing TCP traffic on ports 21, 80, and 443 only
tcp_in://10.11.0.0/255.255.0.0:*:20 Incoming FTP traffic from 10.11.0.0/255.255.0.0 on FTP

server port 20 to all ports on the endpoint
udp_in://*:* Incoming UDP traffic from all IP addresses to all ports on

the endpoint
icmp://*:* Incoming and outgoing ICMP traffic from all IP addresses

to all ports on the endpoint
 Policy applies to ALL roles—To apply this Host Enforcer policy to all users.
 Policy applies to SELECTED roles—To apply this Host Enforcer policy only to users

 Policy applies to all roles OTHER THAN those selected below—To apply this Host
Enforcer policy to all users except for those who map to the roles in the Selected
roles list. Be sure to add roles to this list from the Available roles list.
6. Under Action, specify whether to allow or deny the traffic you specified for Resources.
For example, you can create a policy that denies outgoing TCP traffic for a particular
role.
If you have not already done so, enable the Host Enforcer option on a role.
To copy a Host Enforcer policy as a starting point for a new policy that you want to create,
select the policy in the Host Enforcer Policies page, and then click Duplicate.

Documentation
 Specifying Role Access Options on page 274

Understanding Session Migration
This topic describes the session migration feature. It includes the following information:
 Session Migration Overview on page 255

 Session Migration and Session Timeout on page 257
 How Session Migration Works on page 257
 Session Migration and Session Lifetime on page 258
 Session Migration and Load Balancers on page 258
 Authentication Server Support on page 258
Session Migration Overview

When you enable session migration on two or more Pulse servers, a Pulse endpoint can
migrate from one location to another and connect to a different Pulse server without
providing additional authentication. For example, a user can be connected from home
through a Pulse Connect Secure server, and then arrive at work and connect to a Pulse
Policy Secure server without being reauthenticated. If session migration is not enabled,
Pulse users must be reauthenticated each time they attempt to access the network
through a different Pulse server.
Sessions can be migrated between Pulse Policy Secure and Pulse Connect Secure servers
that are in the same IF-MAP federated network: using either the same IF-MAP server, or
using IF-MAP servers that are replicas of one another.
The servers must be in the same authentication group. Authentication groups are
configured through authentication realms. An authentication group is a string that you
define for common usage. You can use authentication groups to group together realms
with similar authentication methods. Such as, one authentication group for SecurID
authentication, another authentication group for AD. A single gateway can belong to
more than one authentication group, with a different authentication group per realm.

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

Figure 26: Requirements for Pulse Session Migration
Start
Access Access
Using a supported
Support Yes devices in Yes devices in the Yes
Session Yes the same IF-MAP same
Migration? authentication federated authentication
system? network? group?
No No No No
Client
Configuration
(connections and
connection
policies)
Client
Preconfiguration
(select
components for
the client)
Distribute
Pulse based on
Role or create and
distribute installer
package
Session Migration and Session Timeout

Session timeout on the authenticating server does not apply to a migrated session.
Instead, session start time is applicable. The inbound server evaluates session timeout
using the start time of the original session on the original server.
When a user reboots an endpoint for which session migration is enabled, the session is
retained for a short time on the server. For sessions on the Pulse Policy Secure server,
sessions are retained until the heartbeat timeout expires. For Pulse Connect Secure
server sessions, the idle timeout determines how long the session is retained.
If an endpoint that is connected to a Pulse Policy Secure server or Pulse Connect

Secure server is rebooted and the user does not sign out, when the endpoint is restarted
and the user attempts to connect to the same access gateway, Pulse resumes the
previous session without requesting user credentials if the previous session is still
active.
How Session Migration Works

Session migration uses IF-MAP Federation to coordinate between servers.
When a session is established, the authenticating gateway publishes the session

information, including a session identifier, to the IF-MAP server. The session identifier is
also communicated to the Pulse client.

When the Pulse client connects to a migrating gateway in the same authentication group,
the Pulse client sends the session identifier to the migrating gateway. The migrating
gateway uses the session identifier to look up the session information in the IF-MAP
server. If the session information is valid, the migrating gateway uses the session identifier
to establish a local session for the endpoint that the Pulse client is running on.
The IF-MAP server notifies the authenticating gateway that the user session has migrated,
and the authenticating gateway deletes the session information from the IF-MAP server.
Session Migration and Session Lifetime

Session migration is designed to give users maximum flexibility and mobility. Users are
no longer tied to the office. The workplace can travel with the user, and electronic chores
such as online banking can come to work. Because of this flexibility, users might be away
from their machines for long periods of time, allowing their active session to expire.
Session migration requires users to have an active session on the Pulse Policy Secure or
Pulse Connect Secure server.
You can adjust session lifetime to ensure that sessions do not time out while users are
away from their machines. You adjust session lifetime on the gateway by selecting Users
> User Roles > Role Name > General > Session Options in the admin console.
Session Migration and Load Balancers

A Pulse client that connects to a Pulse server that is behind a load balancer will attempt
to migrate the network connection if the connected server fails. The Pulse servers must
be federated and configured for session migration. For example, a load balancer that
balances to 2 Pulse servers (non-clustered) balances to Server1. If Server1 fails, the load
balancer then balances to Server2. A Pulse client that is connected to Server1 is migrated
to Server2 without re-authentication.
Authentication Server Support

The behavior of session migration depends to some extent on the authentication server
on the inbound side.
The following list provides a summary of authentication server support:
 Local authentication server—Migration succeeds if the username is valid on the local

authentication server.
 LDAP server—Migration succeeds if the LDAP authentication server can resolve the
username to a distinguished name (DN).
 NIS server—Migration succeeds if the NIS authentication server can find the username
on the NIS server.
 ACE server—Migration always succeeds.
 RADIUS server—Migration always succeeds. If you select Lookup Attributes using

Directory Server, no attributes are present in the user context data.
 Active Directory—Migration always succeeds. The Lookup Attributes using Directory

Server option might not work, depending on your configuration.

 Anonymous—No support for migrating sessions because sessions are not authenticated.
 Siteminder—No support for migrating sessions because Siteminder SSO is used instead.
 Certificate—No support for migrating sessions because sessions are authenticated

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

Documentation
 Configuring Session Migration for the Pulse Client on page 260

 Understanding Federated Deployments on page 443

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

Documentation  Task Summary: Configuring Session Migration on page 259


CHAPTER 9
User Roles

 Defining Default Options for User Roles on page 266
 Configuring General Role Options on page 267
 Configuring a Guest User Account Management Role on page 267
 Using Role Restrictions on page 268
 Specifying Session Options on page 268
 Specifying UI Options for Agentless Access on page 271
 Setting Up E-mail for Guest User Accounts on page 272
 Creating a MAC Address Authentication Role on page 274
 Use Case: Using a Host Checker Policy with the Host Enforcer on page 276
Understanding User Roles
This topic describes how user roles are used in the Pulse Policy Secure policy
framework. It includes the following information:
 User Roles Overview on page 261

 User Role Evaluation on page 262
 Permissive Merge Guidelines on page 265
 Configuration of User Roles on page 265
User Roles Overview

A user role defines user session parameters (session settings and options) and
personalization settings (user interface customization). At the role level, you specify
whether associated endpoints download OAC, Pulse, the Java agent, or whether agentless
access is permitted.
A user role does not specify resource access control or other resource-based options for
an individual request. The individual resources that a user can access are defined by the
Infranet Enforcer resource access policies, Host Enforcer policies, or RADIUS attribute
policies that you configure separately.

The Policy Secure gateway supports two types of user roles:
 Administrators—An administrator role specifies Policy Secure gateway management

functions and session properties for administrators who map to the role. You can
customize an administrator role by selecting the Policy Secure gateway feature sets
and user roles that members of the administrator role are allowed to view and
manage. You create and configure administrator roles by selecting Administrators >
Admin Roles in the admin console.
 Users—A user role defines user-session parameters and personalization settings. You
can customize a user role by specifying access restrictions, enabling Host Enforcer
(Windows). either or agentless or Java agent access, and configuring session settings.
You create and configure user roles by selecting Users > User Roles in the admin console.
User Role Evaluation

The Policy Secure gateway’s role-mapping engine determines a user’s session role, or
combined permissions valid for a user session, as illustrated in Figure 27 on page 263. A
detailed description of each step follows after the diagram.

Chapter 9: User Roles
NOTE: If you assign a role to a RADIUS proxy realm, role restrictions cannot
be enforced. Host Checker policies, source IP restrictions, and any other limits
that have been assigned are bypassed. Use RADIUS proxy only if no
restrictions have been applied. Additionally, outer proxy cannot be used if a
role-mapping rule based on usernames is being used, because the Policy
Secure gateway cannot see the username, and a session cannot be created.
Figure 27: Security Checks Performed by the IC Series to Create a Session

Role

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

manual policy evaluation, the Policy Secure gateway repeats the role evaluation
process described in this section.

Permissive Merge Guidelines

A permissive merge is a merge of two or more roles that combines enabled features and
settings according to these guidelines:
 Any enabled access feature in one role takes precedence over the same feature set to
disabled in another role. For example, if a user maps to two roles, one of which disables
the Host Enforcer while the other role enables the Host Enforcer, the Policy Secure
gateway enables the Host Enforcer for that session.
 In the case of user interface options, the Policy Secure gateway applies the
settings that correspond to the user’s first role.
 In the case of maximum session lengths, the Policy Secure gateway applies the
greatest value from all of the roles to the user’s session.
 If more than one role enables the Roaming Session feature, then the Policy Secure
gateway merges the netmasks to formulate a greater netmask for the session.
Configuration of User Roles

To create a user role:
1. In the admin console, select Users > User Roles.
2. Click New Role and then enter a name and, optionally, a description. This name is
displayed in the list of Roles on the Roles page.
To create individual user accounts, you must add the users through the appropriate
authentication server (not through the role). For instructions on how to create users on
third-party servers, see the documentation that comes with that server product.
To display the role ID, place the mouse cursor over the role name on the Roles page. The
role ID is displayed at the end of the link text that is displayed on the status bar at the
bottom of the Web browser window. To show information on the ScreenOS Enforcer
about the role ID of a specific Policy Secure gateway authentication table entry, use this
CLI command:
get auth table infranet auth-id <x>

After you create a role, you can click the role name to begin configuring it using the
instructions in the following sections.
Documentation

on page 234

Defining Default Options for User Roles
You can change or keep the default options for a user role by selecting Users > User Roles
> New User Role. The default options include:
 Session Options—Sets timeouts and user permissions that apply to each session
established through the role.
 UI Options—Sets the appearance of agentless login pages.
 OAC Settings
 IC Access
 Preconfigured Installer
 Guest User Account Management—Provides limited permissions to allow users assigned

to this role to create guest accounts.
To define these default options for user roles:
1. Select Users > User Roles > Role Name, or create a new role.
2. Modify settings in the Session Options, UI Options, and Odyssey Settings tabs.
3. If you want to use OAC for this role, select Odyssey Settings for IC Access or if you want
to use the preconfigured installer option, select the check box for Odyssey Settings
for Preconfigured Installer.
If you want the role to access the Policy Secure gateway with Pulse as the client, do
not select the Odyssey Access Client check boxes.
4. Click Save Changes. These become the new defaults for this role.
5. To provision Pulse for this role, save the role, and then select Select Role > Users >
User Roles > Agent.
6. Select the Install Agent for this role check box.
7. Select the Install Pulse option button. (Host Enforcer is not supported for Pulse).
Documentation


Configuring General Role Options
Use the Overview tab to edit a role name and description and to toggle session and user
interface options on and off.
To manage general role settings and options:
1. In the admin console, select Users > User Roles > Role Name > General > Overview.
2. (Optional) Revise the name and description, and then click Save Changes.
3. Under Options, check the role-specific options to enable for the role. If you do not
select role-specific options, the Policy Secure gateway uses the default settings. Role-
specific options include:
 Session Options—To apply the role settings in the General > Session Options page
to the role. This option is selected by default.
 UI Options—To apply the role settings in the General > UI Options page to agentless
access roles. This option is selected by default.
 Odyssey Settings for IC Access—To specify OAC connection and authentication

options. By Default, this option is not selected. Do not select this option if you want
users to access protected resources with Pulse, the Java agent, or with agentless
access.
 Odyssey Settings for Preconfigured Installer—To upload a preconfigured installer

for OAC. By Default, this option is not selected. Do not select this option if you want
users to access protected resources with Pulse, the Java agent, or with agentless
access.
 Enable Guest User Account Management Rights—To provision users who access
this role administrative rights to create and modify guest user accounts.
Documentation

 Specifying Session Options on page 268
 Defining Default Options for User Roles on page 266
Configuring a Guest User Account Management Role
In some businesses, you might want to delegate responsibility for temporary or guest
users to a guest user access manager (GUAM) who can use the local authentication
server to provision accounts for guests.

To delegate guest user account management administration rights to a user:
1. In the admin console, select Users > User Roles > Role.
2. Select the Enable Guest User Account Management Rights check box for the role.
3. Save the configuration.
Users who are assigned to the role can provision guest accounts. To revoke a user’s guest
user account management rights, clear the check box on the role page, or use
role-mapping rules to deny access to the role for a specific user.

Documentation
 Using the Local Authentication Server on page 282

 Pulse Policy Secure Enterprise Guest Access Administration Guide
Using Role Restrictions
You can specify access management options for the role by selecting restrictions at the
top of the General tab for a role. The Policy Secure gateway uses these restrictions to
determine whether or not to map a user to the role. The Policy Secure gateway does
not map users to this role unless they meet the specified restrictions.
You can configure any number of access management options for the role. If a user does
not conform to all of the restrictions, then the Policy Secure gateway does not map the
user to the role.
If you configure a role that is assigned to a RADIUS proxy realm, role restrictions cannot
be enforced. The proxy target authenticates users without regard to any restrictions that
you configured.
Related Using Source IP Access Restrictions on page 241

Documentation

Specifying Session Options
Use the Session tab to specify the maximum session length, roaming capabilities, session
persistence, and to enable session extension without reauthentication. Check the Session
Options check box on the Overview tab to enable these settings for the role.
By default, this option is selected.

To specify general session options:
1. In the admin console, select Users > User Roles> RoleName > General > Session Options.
2. Under Session lifetime:
a. For Max. Session Length, specify the number of minutes an active non administrative
user session can remain open before ending. The minimum is 6 minutes. The
maximum is 725 minutes. During a user session, prior to the expiration of the
maximum session length, the Policy Secure gateway prompts the user to reenter
authentication credentials, thereby avoiding the unexpected termination of the
user session.
NOTE: With machine authentication, a role prompt fails because no

user is present to extend the session.
b. For Heartbeat Interval, set the frequency at which the endpoint sends out a
heartbeat to the Policy Secure gateway to keep the session alive. For agentless
access, the browser refreshes the page with every heartbeat. Users must not the
browser, because this will interrupt the heartbeat and end the session. OAC,
Pulse, and the Java agent provide the heartbeat. You should ensure that the
heartbeat interval
of the agent is greater than the Host Checker interval. If it is not, performance could
be affected. In general, set the heartbeat interval to 50% more than the Host
Checker interval.
c. For Heartbeat Timeout, specify the amount of time the Policy Secure gateway
should “wait” before terminating a session when the endpoint does not send a
heartbeat response.
d. For Auth Table Timeout, enter a timeout value for the auth table entry to be
provisioned as needed. This parameter allows you to specify how long a user with
no activity (for example, a user reading a static web page), can remain in the auth
table before the auth table entry is cleared by the Infranet Enforcer. If the user
accesses protected resources again after exceeding the timeout value specified,
The Policy Secure gateway must provision the auth table entry to the Infranet
Enforcer again.
e. For OAC and agentless users, you can select the Enable Session Extension check
box to allow users with a Layer 2 or Layer 3 connection to continue a session beyond
the maximum session length.
If this feature is enabled, users with OAC and agentless access can be
reauthenticated and extend their current session without interruption.
If you select this, the timer on OAC and the browser window for agentless access
display the time remaining in the session. If you do not select this option, the Extend
Session button on OAC is not active, and the browser window for agentless access
does not display the Extend Session option.
When the user session nears the end of maximum session length, a pop up a new
sign-in page for agentless and credential provider for OAC. When the user enters

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

Related Specifying Role Access Options on page 274

Documentation

Specifying UI Options for Agentless Access
You can specify customized settings for the Policy Secure gateway welcome page for
agentless users who are mapped to a role. The Policy Secure gateway welcome (or
home) is the Web interface presented to authenticated Policy Secure gateway users in
agentless access deployments. Select the UI Options option on the Overview tab to
enable custom settings for the role. Otherwise, the Policy Secure gateway uses the
default settings.
If a user maps to more than one role, then the Policy Secure gateway displays the user
interface settings that correspond to the first role to which the user is mapped.
NOTE: If an authenticated user attempts to close the agentless browser

window or to navigate to another site, a warning message is displayed. The
message advises the user that they will lose access to protected resources
if the user moves away from the current page. The user can select Cancel to
stay on the current page, or they can select OK to go to the new site. If the
user navigates to a different site, they can click the browser back button to
return to the Policy Secure gateway resource page, as long as the session
timeout is not exceeded.
To customize the Policy Secure gateway welcome page for role users:
1. Select Users > User Roles > Role Name > General > UI Options.
2. (Optional) Under Header, specify a custom logo and alternate background color for
the header area of the Policy Secure gateway welcome page:
 Click Browse and locate your custom image file. The new logo is displayed in the
Current appearance box only after you save your changes.
 Type the hexadecimal number for the background color, or click the Color Palette
icon and select a color. The Current appearance box updates immediately.
3. Under User Toolbar, select the Session Counter check box to display both a session
countdown timer and an Extend button that allows agentless users to extend their
session time to the maximum session length if the Enable Session Extension option
is selected.
4. (Optional) Under Post-Auth Sign-In Notification, select a post authentication message

that you configured earlier. If you select this option, the user receives an information
page (for example, an end-user license agreement [EULA]) that you have created.
If you defined a post sign-in notification and you select a message for a role, the user
is presented with the notification message after authentication. The user is prompted
to click Proceed or Decline. If the user clicks Proceed, the protected resource is available
to the user. If the user clicks Decline, they are immediately logged off and returned to
the authentication page.

5. (Optional) Under Personalized greeting, select the Show notification message check
box, and enter a message in the associated text box.
The message is displayed as a header on the Policy Secure gateway welcome page
after the user is authenticated. You can format text and add links using the following
HTML tags: , , , , and <a href>. This information does not appear
on the initial sign-in page that is displayed prior to authentication. You can also use
Policy Secure gateway system variables and attributes in this field.
The length of the personalized greeting cannot exceed 12K, (12288 characters).
If you use unsupported HTML tags in your custom message, the Policy Secure gateway
might display the user’s Policy Secure gateway home page incorrectly.
6. (Optional) Under Informative, select the Show instruction message check box and
specify any instructions to appear on the welcome page. For example, you could
advise users of company privacy notices or usage restrictions, or you can link to another
site for more information.
As with the notification message, you can use the following HTML tags: , ,
 , , and <a href>.
might display the user’s Policy Secure gateway home page incorrectly.
If you include a link to an external website, a warning message appears informing the
user of loss of access privileges if they leave the current page. To avoid this, add a tag
for opening links in a new browser window. For example:
<a href=”http://www.google.com” target=”_blank”>Google</a> displays the linked

text “Google,”, and the link opens in a new browser window.
The instruction message supports non-English languages.
7. (Optional) Under Other, specify whether or not to display the copyright notice and
label in the footer. This setting applies only to users whose license permits disabling
the copyright notice. For more information about this feature, call Pulse Secure, LLC
Support.
8. (Optional) Click Restore Factory Defaults to reset all user-interface options back to
factory defaults.
Click Save Changes. The changes take effect immediately, but current user browser
sessions might need to be refreshed to see the changes.
Related Specifying Session Options on page 268

Documentation
 Using Sign-In Notifications on page 482

Setting Up E-mail for Guest User Accounts
There is a guest e-mail box on the create and edit account pages into which the guest
user access manager can enter guest e-mail addresses. After guest user accounts are
created, the authentication credentials can be e-mailed to the guest, eliminating the
need to print the credentials. Though the e-mail field is always present, this feature is

only available if you enable e-mail from the admin console. You can send plain text or
html e-mails.
To enable the guest access e-mail accounts:
1. In the admin console, select Configuration > Guest Access.
2. Select the Enabled check box after Email account details.
3. Enter the hostname or IP address of your SMTP server.
4. (Optional) Enter the SMTP login credentials if the server requires credentials.
5. (Optional) Enter the SMTP password if the server requires credentials.
6. Enter the default e-mail address that should be used to send e-mails and receive
bounce-back messages.
7. Enter the e-mail subject to use in the header.
8. Select the html or text option button. The default is html.
To create optional custom HTML pages:
a. In the admin console, select Signing In > Sign-in Pages.
b. Click Upload Custom Pages.
c. Under Sample Template Files, select Sample.
d. At the prompt, select Open.
e. Open the file guest-user-email-page.thtml.
f. Edit the file to your specifications.
NOTE:
To send just the username and password in the e-mail, use the following
in the template:
 <% I18N_USERNAME_COLON %>
 <% login %>
 <% I18N_PASSWORD_COLON %>
 <% passwd %>
g. Save the file and then upload the zipped package with a meaningful name, for
example GUAM.
h. In the admin console, select Signing In > Sign-in Policies.
i. Open the sign in policy that will be used by the guest user access manager, or create
a new sign-in policy for the guest user access manager.

j. After Sign-in page, select the zipped file that you created.
k. Click Save Changes.
Related  Configuring Sign-In Pages on page 485

Documentation
Creating a MAC Address Authentication Role
To create a role for MAC address authentication, you only need to specify a name and a
session timeout parameter.
1. In the admin console, select Users > User Roles > New User Role.
2. Add a name and optionally a description, then click Save Changes.
Do not specify any role restrictions for MAC address authentication.
3. Select Users > User Roles > RoleName > General > Session Options.
4. For Max. Session Length, specify the number of minutes the active session can remain
open before ending. The minimum is 6 minutes, the default is 750 minutes.
You must also set up a reauthentication interval on the switch. A change in device
status does not propagate immediately to the switch. Instead, you have to wait for
the switch to fail the authentication. If you configure the device to be reauthenticated
frequently, changes can propagate quickly. If you configure the device to reauthenticate
less frequently, there will be less load on the Policy Secure gateway.
Set the switch reauthentication interval to be slightly shorter than the session length
that you set for the role. Consult the applicable manufacturer’s documentation for
information about configuring the switch.
Specifying Role Access Options
You can specify the following role options for user access through a role:
 Install OAC—For Windows endpoints, you can configure a role that automatically
downloads OAC.
 Enable agentless access—For Windows, Macintosh, Linux, and Solaris platforms, you
can allow users to access protected resources without installing and running OAC on
the endpoint. This type of access is referred to as agentless access.
 Install Java agent—For Linux platforms, you can install a lightweight Java agent to
provide status and session control.
 Install Pulse—For Windows platforms, you can configure a role that automatically
downloads the Pulse client.

 Enable Host Enforcer—For OAC, you can enable Host Enforcer for a role and specify
endpoint traffic in a Host Enforcer policy. You can also control endpoint access to
resources and protect endpoints from attacks from other computers.
 Session scripts—You can specify scripts to run on Windows endpoints for users
assigned to a role after OAC or Pulse connects or disconnects with the Policy Secure
gateway. For example, you can specify a script that maps network drives on an
endpoint to shares on protected resources as a session start script, and you can
specify a another script that disconnects the mapped network drives as session end
script.
To configure these access options for a role:
1. In the admin console, select Users > User Roles > Role Name > Agent.
2. To allow OAC to download automatically on Windows endpoints, select Install Agent

for this role, and then select the Install Odyssey option button.
3. To allow Pulse to download automatically on Windows endpoints, select Install Agent

for this role, and then select the Install Pulse option button.
4. To allow users to download and install the lightweight Java agent for Macintosh or
Linux platforms, select Install Java Agent for this role.
5. (Windows only) For OAC configurations, select Enable Host Enforcer to enable Host
Enforcer on the endpoint and to send Host Enforcer policies to OAC for this role. Host
Enforcer is not supported on Pulse.
NOTE:
 By default, after you enable the Host Enforcer option on a role, OAC
denies all traffic on the endpoint except for the following allowed types:
traffic to and from the Policy Secure gateway and Infranet Enforcer,
WINS, DNS, IPsec, DHCP, ESP, IKE, outgoing TCP traffic, and some
ICMP messages (for example, PING from the endpoint to other devices
is allowed). Therefore, it’s important that you configure Host Enforcer
policies to specify the additional types of traffic you want to allow on
each endpoint. For example, you must configure Host Enforcer policies
to allow any incoming TCP traffic.
 To avoid blocking all traffic on endpoints and preventing users from

accessing all network and Internet resources, we recommend that you
configure Host Enforcer policies to allow the specific types of traffic on
endpoints before you enable the Host Enforcer option on a role.
6. To use session scripts, under Session Scripts specify the location of the session start
and end scripts you want to run on Windows endpoints after OAC connects to or
disconnects from the Policy Secure gateway. You can specify a fully qualified path.
Scripts can be accessed locally or remotely by means of file share or another
permanently available local network resource. You can also use environment
variables, such as
%USERNAME% in the script path name. For example:
\\abc\users\%USERNAME%\myscript.bat

When OAC connects to the Policy Secure gateway, the Policy Secure gateway
copies the session start and end scripts to a temporary directory on the endpoint
(defined by the
%TEMP% environment variable). When OAC disconnects, the Policy Secure gateway
deletes the copied scripts from the temporary directory.
NOTE:
Windows supports only scripts with the .bat, cmd, or .exe extension. To
run a .vbs script, the user must have a batch file to call the .vbs script.
 Any files referenced in a script are not copied to the endpoint; only the
script itself is copied. Any references to files in scripts must take the
temporary directory on the endpoint location into account.
 After connecting to the Policy Secure gateway, OAC copies the

session end script from a network drive to a temporary directory on
the endpoint so that the end script can run if the network connection
fails.
 The session scripts run in the user’s context.
 If a user qualifies for multiple roles, all scripts for all roles are run. You
cannot configure the order in which to run the scripts when multiple
roles are assigned to a user.
7. To configure the role to permit users to use agentless access, select the Agentless
tab, then select Enable Agentless Access for this role. You can also select this to allow
access to endpoints in addition to using OAC on Windows machines. If you don’t select
the agentless option, the Policy Secure gateway allows access to protected
resources by means of OAC only.
Documentation

 Understanding OAC Configuration Settings for Windows Endpoints on page 23
Use Case: Using a Host Checker Policy with the Host Enforcer
This use case illustrates how to use a Host Checker policy to verify whether a particular
third-party firewall is running on the endpoint. If the third-party firewall is not running,
you can map the user to a role that enables Host Enforcer on the endpoint. If the
third-party firewall is running, you can map the user to a role that does not enable Host
Enforcer.

To use a Host Checker policy with Host Enforcer:
1. Select Authentication > Endpoint Security > Host Checker. Then create a Host Checker
policy that uses a Process Name rule to verify that a particular third-party firewall
process is running on the endpoint. Select the Deny option for this policy.
2. Create a role that enables the Host Enforcer for users who do not have the third-party
firewall running:
a. Select Users > User Roles to create a new role (such as “Role-1”).
b. Select Users > User Roles > RoleName > General > Restrictions > Host Checker, and
add the Host Checker policy under Selected Policies, and select Allow users whose
workstations meet the requirements specified by these Host Checker policies.
c. Select Users > User Roles > RoleName > Agent, and select Enable Host Enforcer.
3. Select Users > User Roles, and create a second role (such as “Role-2”) that does not
enable the Host Enforcer for users who do have the third-party firewall running. (For
this role, do not select the Host Checker policy and do not select Enable Host Enforcer.)
4. Select Users > User Realms > RealmName > Role Mapping > Role Mapping Rule, and
add both roles under Selected Policies.
If the third-party firewall process is not running, the Host Checker policy is successful.
The user is mapped to Role-1, which enables Host Enforcer. In this case, the endpoint is
using Host Enforcer.
If the third-party firewall process is running, the Host Checker policy fails because it is
set to Deny. The user is not qualified for Role-1 because of the Host Checker restriction.
Instead the user is mapped to Role-2, which does not enable Host Enforcer. In this case,
the endpoint is using the third-party firewall instead of Host Enforcer.
Related Using Host Enforcer Policies on page 251

Documentation  Specifying Role Access Options on page 274



CHAPTER 10
AAA Servers

 Using the Local Authentication Server on page 282
 Using Active Directory on page 290
 Understanding Multi-Domain User Authentication on page 304
 Understanding Active Directory and Windows NT Group Information Support on page 306
 Importing and Exporting an Active Directory Mode Configuration on page 307
 Using the Anonymous Server on page 308
 Using the Certificate Server on page 312
 Using an LDAP Server on page 316
 Using the LDAP Password Management Feature on page 323
 Using the MAC Address Authentication Server on page 328
 Example: Using Endpoint Discovery and Profiling for MAC Address
Authentication on page 334
 Using an NIS Server on page 367
 Using a RADIUS Server on page 372
 Using an ACE Server on page 390
 Using a SiteMinder Server on page 396
 Troubleshooting the SiteMinder Server Configuration on page 415
 Using an SQL Server on page 416
 Troubleshooting Oracle Error Codes on page 423
AAA Server Overview
This topic includes the following information:
 Understanding the Role of AAA Servers in the Pulse Policy Secure Access
Management Framework on page 280
 Authentication Protocols Used by AAA Servers on page 281
 AAA Server Configuration Task Summary on page 281

Understanding the Role of AAA Servers in the Pulse Policy Secure Access Management
Framework
AAA stands for authentication, authorization, and accounting. A AAA server is a database
that stores user credentials—username and password—and, in some cases, group
information or other user attributes. The authentication results and group or user attribute
information are used Pulse Policy Secure access management framework policy
decisions.
In the Pulse Policy Secure access management framework, the sign-in page, realm, and
AAA server configurations are associated. They determine user access and user role. A
user submits credentials through a sign-in page, which specifies a realm, which is
associated with a AAA server. If the access request meets the realm’s authentication
policy, the system forwards the user’s credentials to the associated authentication
server. The authentication server’s job is to verify the user’s identity. After verifying the
user, the authentication server sends approval. If the realm also uses the server as a
directory/attribute server, the AAA server sends the user’s group information or other
user attribute information. The access management framework then evaluates the
realm’s role-mapping rules to determine the user roles that apply to the session.
The Pulse Policy Secure access management framework supports the following types
of AAA servers:
 Local—You can create special purpose local databases to manually create user
accounts, manage guest user access, permit anonymous access, or manage access
based on digital certificates or MAC addresses.
 External (standards-based)—You can integrate standards-based LDAP and RADIUS

servers with the access management framework. In addition to using the backend
server for authentication, you can use LDAP group and RADIUS attribute information
in role-mapping rules.
 External (other)—You can integrate compatible versions of popular third-party AAA

servers with the access management framework. In addition to using the backend
server for authentication, you can use Active Directory group information and SiteMinder
attributes in role-mapping rules.
Table 25 on page 280 is a reference of the AAA servers supported in Pulse Policy Secure
and Pulse Connect Secure deployments.
Table 25: Supported AAA Servers

Pulse Policy Secure Pulse Connect Secure
* **
Local “Local Authentication Server” on page 282 , Local Authentication Server , “Anonymous
“Anonymous Server” on page 308, “Certificate Server” on page 308, “Certificate Server” on
***
Server” on page 312, “MAC Address page 312, SAML Server
Authentication Server” on page 328
**
No special features to manage guest users.
*
Special features to manage guest users.
***
Supports an authentication server
configuration when deployed as a SAML
service provider. Different Pulse Connect
Secure features support a local SAML server
when deployed as a SAML identity provider.

Chapter 10: AAA Servers
Table 25: Supported AAA Servers (continued)

Pulse Policy Secure Pulse Connect Secure
External (standards-based) “LDAP Server” on page 316, “RADIUS Server” “LDAP Server” on page 316, “RADIUS Server”
on page 372 on page 372
External (other) “Active Directory” on page 290, “NIS Server” Active Directory, “NIS Server” on page 367,
on page 367, “RSA ACE Server” on page 390, “RSA ACE Server” on page 390, “SiteMinder
“SiteMinder Server” on page 396, “SQL Server” on page 396
Server” on page 416
Authentication Protocols Used by AAA Servers

The Pulse Policy Secure supports multiple authentication protocols. The following
authentication servers require the protocols listed:
 Local authentication servers—If the passwords are stored as hashed values, the
protocols available are PAP and MS-CHAP v1 with or without EAP. If the passwords
are stored as cleartext, CHAP and MD5-Challenge are also available.
 Active directory—The protocols available for inner authentication are PAP, MSCHAP
and MS-CHAP v2, with or without EAP.
 LDAP—CHAP, EAP-MD5-Challenge, MS-CHAP v1, and MS-CHAP v2 protocols can be

used with an LDAP authentication server only if the administration password is in
cleartext. By default, challenge response protocols are disabled for LDAP servers. Use
these protocols only with noninteractive devices (for example, phones), as password
management is not possible if these protocols are used for authentication.
 Anonymous authentication server—The anonymous authentication server is not

supported with the open protocols.
AAA Server Configuration Task Summary

To integrate an authentication server:
1. Configure the authentication server. Select Authentication > Authentication > Auth.
Servers page and complete the authentication server configuration.
2. Create an authentication realm. Select Users > User Realms or Administrators > Admin
Realms and select the authentication server when you complete the authentication
realm configuration.
Related Understanding Authentication Realms on page 425

Documentation
 Understanding Authentication Realms


Using the Local Authentication Server
This topic describes the local authentication server. It includes the following information:
 Local Authentication Server Overview on page 282

 Configuring the Local Authentication Server on page 283
 Creating User Accounts on page 285
 Managing User Accounts on page 287
 Creating Administrator User Accounts on page 289
Local Authentication Server Overview

This section provides an overview of the feature and its limitations. It includes the following
sections:
 Understanding the Local Authentication Server on page 282

 Requirements and Limitations on page 282
Understanding the Local Authentication Server
The local authentication server is an authentication database that is built in to the Pulse
Policy Secure. Therefore, it is considered a “local” server in contrast to a third-party
enterprise AAA server that is connected over the network.
Typically, you create local user accounts for temporary users who do not have accounts
on your enterprise AAA servers. Temporary users include lab users or guests, but you
might find the local authentication server useful to create temporary accounts for users
who are normally verified by an enterprise AAA server that you plan to disable.
You also use the local authentication server to create accounts for administrator users,
such as system administrators and guest user access managers (GUAM).
NOTE: Although it is common practice to use the local authentication server

for administrator accounts, it does not preclude you from using any of the
supported third-party enterprise AAA servers in your administrator access
management framework.
Requirements and Limitations
The following authentication protocol sets can be used with the local authentication
server:
 By default, the system uses hashing to store passwords. When using the default, the
protocols available are PAP and MS-CHAP v1 with or without EAP.
 You can enable an option to store passwords as cleartext. If you enable this option,
CHAP and MD5-Challenge are also available.

Configuring the Local Authentication Server

You can create multiple local authentication server instances. When you define a new
local authentication server, you must give the server a unique name and configure options
for passwords and guest users.
To create a local authentication server:
1. Select Authentication > Auth. Servers.
2. Select Local Authentication and click New Server to display the configuration page.
The Local Authentication Server configuration page is shown in Figure 28 on page 283.
3. Complete the configuration as described in Table 26 on page 284.
Figure 28: Local Authentication Server Configuration Page

Table 26: Local Authentication Server Settings
Settings Guidelines
Name Specify a name that is useful to you.
Password Options
Minimum length Specify a number of characters. The valid range is 0-99. 6 is the default.
Maximum length Specify a number of characters. The valid range is 0-99. 8 is the default. The maximum
length cannot be less than the minimum length.
Minimum digits Specify the number of digits required in a password. Do not require more digits than the
value of the maximum length option.
Minimum letters Specify the number of letters required in a password. Do not require more letters than the
value of the maximum length option. If you enable the previous option, the combined total
of the two options cannot exceed that of the value specified in the maximum length option.
Uppercase and lowercase Select this option if you want all passwords to contain a mixture of uppercase and lowercase
required letters.
NOTE: Require passwords to contain at least two letters if you also require a mix of
uppercase and lowercase letters.
Different from username Select this option if the password cannot equal the username.
Different from previous password Select this option if a new password cannot equal the previous password.
Stored as cleartext Select this option if you are using open authentication protocol sets. CHAP and
EAP-MD5-Challenge work with local authentication servers only if you select this option.
NOTE: Be aware of the security implications of storing passwords as cleartext.
Password Management
Allow users to change passwords Select this option if you want users to be able to change their passwords.
NOTE: In addition to selecting local authentication password management options, you

must select the Enable Password Management option for the associated realm authentication
policy.
Force password change Select this option to specify the number of days after which a password expires. The default
is 64 days.
Prompt users to change Select this option to specify when to prompt the user to change passwords.
password
Guest Access Configurations

Table 26: Local Authentication Server Settings (continued)
Settings Guidelines
Enable Guest User Account Select this option to allow guest user account managers to create guest user accounts on
Managers the local authentication server.
In some businesses, you might want to delegate responsibility for temporary or guest users
to a guest user access manager (GUAM) who can use the local authentication server to
provision accounts for guests. The GUAM feature is available with the standard Pulse
Policy Secure license, but also with a special Enterprise Guest Access (EGA) license for
MAG Series devices. The EGA license gives the GUAM administrator the ability to create
and manage guest accounts on the local authentication server. See the Pulse Policy Secure
Enterprise Guest Access Administrator Guide.
Guest User Name Prefix Specify the prefix to be used in autogenerated guest usernames.
We recommend you retain the default guest_ so that you can rely on the naming convention
in your role mapping rules.
Guest User Info Fields (Optional) Add line items to represent fields that you want to appear on the configuration
page for creating guest user accounts. For example, you can create fields for Company
Name, Host Person, Meal Preference, and so on.
Instructions for Guest User (Optional) Add instructions to the GUAM that appear on the GUAM sign-in page. You can
Account Manager use the following HTML tags to format the text: , , , <noscript>, and <a href>.
Maximum Account Validity Specify the number of hours the account is valid. The default is 12 hours.
Period
Creating User Accounts

You use the Users page to create local authentication server user accounts. A user account
includes a username and password to be used for authentication, as well as other
information used for records and account management.
To create a local user account:
2. Select the local authentication server to which you want to add a user account.
3. Click the Users tab.
4. Click New to display the configuration page.
The New User configuration page is shown in Figure 29 on page 286.

Figure 29: User Account Configuration Page
Table 27: User Account Configuration Settings
Settings Guidelines
Username Do not include “~~” in a username.
NOTE: You cannot change a username after you create the account.
Full Name Specify the user’s full name.
Password Specify a password. Make sure that the password you enter conforms to the password
options specified on the local authentication server configuration page.
Confirm password Confirm the password.
Start Time (Optional) Specify a start and end time for the account.
The system process that deletes expired user accounts runs every 10 minutes. There
End Time
might be a delay of some minutes before the account is purged. Even if the system time
or date is moved ahead past the expiration time, the account could still be valid until the
purge process runs.
One-time user accounts are not deleted by the purge process; they are deleted
immediately after the user exits.
Company Name (Optional) Specify the company with which the user is associated.
Host or Sponsor (Optional) Specify the host or sponsor—for example, the person at your company who
requested that you create the account.

Table 27: User Account Configuration Settings (continued)
Settings Guidelines
One-time use Select this option to limit the user to one login. After one successful login, the user’s login
state is set to disabled, and the user receives an error message when attempting
subsequent sign-ins. However, you can manually reset this option to allow the same
user to log in again.
If you do not select this option, the user account is subject to the specified start and end
time for the account.
Enabled Select this check box if it is not already selected.
If the one-time use option has been implemented, this option is listed as Disabled after
the user has logged in successfully. If a permanent or one-time user is logged in and you
disable this option, the user is immediately logged out of the system and receives an
error message.
Require user to change password Select this option to force users to change their passwords at the next login.
NOTE: If you force the user to change passwords, you must also enable the local
authentication password management options.
Managing User Accounts

You use the Users page to list, modify, and delete local authentication server user
accounts.
To manage a user account:
2. Click the link for the authentication server you want to manage.
3. Click the Users tab to display the user accounts table.
The user accounts table is shown in Figure 30 on page 288.

The user accounts table includes entries for the accounts that have been created.
The Last Sign-in Statistic column shows the last successful sign-in date and time for
each user, the user’s IP address, and the agent or browser type and version.
4. Use the controls to search for users and manage user accounts:
 To search for a specific user, enter a username in the Show users named box and
click Update.
TIP: You can use an asterisk (*) as a wildcard, where * represents any
number of zero or more characters. For example, to search for all
usernames that contain the letters jo, enter *jo*. The search is
case-sensitive. To display the entire list of accounts again, type * or
delete the field’s contents and click Update.
 To limit the number of users displayed on the page, enter a number in the Show N
users box and click Update.
 To edit the user account configuration, click the link in the Username column to
display the Update Local User Account page.
The Update Local User Account page is shown in Figure 31 on page 289.
 To terminate the user session and delete the account, select the box next to the
user account record and click Delete.
Figure 30: User Accounts Table
Figure 31 on page 289 shows the user account configuration page. You can use this page
to modify the account settings, or to disable or quarantine the account.

Figure 31: Update User Account Configuration Page
Creating Administrator User Accounts

You use the Admin Users page to create accounts for local authentication server
administrators. An administrator user can create, modify, and delete user accounts.
The admin users you create on the Admin Users page can view and manage all users
that have been added to the local authentication server. In contrast, admin users you
create by assigning the GUAM role capability can view and manage only the user accounts
they created. For information on using the GUAM role capability, see the Pulse Policy
Secure Enterprise Guest Access Administrator Guide.
To create an administrator user account:
3. Click the Admin Users tab to display the configuration page.
The Admin Users configuration page is shown in Figure 32 on page 290.
4. Specify a username, select an authentication realm, and click Add to create the
administrator user.

Figure 32: Admin Users Configuration Page
Related AAA Server Overview on page 279

Documentation

 Enterprise Guest Access Feature Guide
Using Active Directory

® ®
This topic describes integration with the Microsoft Windows platform Active Directory™
service. It includes the following information:
 Microsoft Windows Platform Active Directory Service Overview on page 290

 Configuring Authentication and Authorization with Active Directory Service (Standard
Mode) on page 292
 Configuring Authentication and Authorization with Active Directory Service (Legacy
Mode) on page 297
 Displaying the User Accounts Table on page 302
Microsoft Windows Platform Active Directory Service Overview

This section describes support for using the Pulse Policy Secure with the Active
Directory AAA service. It includes the following sections:
 Understanding Active Directory on page 291

 Active Directory Feature Support on page 291
 Interoperability Requirements and Limitations on page 291
 Understanding the Active Directory Standard Configuration and Active Directory Legacy
Mode Configuration on page 292

Understanding Active Directory
Active Directory is a directory service used in Windows domain networks. It is included in

most Windows server operating systems. Enterprise servers that run Active Directory are
called domain controllers. An Active Directory domain controller authenticates and
authorizes users and computers in a Windows domain network.
When you use Active Directory as the authentication and authorization service for your
Pulse Policy Secure access management framework, users can sign in to the system
using the same username and password they use to access their Windows desktops.
You can also use Active Directory group information in role mapping rules.
Active Directory Feature Support
Pulse Policy Secure access management framework supports the following Active
Directory features:
 Honors trust relationships in Active Directory and Windows NT environments.
 Supports Domain Local Groups, Domain Global Groups, and Universal Groups defined
in the Active Directory forest.
 Supports use of Kerberos, NTLMv2, and NTMLv1 authentication protocols.
Interoperability Requirements and Limitations
The following limitations apply to interoperability with Active Directory:
 The Pulse Policy Secure access management framework uses Active Directory
security groups, not distribution groups. Security groups allow you to use one type of
group for not only assigning rights and permissions, but also as a distribution list for
e-mail.
 Each Active Directory configuration you create for the Pulse Policy Secure access
management framework should use a different and unique machine account name.
 If the current Active Directory domain controller is not reachable, the user or machine
authentication requests fail for a few seconds (less than 2 minutes) before attempting
to authenticate users with another domain controller in the Active Directory domain.
 We do not support interoperation with Active Directory implementations that use the
equal sign operator (=) in a group name, such as: "\=THIRD FLOOR GROUP". The
Pulse Policy Secure access management framework authentication process
involves search operations that use the equal sign operator (=) when parsing server
catalogs to retrieve group names, usernames and domain names, as well as user_SID
and domain_SID values. You might encounter unexpected behavior that can affect
normal processing of authentication services if a group name configured on your
Active Directory server includes an equal sign operator (=).
 Active Directory versions Windows 2008 R2 and later use a dynamic port range. The
default start port is 49152 and the default end port is 65535. Therefore, if there is a
firewall between the Pulse Secure service and the Active Directory Service, you must

increase the remote procedure call (RPC) port range on the firewall. See Microsoft
Knowledge Base article 929851.
 The Pulse Secure password management feature, which enables users to change their
Active Directory passwords through the Pulse Secure service Web server, is not supported
for users of trusted domains that do not trust the domain specified in the Pulse
Secure Active Directory configuration.
Understanding the Active Directory Standard Configuration and Active Directory

Legacy Mode Configuration
The Pulse Policy Secure supports interoperability with Active Directory using two
configurations:
 Active Directory standard configuration. Recommended. Supports interoperability with

any version of Active Directory, and is the required configuration mode to support
authentication using MS-CHAP v2 with Windows 2008 R2 Active Directory Service.
Machine authentication, for example, uses MS-CHAP v2.
 Active Directory Legacy Mode configuration. Supports interoperability with Active

Directory versions Microsoft 2003 or earlier. You might choose to use the Active Directory
Legacy Mode configuration as your primary configuration if you require role-mapping
rules to use “domain local groups” of trusted child domains. The Active Directory
standard configuration does not support “domain local groups” for authorization. You
can also use an LDAP server as the directory server if you want to use domain local
groups in role mapping.
We recommend configuring and using Active Directory standard configuration as your

primary configuration and Active Directory Legacy Mode as a fallback configuration. If
you are experiencing issues with the standard Active Directory configuration, you can use
the Switch to Active Directory Legacy Mode at the bottom of the Active Directory
authentication server configuration page to activate the Active Directory Legacy Mode
configuration. The fallback configuration saves you from having to reconfigure your
authentication server, server catalog, and role mapping rules.
Configuring Authentication and Authorization with Active Directory Service (Standard Mode)
To configure integration with Active Directory Service (standard mode):
2. Select Active Directory / Windows NT and click New Server to display the configuration
page.
Figure 33 on page 293 shows the configuration page.
3. Select Active Directory mode and complete the configuration as described in

Table 28 on page 294.

Figure 33: New Active Directory/Windows NT Server Configuration Page

Table 28: Active Directory Mode Settings
Settings Guidelines
Mode
Select one of the following modes:
 Active Directory—For recent versions of Windows Server.

 Active Directory Legacy Mode—For Windows Server 2003 and earlier.
This table describes Active Directory mode.
Base Configuration
Name Specify a name to identify the server within the system.
Domain Specify the NetBIOS domain name for the Active Directory domain.
The system uses DNS to discover domain controllers in the Active Directory forest. It sends
authentication requests to the domain controller at the closest site. Ensure that your DNS servers
are configured to resolve the Active Directory domain controller fully qualified domain name (FQDN)
and service (SRV) records.
Do not create an Active Directory and an Active Directory Legacy Mode configuration with the same
domain and computer name. They must have different computer names.
Kerberos Realm Specify the FQDN of the Active Directory domain. For example, if “juniper” is the domain name
(NetBIOS name), then juniper.net is the Kerberos realm name.
Domain Join Configuration

Username Specify a username that has permission to join computers to the Active Directory domain.
Use the “Delegate Control” workflow in Active Directory to assign the following user account
permissions to the username or to a group to which the user belongs:
 Write
 Write All Properties
 Change Password
 Reset Password
 Validate Write to DNS hostname
 Read and write DNS host attributes
 Delete Computer Objects
 Create Computer Objects
Password Specify the password for the special user.
Save Credentials If this setting is not enabled, the credentials entered will be destroyed after successfully joining the
domain.
This option is useful when managing clusters. For example, you might want to save the credentials
for a cluster node you have yet to add. If you do not enable this option, you must manually enter
the credentials when you add the new cluster node.

Table 28: Active Directory Mode Settings (continued)
Settings Guidelines
Container Name Specify the container path in Active Directory in which to create the machine account. Changing
this field triggers a domain rejoin action.
The default is Computers, which is a standard container created during installation of the AD server.
The AD Computers container is the default location for new computer accounts created in the
domain.
If desired, you may specify a different container or OU. To specify nested containers, use a forward
slash ( / ) as the container separator. For example: outer OU/inner OU.
NOTE: Do not use backslashes in the path. Using backslashes causes an Invalid DN Syntax error.
Computer Name Specify the machine account name. The default computer name is derived from the license hardware
in the following format: 0161MT2L00K2C0. We recommend the Computer Name string contain no
more than 14 characters to avoid potential issues with the AD/NT server. Do not include the '$'
character.
Update Join Status / The following colors are used to indicate status:
Reset Join
 Gray. The Domain Join action has not been attempted. This is the default status that appears
when you are using the page to create a new Active Directory configuration.
 Yellow. Attempting to join the Active Directory domain. This is the default status that appears
after saving configuration settings or when any domain join settings are changed in an existing
configuration.
 Green. The attempt was successful. This status indicates that this server can now be used to
authenticate users.
 Red. The attempt to join the Active Directory domain was not successful.
Click Update Join to get the latest join status of nodes. If the status appears persistently red, click
Reset Join to reinitiate the domain join process. The Reset Join action requires Active Directory
administrator credentials.
NOTE: Transient network issues might also cause the join status indicator to appear red. Before
reinitiating the join process, ensure that it is not caused by network issues. Make sure your DNS
servers can resolve queries to the Active Directory domain controller and that the Active Directory
credentials are valid and have the appropriate permissions.
Additional Options

Settings Guidelines
Authentication Protocol The system attempts authentication using the protocols you have enabled in the order shown on
the configuration page. For example, if you have selected the check boxes for Kerberos and NTLMv2,
the system sends the credentials to Kerberos. If Kerberos succeeds, the system does not send the
credentials to NTLMv2. If Kerberos is not supported or fails, the system uses NTLMv2 as the next
protocol in order.
Kerberos. Select to enable the Kerberos authentication protocol. Kerberos is the most secure
method and is required for Kerberos single sign-on authentication. Kerberos must be enabled if
you plan to use Pulse Secure single sign-on or browser-based agentless single sign-on
(SPNEGO).
Enable NTLM protocol. Enable NTLM if you plan to use any of the following features:
 Machine authentication using OAC, Pulse Secure client, or Windows native 802.1x supplicants.
 MS-CHAP-based authentication protocols for any 802.1x supplicants.
 User password management.
 Role mapping rules based on group membership.
If you enable NTLM, select one of the following versions:
 NTLMv2. This protocol is moderately secure. It is required for machine authentication and
MS-CHAP v2 based 802.1x authentication protocols.
 NTLMv1. This protocol is comparatively less secure. It might be required for compatibility with
existing legacy servers, MS-CHAP based servers, and MS-CHAP based 802.1x authentication
protocols.
Trusts Contact trusted domains. Select this option to contact domain controllers of trusted domains
directly without proxying authentication requests and group membership checks through the
domain controller in which the Pulse Policy Secure is a member.
If this option is not selected:
 Network contact with trusted domains is not permitted, but pass-through authentication using
the primary domain is still permitted.
 Trusted domain user's group lookup for Kerberos SSO and SPNEGO authentication does not
work even though user authentication succeeds.
 Trusted domain user's password-based authentication does not work.
 Only groups from the domain in which this system is a member are available for use in role
mapping when a group search is performed in the server catalog window.
NOTE: If you want to restrict trusted domain users and computers (machine authentication) from
logging in when this option is not selected, you can define a custom expression based on the
ntdomain variable and use it in role mapping rules. For example, if the Pulse Policy Secure
belongs to the domain named Corporate, you can define a custom expression as
ntdomain=Corporate and use the custom expression in the role mapping rule of the realm.
SPNEGO Single Sign On Enable SPNEGO. Select this option to support SPNEGO SSO.
Keytab Upload. Use the controls to upload the SPNEGO keytab. The keytab must be generated on
the Active Directory Service for the SPN. It must match the FQDN used to access this device.

Settings Guidelines
Machine account Enable periodic password change of machine account. Changes the domain machine account
password change password for this configuration.
Change machine password frequency. Specify a frequency in days. For example, every 30 days.
Save Changes?
After you have saved your configuration, the “Mode” section is removed from the top of the configuration page and the “Active
Directory Selection” section is included at the bottom of the page. Click the Switch to Active Directory Legacy Mode button to
display the Active Directory Legacy Mode configuration page. The settings that are applicable to both configurations are
populated in the Active Directory Legacy Mode configuration page. You must complete the remaining settings.
Configuring Authentication and Authorization with Active Directory Service (Legacy Mode)
To create an Active Directory Legacy Mode configuration:
2. Select Active Directory / Windows NT and click New Server to display the configuration
page.
3. Select Active Directory Legacy Mode to display the Active Directory Legacy Mode
configuration page.

Figure 34: New Active Directory Legacy Mode Configuration Page
Table 29 on page 299 describes the Active Directory Legacy Mode configuration.

Table 29: Active Directory Legacy Mode Settings
Settings Guidelines
Mode
Select one of the following modes:
 Active Directory—For recent versions of Windows Server.

 Active Directory Legacy Mode—For Windows Server 2003 and earlier.
This table describes Active Directory Legacy Mode.
Server
Primary Domain Specify the name or IP address for the primary domain controller or Active Directory server.
Controller
Backup Domain (Optional) Specify the IP address of your backup domain controller or Active Directory server.
Controller
Domain Specify the NetBios domain name for the organization. The NetBios name can be found within
Active Directory, under Users and Computers. Right-click the domain name, and select Properties.
The system uses DNS to discover domain controllers in the Active Directory forest. It sends
authentication requests to the domain controller at the closest site. Ensure that your DNS servers
are configured to resolve Active Directory domain controller FQDNs and SRV records.
Do not create an Active Directory and an Active Directory Legacy Mode configuration with the same
domain and computer name. They must have different computer names.
You may, however, create two Active Directory Legacy Mode configurations with the same domain
and the same computer name.
Allow domain to be Select this option to allow users to sign in by entering a domain name in the Username box in the
specified as part of format: domain\username.
username
Allow trusted domains Select this option to get group information from all trusted domains within a forest.
Domain Controller is a Select this option if the domain controller is a Windows 2008 server. The Windows 2008 server
Windows 2008 server has several enhancements to the Active Directory Server, which is now called Active Directory
Domain Services.
Administrator
Admin Username Specify an administrator username for the AD or NT server. Make sure the administrator you specify
is a domain administrator in the same domain as the AD or NT server. Do not include a domain
name with the server administrator username in the Admin Username box.
Admin Password Specify the corresponding password.
Additional Options

Table 29: Active Directory Legacy Mode Settings (continued)
Settings Guidelines
Authentication Protocol The system attempts authentication using the protocols you have enabled in the order shown on
the configuration page. For example, if you have selected the check boxes for Kerberos and NTLMv2,
the system sends the credentials to Kerberos. If Kerberos succeeds, the system does not send the
credentials to NTLMv2. If Kerberos is not supported or fails, the system uses NTLMv2 as the next
protocol in order.
Kerberos. This protocol is the most secure method and is required for Kerberos single sign-on
authentication. Kerberos must be enabled if you plan to use Pulse Secure single sign-on or
browser-based agentless single sign-on (SPNEGO).
NTLMv2. This protocol is moderately secure. It is required for machine authentication and MS-CHAP
v2 based 802.1x authentication protocols.
NTLMv1. This protocol is comparatively less secure. It might be required for compatibility with
existing legacy servers, MS-CHAP based servers, and MS-CHAP based 802.1x authentication
protocols.
Kerberos Realm Name Select one of the following options to specify the Kerberos realm name:
 Use LDAP to get Kerberos realm name. Select this option to retrieve the Kerberos realm name
from the Active Directory server using the specified administrator credentials.
 Specify Kerberos realm name. Select this option to specify the realm name in the corresponding
text box. Specify the FQDN of the Active Directory domain. For example, if “juniper” is the domain
name (NetBIOS name), then juniper.net is the Kerberos realm name.
SPNEGO Single Sign On Enable SPNEGO. Select this option to support SPNEGO SSO. This option is available only on Pulse
Policy Secure.
Keytab Upload. Use the controls to upload the SPENEGO keytab. The keytab must be generated
on the Active Directory Service for the SPN. It must match the FQDN used to access this device.

Settings Guidelines
Group Search With LDAP Enable Group Search With LDAP. Select this option to use LDAP to retrieve group membership
information. If you enable group search with LDAP, specify one of the following LDAP protocols:
 LDAP. Select this option to use unsecure LDAP.

 LDAPS. Select this option to use secure LDAP (LDAP communication using an SSL tunnel). You
enable LDAPS by installing a properly formatted certificate. If you select LDAPS, optionally select
Validate Server Certificate to validate this certificate.
NOTE: Active directory group lookup using LDAP fails if a user from a different domain tree attempts
to log in. Native Active Directory group lookup works correctly.
Active directory group lookup using LDAP fails if the same username is present in both the parent
and child domain and if only the child domain user is part of a group. Native Active Directory group
lookup works correctly.
Admin DN. Specify the administrator Distinguished Name. You can click the Test Configuration
button at the bottom of the page to automatically populate this field.
Base Search DN. Specify the point to start searching for the user. For example, dc=juniper,dc=com.
You can click the Test Configuration button at the bottom of the page to automatically populate
this field.
Nested Group Level. Specify how many levels within a group to search for the user. Higher numbers
create longer queries or search time.
Advanced Options
User may belong to Specify if the trusted domains' Domain Local Groups must be searched to determine users' group
Domain Local Groups memberships. This might impact performance.
across trust boundaries
Container Name Specify the Container path in Active Directory in which to create the machine account. Changing
this field triggers a domain rejoin action.
The default is Computers, which is a standard container created during installation of the AD server.
The AD Computers container is the default location for new computer accounts created in the
domain.
If desired, you may specify a different container or OU. To specify nested containers, use a forward
slash ( / ) as the container separator. For example: outer OU/inner OU.
NOTE: Do not use backslashes in the path. Using backslashes causes an Invalid DN Syntax error.
Computer Name The computer name is pre-filled with an entry in the format of vcNNNNHHHHHHHH, where, in an
IVS system, the NNNN is the IVS ID (assuming you have an IVS license) and the HHHHHHHH is a
hex representation of the IP address of the Junos Pulse device. You can change this to a unique
name, either the one provided by default or one of your own choosing to more easily identify your
systems in the Active Directory. In a non-IVS system, the first six characters of the name will be
‘vc0000’ because there is no IVS ID to display. For example, the name could be something like
vc0000a1018dF2’ for a non-IVS system. The following entry conforms with the required format:
IVE_123.
In a clustered environment with the same AD authentication server, this name is also unique among
all cluster nodes, and this configuration section displays all of the identifiers for all attached cluster
nodes.

Settings Guidelines
Save Changes?
After you have saved your configuration, the “Mode” section is removed from the top of the configuration page and the “Active
Directory Selection” section is included at the bottom of the page. Click the Switch to Active Directory mode button to display
the Active Directory standard mode configuration page. The settings that are applicable to both configurations are populated
in the Active Directory standard mode configuration page. You must complete the remaining settings.
Displaying the User Accounts Table

To display user accounts:
Figure 35 on page 303 shows the user accounts table.
 To search for a specific user, enter a username in the Show users named field and
click Update.
users field and click Update.
 To terminate their user session and delete the account, select the check box next
to the user account record and click Delete.


Documentation

 Understanding Multi-Domain User Authentication on page 304
Using Kerberos SSO
This topic includes the following information:
 Kerberos SSO Support Overview on page 303

 Requirements and Limitations on page 303
 Enabling Kerberos SSO on page 304
Kerberos SSO Support Overview

Kerberos single sign-on (SSO) is a method of access control that allows a user to log in
once to the client desktop without being prompted again for credentials.
The Kerberos SSO feature uses Kerberos authentication to automatically sign in users
with the same credentials they used to access their Windows desktops. After you configure
Kerberos SSO, the sign-in dialog box does not appear to users.
Requirements and Limitations

The following requirements and limitations apply to the Kerberos SSO implementation:
 The SSO feature requires a Windows NT Primary Domain Controller (PDC) or Active
Directory for user authentication.
 The Kerberos SSO feature is not supported on Windows NT Server 4.0 or earlier.

 The Kerberos SSO feature does not provide credentials for OAC machine credentials
or GINA authentication.
 The clocks on the Pulse Policy Secure and the Windows Active Directory
authentication server must be synchronized to within 2 minutes of each other.
 The Active Directory controller must be deployed in front of the Pulse Policy Secure.
 The Windows endpoint computers must be joined to the same domain that the Pulse
Policy Secure uses for authentication. Alternatively, make sure the Windows endpoint
computers are joined to a domain that has a trust relationship with the domain that
the Pulse Policy Secure uses for authentication.
 Users must sign into their endpoint computers in the domain of the Windows Active
Directory authentication server or in a trusted domain.
 The realm Enable SSO option is visible only if the Windows Active Directory
authentication server is used for authenticating users of the selected realm.
Enabling Kerberos SSO

To enable Kerberos SSO:
1. Configure the authentication server:
a. Select Authentication > Auth. Servers.
b. Select New Active Directory / Windows NT and click New.
c. Complete the configuration. Enable the Kerberos authentication protocol option.
2. Configure the realm:
a. Select Administrators > Admin Realms or Users > User Realms . Specify the realm
that must use the Active Directory server to authenticate and authorize
administrators and users.
b. Select Administrators > Admin Realms > Select Realm > Authentication Policy >
SSO to ensure that the Enable SSO option is enabled (the default).
Related Using Active Directory on page 290

Documentation

Understanding Multi-Domain User Authentication
This topic provides an overview of multidomain user authentication with Active Directory
and Windows NT. It includes the following information:
 Multi-Domain User Authentication Overview on page 305

 Windows NT User Normalization on page 305
 Kerberos Support on page 305
 Windows NT4 Support on page 306

Multi-Domain User Authentication Overview

The Pulse Policy Secure access management framework allows for multidomain Active
Directory and Windows NT authentication. The system authenticates users in the
domain that you configure, users in child domains, and users in all domains trusted by
the configured domain.
Users in the default domain can sign into the system using just their username, or the
default domain and the username in the format default-domain\username.
When you enable trusted domain authentication, users in trusted or child domains can
sign in using the name of the trusted or child domain and the username in the format
trusted-domain\username. Note that enabling trusted domain authentication adds to
the server response time.
Windows NT User Normalization

To support multidomain authentication, the Pulse Policy Secure access management
framework uses “normalized” Windows NT credentials when it contacts an Active
Directory or Windows NT4 domain controller for authentication. Normalized Windows
NT credentials include both the domain name and the username: domain\username.
Regardless of how the user signs in (either using just a username or using the
domain\username format), the access management framework always processes the
username in domain\username format.
When a user signs in using only their username, the access management framework
normalizes their Windows NT credentials as default-domain\username. Authentication
succeeds only if the user is a member of the default domain.
When a user signs in using the domain\username format, the access management
framework attempts to authenticate the user as a member of the domain the user
specifies. Authentication succeeds only if the user-specified domain is a trusted or child
domain of the default domain. If the user specifies an invalid or untrusted domain,
authentication fails.
Two variables, <NTUser> and <NTDomain>, allow you to individually refer to Windows
NT domain and username values. The system populates these two variables with the
Windows NT domain and username information.
In role mapping rules, when you specify USER = someusername, the system treats this
rule semantically as NTUser = someusername AND NTDomain = defaultdomain.
Kerberos Support
We recommend you configure the Pulse Policy Secure access management
framework to use the Kerberos authentication protocol with Windows domain
controllers. When a user logs in to the system, the system performs Kerberos
authentication and attempts to fetch the Kerberos realm name for the domain
controller, as well as all child and trusted realms, using LDAP calls.

You can use Kerberos differently. You can specify the Kerberos realm name when
configuring an Active Directory authentication server. We do not recommend this method
for two reasons:
 You cannot specify more than one realm name. The system cannot then authenticate
against child or trusted realms of the realm you specify.
 If you misspell the realm name, the system cannot authenticate users against the
proper realm.
Windows NT4 Support

The Pulse Policy Secure access management framework does not support Kerberos-
based authentication in Windows NT4 domain controllers. The system uses NTLM
with a backend Windows NT4 domain controller.

Documentation
 Using Active Directory

Understanding Active Directory and Windows NT Group Information Support
This topic describes support for polling group information from Active Directory and
Windows NT servers. It includes the following information:
 Active Directory Group Information Overview on page 306

 Windows NT4 Group Information Overview on page 307
Active Directory Group Information Overview

The Pulse Policy Secure access management framework supports user group lookup in
Domain Local, Domain Global, and Universal groups in the default domain, child
domains, and all trusted domains. The system obtains group membership using one of
three methods that have different capabilities:
 Group information in User’s Security Context—Returns information about the user’s

Domain Global groups.
 Group information obtained using LDAP search calls—Returns information about the
user’s Domain Global groups and about the user’s Universal groups if the access
management framework queries the Global Catalog Server.
 Group information using native RPC calls—Returns information about the user’s Domain
Local Group.
With respect to role-mapping rules, the system attempts group lookup in the following
order:
 Checks for all Domain Global groups using the user’s security context.
 Performs an LDAP query to determine the user’s group membership.

 Performs an RPC lookup to determine the user’s Domain Local group membership.
Windows NT4 Group Information Overview

The Pulse Policy Secure access management framework supports group lookup in the
Domain Local and Domain Global groups created in the default domain, as well as all
child and other trusted domains. The system obtains group membership using:
 Domain Global group information from the user’s security context.
 Domain Local information using RPC calls.
In the Windows NT4 environment, the system does not use LDAP-based search calls.

Documentation
 Using Active Directory

Importing and Exporting an Active Directory Mode Configuration
You can use the Maintenance > Import/Export > Import/Export users page to copy an
Active Directory mode configuration from one system to another. If Active Directory
credentials for joining a domain are not stored in the exported configuration, you must
update the configuration to specify them.
NOTE: Push configuration is not supported for Active Directory mode

configurations.
XML Import/Export for the Active Directory mode configuration has limitations. An XML
exported Active Directory configuration (standalone/cluster) can be imported to the
same system from which it is exported. However, an XML exported Active Directory
configuration from a standalone configuration cannot be imported into a cluster
configuration. Similarly, an XML exported Active Directory configuration from a cluster
cannot be imported into a standalone configuration.
It is not recommend that you import a configuration into a different system than the one
from which the configuration was exported. Although the import operation will be
successful, the importing system will join the AD domain with the same computer name
as the exporting system. When this occurs, the Active Directory disconnects the earlier
join from the exporting system.
To work around this, modify the value of the computer-name parameter in the XML file
to be unique and then import it to another system. In cluster configurations, in addition
to modifying the computer-name parameter, also modify the node parameter for each
cluster member to match with the importing cluster node names.
Here are the parameters you must change before importing the XML configuration file
of Active Directory:
<nodenames>

<node>clusternode1</node>
<computer-name>computer1</computer-name>
</nodenames>
<nodenames>
<node>clusternode2</node>
<computer-name>computer2</computer-name>
</nodenames>
NOTE: You must specify the cleartext password within <password-cleartext>

</password-cleartext> tags, in place of <user-password-encrypted>
</user-password-encrypted> tags, before you perform an XML Import of an
Active Directory mode configuration.

Documentation

Using the Anonymous Server
This topic describes integration with the anonymous server. It includes the following
information:
 Anonymous Server Overview on page 308

 Configuring Authentication with the Anonymous Server on page 309
 Monitoring Anonymous User Sessions on page 311
Anonymous Server Overview

This section describes support for using the Pulse Policy Secure and Pulse Connect
Secure with the anonymous server. It includes the following sections:
 Understanding the Anonymous Server on page 308

 Anonymous Server Feature Support on page 308
Understanding the Anonymous Server
The anonymous server is a local authentication server that allows any user to access the
system without providing a username and password.
Instead, when a user enters the URL of a sign-in page that is configured to authenticate
against an anonymous server, the Pulse Policy Secure access management framework
bypasses the standard sign-in page and immediately displays the welcome page to the
user.
Anonymous Server Feature Support
Pulse Policy Secure access management framework supports the following

anonymous server features:
 Enables guest access without username or password
 Supports Host Checker scans before allowing a guest device to connect to the network

 Supports firewall enforcement roles and policies to limit the resources available to the
guest user
The following limitations apply to the anonymous server configuration and logging:
 You can add only one anonymous server configuration.
 You cannot create an administrator realm that uses the anonymous server. Anonymous
administration is not allowed.
 During configuration, youmust choose the anonymous server asboth the authentication
server and the directory or attribute server in the Users > User Realms > General tab.
 When creating role mapping rules through the Users > User Realms > Role Mapping
tab, the Pulse Policy Secure access management framework does not allow you to
create mapping rules that apply to specific users (such as “Joe”), because the
anonymous server does not collect username information. You can only create role
mapping rules based on a default username (*), certificate attributes, or custom
expressions.
 For security reasons, you might want to limit the number of users who sign in through
an anonymous server at any given time. To do this, use the option on the Users > User
Realms > [Realm] > Authentication Policy > Limits tab (where [Realm] is the realm
that is configured to use the anonymous server to authenticate users).
Configuring Authentication with the Anonymous Server

To configure authentication with the anonymous server:
2. Select Anonymous Server and click New Server to display the configuration page.
Figure 36 on page 310 shows the configuration page for Pulse Policy Secure.
Figure 37 on page 310 shows the configuration page for Pulse Connect Secure.

Figure 36: Anonymous Server Configuration Page – Pulse Policy Secure
Figure 37: Anonymous Server Configuration Page – Pulse Connect Secure
Table 30: Anonymous Server Settings
Settings Guidelines
User Record This feature is available only on Pulse Connect Secure.

Synchronization
Enable User Record Select this option to retain the bookmarks and individual preferences regardless of which system
Synchronization you log in to.

Table 30: Anonymous Server Settings (continued)
Settings Guidelines
Logical Auth Server Name Specify a logical authentication server name.
Monitoring Anonymous User Sessions

The purpose of the anonymous server is to enable unauthenticated access. Therefore,
the system does not maintain session tables, and the Anonymous Server configuration
page does not have a corresponding Users tab. The system does maintain user access
logs for anonymous access. The username is recorded in the user access log as
“AnonUser1234”. If the user is logging in using the agentless access method, the user
access log records the host’s IP address. You can view the User Access Log file by
navigating to System > Log/Monitoring.
Figure 38 on page 311 shows the User Access Log Page.
Figure 38: User Access Log

Documentation

 Creating an Authentication Realm
 KB: How to reduce the impact of an unreachable authentication server
 KB: Configuring Realm Selection

Using the Certificate Server
This topic describes integration with the certificate server. It includes the following
information:
 Certificate Server Overview on page 312

 Configuring Authentication with the Certificate Server on page 313
Certificate Server Overview

Secure with the certificate server. It includes the following sections:
 Understanding the Certificate Server on page 312

 Feature Support on page 312
Understanding the Certificate Server
The certificate server is a local server that allows user authentication based on the digital
certificate presented by the user without any other user credentials.
When you use a certificate server, the user experience is similar to anonymous
authentication. If the certificate is secured through a hardware or a software token or
through a password, the certificate server authentication is very useful. The certificate
contains the full distinguished name (DN) and the system extracts the values from the
DN and uses it for role mapping rules, authentication policies, and role restrictions.
Feature Support
The Pulse Policy Secure access management framework supports the following
certificate server features:
 Certificate directory services to retrieve user attributes in role mapping rules,

authentication policies, and role restrictions.
 Load CA-created certificates on the system.
 Load multiple certificates from different CAs for use with different authentication
realms.
If you choose a certificate attribute with more than one value, the system uses the first
matched value. For example, if you enter <certDN.OU> and the user has two values for
the attribute (ou=management, ou=sales), the system uses the “management” value.
To use all values, add the SEP attribute to the variable. For example, if you enter
<certDN.OUT SEP=”:”> the system uses “management:sales”.

Configuring Authentication with the Certificate Server

To configure authentication with the certificate server:
2. Select Certificate Server and click New Server to display the configuration page.
Figure 39: Certificate Server Configuration Page – Pulse Policy Secure

Figure 40: Certificate Server Configuration Page – Pulse Connect Secure
Table 31: Certificate Server Settings
Settings Guidelines
User Name Template Specify a username template. Specify how the system should construct a username. You may use
any combination of certificate variables contained in angle brackets and plain text.
NOTE: This value populates the <USER> and <USERNAME> session variables for use throughout
the rest of the system configuration.

Table 31: Certificate Server Settings (continued)
Settings Guidelines
User Record Pulse Connect Secure only.

Synchronization

Figure 41 on page 316 shows the Users page for Pulse Connect Secure. The Users page
for Pulse Policy Secure is similar.
click Update.
 To terminate the user session and delete the account, select the check box next to
the user account record and click Delete.


Documentation
 KB: Pulse Connect Secure Troubleshooting: Certificate Authentication with Windows 7

Clients
 How to: Secure Access Service: Using Certificates
Using an LDAP Server
This topic describes integration with the LDAP server. It includes the following information:
 LDAP Server Overview on page 316

 Configuring Authentication with an LDAP Server on page 317
LDAP Server Overview

Secure with the LDAP server. It includes the following sections:
 Understanding LDAP Server on page 316

 LDAP Feature Support on page 317
Understanding LDAP Server
Lightweight Directory Access Protocol (LDAP) facilitates the access of online directory
services. The Internet Engineering Task Force (IETF) designed and specified LDAP as a
better way to make use of X.500 directories, having found the original Directory Access
Protocol (DAP) too complex for average Internet clients to use. LDAP is a relatively simple
protocol for updating and searching directories running over TCP/IP.

LDAP directory consists of a collection of attributes with a name, known as a distinguished

name (DN). Each of the entry’s attributes, known as a relative distinguished name (RDN),
has a type and one or more values. The types are typically mnemonic strings, such as CN
for common name. The valid values for each field depend on the types.
The full DN is constructed by stringing together RDNs from most specific to least specific,
separated by commas, as shown in the following example:
cn=Bob_Employee, ou= account_mgr, o=sales, dc=Acme,dc=com.
LDAP Feature Support
Pulse Policy Secure access management framework supports the following LDAP
features:
 LDAP directory services to retrieve user attributes and group membership in role
mapping rules
 Encrypted connections to the LDAP server using LDAP over SSL (LDAPS) or Start
Transport Layer Security (TLS)
 Password management feature enabling users who access an LDAP server to manage
their passwords using the policies defined on the LDAP server
 Fine-grained password policy (FGP) for Active Directory 2008
The following limitations apply to interoperability with LDAP:
 By default, challenge response protocols are disabled for LDAP servers. Use these
protocols only with noninteractive devices (for example, phones), as password
management is not possible if these protocols are used for authentication.
 To use the CHAP, EAP-MD5-Challenge, MS-CHAP-V1, and MS-CHAP-V2 protocols,

the LDAP server must store the administrator password in cleartext so that the
administrator username and password you configure in your Pulse Policy Secure or
Pulse Connect Secure LDAP configuration can be used to perform password
management operations.
 Backup LDAP servers must be the same version as the primary LDAP server. Also, we
recommend that you specify the IP address of a backup LDAP server instead of its
hostname, which might accelerate failover processing by eliminating the need to resolve
the hostname to an IP address.
Configuring Authentication with an LDAP Server

To configure authentication with an LDAP server:
2. Select LDAP Server and click New Server to display the configuration page.

Figure 42: LDAP Server Configuration Page – Pulse Policy Secure

Figure 43: LDAP Server Configuration Page – Pulse Connect Secure

Table 32: LDAP Server Settings
Settings Guidelines
LDAP Server Specify the LDAP server name or the IP address.
LDAP Port Specify the LDAP port for the LDAP server.
Default port number: 389 (unencrypted connection)
Default port number: 636 (SSL connection)
Backup LDAP Server1 (Optional) Specify the parameters for backup LDAP server1.
The specified backup LDAP server is used for failover processing. The authentication request is
first routed to the primary LDAP server, and then to the specified backup servers if the primary
server is unreachable.
Backup LDAP Port1 Specify the parameters for backup LDAP port1.
Backup LDAP Server2 (Optional) Specify the parameters for backup LDAP server2.
Backup LDAP Port2 Specify the parameters for backup LDAP port2.
LDAP Server Type Select the backend LDAP server type from the following choices:
 Generic
 Active Directory
 iPlanet
 Novell eDirectory
Connection Select one of the following options for the connection to the LDAP server:
 Unencrypted– The device sends the username and password to the LDAP Directory Service in
cleartext.
 LDAPS– The device encrypts the data in the LDAP authentication session using the Secure
Socket Layer (SSL) protocol before sending it to the LDAP Directory Service.
 Start TLS– The device allows both secure and plain requests against an LDAP server on a single
connection.
NOTE:
 If you select LDAPS or Start TLS, the Validate Certificate option is displayed for the configured
LDAP server(s) and its referral servers. Select this option if the SSL connection uses digital
certificate security.
 If you enable validation for the referral servers, make sure your network DNS supports reverse
lookup zone.
 If you want to verify the server certificates, the root CA and Intermediate CAs must be imported
as trusted CAs.
Connection Timeout Specify the time to wait for connection to the primary LDAP server, and then to each backup LDAP
(seconds) server.
Default: 15 seconds

Table 32: LDAP Server Settings (continued)
Settings Guidelines
Search Timeout Specify the time to wait for search results from a connected LDAP server.
(seconds)
Test Connection (Optional) To verify the connection between Junos Pulse and LDAP servers, click the Test Connection
button.
NOTE: We recommend using the Test Connection function only after saving changes on the LDAP
Server Configuration page.
Authentication required?
Authentication required Select this option to require authentication when performing search or password management
to search LDAP operations.
NOTE:
 If you use Active Directory, you must select the Authentication required to search LDAP check box
and provide the full DN and password of an account that can reach Active Directory.
 You can enable password management on any LDAP server.
This feature enables users who authenticate through an LDAP server to manage their passwords
through the system using the policies defined on the LDAP server. To enable password
management on any LDAP server, you must provide an administrator account (with write privileges
to the directory) for the administrator DN.
Admin DN Specify the administrator DN for queries to the LDAP directory.
Password Specify the password for the LDAP server.
Finding user entries

Base DN Specify the base DN under which the users are located. For example, dc=sales,dc=acme, dc=com.
Filter Specify a unique variable that can be used to do a fine search in the tree. For example,
samAccountname=<username> or cn=<username>.
NOTE:
 Include <username> in the filter to use the username entered on the sign-in page for the search.
 Specify a filter that returns 0 or 1 user DNs per user; the device uses the first DN returned if more
than 1 DN is returned.
Remove Domain from Windows users names?

Strip domain from Select this option to pass the username without the domain name to the LDAP server.
Windows user name
Enable Challenge-Response open protocols?

Enable Select this option if you want to use a challenge-response protocol for authentication.
Challenge-Response
open protocols NOTE: By default, these protocols are disabled for LDAP servers because account management
is not possible.
Determining group membership

Table 32: LDAP Server Settings (continued)
Settings Guidelines
Base DN Specify the base DN to search for user groups.
Filter Specify a unique variable which can be used to do a fine search in the tree. For example,
samAccountname=<username> or cn=<GROUPNAME>.
Member Attribute Specify all the members of a static group. For example, member or uniquemember (iPlanet specific).
Reverse group search Select this option to start the search from the member instead of the group. This option is available
only for Active Directory server types.
Query Attribute Specify an LDAP query that returns the members of a dynamic group. For example, memberURL.
Nested Group Level Specify how many levels within a group to search for the user.
NOTE: The higher the number, the longer the query time, so we recommend that you specify to
perform the search no more than two levels deep.
Nested Group Search Select one of the following options:
 Nested groups in Server Catalog–This option is faster because it can search within the implicit
boundaries of the nested group.
 Search all nested groups–With this option, the device searches the Server Catalog first. If the
device finds no match in the catalog, then it queries LDAP to determine if a group member is a
subgroup.

Figure 44 on page 323 shows the Users page for Pulse Policy Secure. The Users
page for Pulse Connect Secure is similar.
click Update.


 To terminate the user session and delete the account, select the checkbox next to

Documentation
 Using the LDAP Password Management Feature on page 323

 Using the LDAP Server Catalog on page 435
 Using the LDAP Server Catalog
Using the LDAP Password Management Feature
This topic describes support and limitations for LDAP password management. It includes
 LDAP Password Management Feature Overview on page 323

 Enabling LDAP Password Management on page 324
 LDAP Password Management Support on page 324
 LDAP Password Management for Windows AD Versions on page 326
 Troubleshooting LDAP Password Management on page 328
LDAP Password Management Feature Overview

The password management feature enables users who access an LDAP server to manage
their passwords through the Pulse Policy Secure access management framework
using the policies defined on the LDAP server. For example, if a user tries to sign in to
the system with an LDAP password that is about to expire, the system notices the user
through the

interface, and then passes the user’s response back to the LDAP server without requiring
the user to sign in to the LDAP server separately.
Users, administrators, and help desk administrators who work in environments where
passwords have set expiration times may find the password management feature very
helpful. If users are not informed that their passwords are about to expire, they can change
them themselves through the system rather than call the help desk.
Once this feature is enabled, the system performs a series of queries to determine user
account information, such as when the user’s password was last set, whether the account
is expired, and so on. The Pulse Policy Secure access management framework does this
by using its internal LDAP or Samba client. Many servers, such as Microsoft Active
Directory or Sun iPlanet, offer an Administrative Console to configure account and
password options.
LDAP-based password management works with only three types of LDAP servers:
 Microsoft Active Directory. For Active Directory, password policy attributes can be
configured in the user entry container level or any organization level above the user
container. If these attributes are configured at multiple levels, the level closest to the
user node takes precedence. The password management feature is not supported on
the Active Directory Global Catalog because password policy attributes are not fully
populated in the Active Directory Global Catalog.
 For Active Directory 2008, the Pulse Policy Secure access management framework
supports the Fine Grained Password Policy (FGP) configured in the AD user
container.
 Sun Microsystems iPlanet
LDAP-based password management does not work on generic LDAP servers such as
OpenLDAP.
The system relies on the back-end server to pinpoint the cause of error when a password
change operation fails. However, although LDAP servers may report errors accurately to
human operators, they do not always do so when communicating programmatically to
systems. Therefore, reported errors might be generic or cryptic.
The system does not support customized password policies.
Enabling LDAP Password Management

To enable password management, you must first create an instance of the LDAP server.
Next, you associate the LDAP server with the applicable realms. Finally, you select the
enable password management feature at the realm level.
LDAP Password Management Support

The Pulse Policy Secure access management framework supports password
management with the following LDAP directories:
 Microsoft Active Directory/Windows NT
 Sun iPlanet

 Generic LDAP directories, such as IBM Secure Directory and OpenLDAP
Table 33 on page 325 describes supported password management functions, their

corresponding function names in the individual LDAP directories, and any additional
relevant details. These functions must be set through the LDAP server itself before the
system can pass the corresponding messages, functions, and restrictions to end users.
The Active Directory attribute names shown are specific to the Domain Security Policy
object. Similar attributes for the corresponding functions are used for the Active Directory
2008 Fine-Grained Password Policy. Refer to Microsoft documentation for details.
When authenticating against a generic LDAP server, such as IBM Secure Directory, the
system supports only authentication and allowing users to change their passwords.
Password management functions are not supported when the CHAP family protocols
are used for authentication. All functions are available when the JUAC protocol is used
for authentication.
Table 33: Supported Password Management Functions
Function Active Directory iPlanet eDirectory Generic
Authenticate user unicodePwd userPassword userPassword userPassword
Allow user to change Server tells us in bind If passwordChange == If passwordAllowChange Yes

password if enabled response (uses ON == TRUE
ntSecurityDescriptor)
Log out user after Ye Ye Ye Yes

password change s s s
Force password change If pwdLastSet == 0 If passwordMustChange If pwdMustChange == -

at next login == ON TRUE
Expired password userAccountControl== If Bind Response Check date/time value -

notification 0x80000 includes OID
2.16.840.1.113730.3.4.4
== 0
Password expiration if pwdLastSet - now() < If Bind Response If now() -

notification (in X maxPwdAge - 14 days includes control OID passwordExpirationTime<
days/hours) 2.16.840.1.113730.3.4.5 14 days
(Read from domain (contains date/time) (The system displays
attributes) (The system displays warning if less than 14
(The system displays warning if less than 14 days)
warning if less than 14 days)
days)
Disallow authentication userAccountControl== Bind ErrorCode: 53 Bind ErrorCode: 53

if "account 0x2 (Disabled) "Account Inactivated" "Account Expired"
disabled/locked accountExpires Bind Error Code: 19 Bind ErrorCode: 53
userAccountControl == "Exceed Password Retry "Login Lockout"
0x10 (Locked) Limit"
lockoutTime

Table 33: Supported Password Management Functions (continued)
Function Active Directory iPlanet eDirectory Generic
Honor "password Server tells us in bind Server tells us in bind Server tells us in bind
history" response response response
Enforce "minimum If set, the system If set, the system If set, the system
password length" displays message telling displays message telling displays message telling
user minPwdLength user passwordMinLength user
passwordMinimumLength
Disallow user from If pwdLastSet - now() < If passwordMinAge > 0, Server tells us in bind
changing password too minPwdAge, then we then if now() is earlier response
soon disallow than
passwordAllowChangeTime,
then we disallow
Honor "password If pwdProperties == 0x1, Server tells us in bind Server tells us in bind
complexity" then enabled. response response
Complexity means the
new password does not
contain username, first
or last name, and must
contain characters from
3 of the following 4
categories: English
uppercase, English
lowercase, Digits, and
Non-alphabetic
characters (ex. !, $, %)
Note the following expected behavior:
 When you select the User must change password after reset option on the iPlanet
server, you must also reset the user password before this function takes effect. This
issue is a limitation of iPlanet.
 The system displays a warning about password expiration only if the password is
scheduled to expire in 14 days or less. The system displays the message during each
sign-in attempt. The warning message contains the remaining number of days, hours,
and minutes that the user has to change the password before it expires on the server.
The default value is 14 days, but you can change it on the password configuration page
of the admin console.
LDAP Password Management for Windows AD Versions

The Pulse Policy Secure access management framework supports password
management with the following Windows servers:
 Microsoft Active Directory 2008
 Microsoft Active Directory 2003

 Windows NT 4.0
Table 34 on page 327 describes supported password management functions. These

functions are not supported for a layer 2 connection when CHAP, MS-CHAP, or PAP are
used as authentication protocols.
Table 34: AD/NT Password Management Matrix
Active Directory 2008

Function Active Directory Active Directory 2003 FGP Windows NT
Authenticate user Ye Ye Ye Yes

s s s
Allow user to change Yes Yes Yes Yes

password if licensed and
if enabled
Log out user after Ye Ye Ye Yes

password change s s s
Force password change Yes Yes Yes Yes

at next login
Password expired Ye Ye Ye Yes

notification s s s
Account disabled Yes Yes Yes Yes
Account expired Ye Ye Ye Yes

s s s
Note the following expected behavior:
 Changes on the Active Directory domain security policy can take 5 minutes or longer
to propagate among Active Directory domain controllers. Additionally, this information
does not propagate to the domain controller on which it was originally configured for
the same time period. This issue is a limitation of Active Directory.
 When changing passwords in Active Directory using LDAP, the system automatically
switches to LDAPS, even if LDAPS is not the configured LDAP method. To support
LDAPS on the Active Directory server, you must install a valid SSL certificate into the
server’s personal certificate store. The certificate must be signed by a trusted CA, and
the CN in the certificate’s Subject field must contain the exact host name of the Active
Directory server, (for example: adsrv1.company.com). To install the certificate, select
the Certificates Snap-In in the Microsoft Management Console (MMC).
 The Account Expires option in the User Account Properties tab only changes when the
account expires, not when the password expires. Microsoft Active Directory calculates
the password expiration using the Maximum Password Age and Password Last Set
values retrieved from the User object and Fine-Grained Password Policy objects or the
Domain Security Policy LDAP objects.
 The system displays a warning about password expiration only if the password is
scheduled to expire in 14 days or less. The system displays the message during each

sign-in attempt. The warning message contains the remaining number of days, hours,
and minutes that the user has to change the password before it expires on the server.
The default value is 14 days, but you can change it on the password configuration page
of the admin console.
Troubleshooting LDAP Password Management

When you troubleshoot, provide any pertinent system logs, server logs, configuration
information, and a TCP trace from the system. If you are using LDAPS, switch to the
“Unencrypted” LDAP option LDAP server configuration while taking the LDAP TCP traces.
Related Using an LDAP Server on page 316

Documentation

Using the MAC Address Authentication Server
This topic describes how to use the MAC address authentication server. It includes the
 MAC Address Authentication Server Overview on page 328

 Configuring the MAC Address Authentication Server on page 330
MAC Address Authentication Server Overview

This section describes the Pulse Policy Secure MAC address authentication solution. It
includes the following sections:
 Understanding MAC Address Authentication on page 328

 MAC Address Authentication Server Feature Support on page 329
 Licensing on page 329
 MAC Address Authentication Framework Configuration Overview on page 329
 802.1x Framework Configuration Overview on page 330
 Ethernet Switch MAC Address Authentication Configuration Overview on page 330
Understanding MAC Address Authentication
MAC address authentication is port-based security typically deployed at the edge of the
network to enable secure access for non-user devices, such as IP phones, printers, and
network attached storage devices. The Pulse Secure MAC address authentication
solution uses the Pulse Policy Secure 802.1x framework. When a device connects to a
switch, the switch forwards the MAC address as the login credential to the Pulse Policy
Secure RADIUS server. With MAC-based authentication, the MAC address serves as
both the username and the password. The RADIUS server consults the authentication
server and sends back a RADIUS return attribute based on authentication results.

BEST PRACTICE: MAC-based authentication is not as secure as agent access

or agentless access authentication. MAC addresses are not generally guarded
as secrets, so an attacker can spoof a MAC address and impersonate a device
to gain network access. To reduce risk of an exploit, create a special VLAN
for each device type.
MAC Address Authentication Server Feature Support
The MAC address authentication server is a local authentication server that supports
both a local database of records and integration with LDAP servers. You can add entries
manually or by reference to LDAP servers. The address table for each local MAC address
authentication server is limited to 500 entries. We recommend you use LDAP for
large-scale projects.
Integration with an LDAP server requires the LDAP server to communicate with the Pulse
Policy Secure internal interface.
Licensing
Unlike the user access management framework, the MAC address authentication
framework does not require an ACCESS, ADD, or RADIUS license. The number of
authentications is unlimited.
MAC Address Authentication Framework Configuration Overview
The MAC address authentication framework is similar to the user access management
framework. It involves configuration of a MAC address authentication server, MAC address
realm, and roles.
To implement the MAC address authentication framework:
1. If necessary, use the Authentication Protocols Sets page to add the protocols that
your Ethernet switches use for MAC authentication to the Pulse Policy Secure
802.1x protocol set. Go to Authentication > Signing In > Authentication Protocols Sets.
The HP and Cisco switches can use CHAP and EAP-MD5-Challenge protocols for
MAC address authentication with the username (the MAC address) as the clear text
password. By default, the Nortel switch uses PAP, with a password in the format
.<MAC Address>. We recommend using PAP with the Nortel switch.
2. Create LDAP server configurations for the external LDAP servers used to maintain
MAC address records.
3. Create a MAC address authentication server.
4. Create roles for agentless access.
5. Create a MAC address authentication realm that uses the MAC address authentication
server and role mapping rules that sort MAC address authentication requests into
roles according to your security policy design.

802.1x Framework Configuration Overview
The MAC address authentication solution uses the Pulse Policy Secure 802.1x
framework.
To implement the 802.1x framework:
1. Complete the Location Group configuration.
2. Complete the RADIUS Client configuration.
3. Complete the RADIUS Return Attributes Policy configuration.
Ethernet Switch MAC Address Authentication Configuration Overview
The MAC address solution depends on the Ethernet switch configuration.
To configure MAC address authentication on the Ethernet switch:
1. Configure the switch as an 802.1x authenticator and enable MAC RADIUS protocols.
2. Configure RADIUS client communication with the Pulse Policy Secure RADIUS
server.
3. Configure Ethernet switching options and VLANs to provision VLANs for non-user
devices.
Configuring the MAC Address Authentication Server

To configure the MAC address authentication server:
2. Select MAC Address Authentication and click New Server to display the configuration
page.
The MAC address authentication server configuration page is shown in

Figure 45 on page 331.

Figure 45: New MAC Address Authentication Server Configuration Page
Table 35: MAC Address Authentication Server Settings
Settings Guidelines
Name Specify a name to identify the configuration. Follow a convention that is helpful to you and others
who might perform administration tasks.
MAC Addresses
MAC Address Enter a MAC address. The system supports various formats, including no-delimiter
(003048436665), single dash (003048-436665), multidash (00-30-48-43-66-65), and
multicolon (00:30:48:43:66:65). The system supports wildcards (00:30:*:*:*:*). In the user log,
entries appear in the multicolon format.

Table 35: MAC Address Authentication Server Settings (continued)
Settings Guidelines
Action Select an action to take when the MAC address matches:
 Allow—Signal successful authentication.

 Deny—Signal unsuccessful authentication.
 Allow and Attributes—Typically, a match terminates the search. If you select Allow and Attributes,
the search is not terminated; instead, the system searches the LDAP servers for a match in order
to retrieve the LDAP authorization attributes.
Attributes Specify a name-value pair to associate the MAC address with a particular group or organization.
For example, dept=eng is a name-value pair that associates the MAC address with a department
(engineering). When you create the MAC address realm, you can create a custom expression to
assign the MAC address to a specific role.
Optional LDAP Servers

Available / Selected Use the Add and Remove selector buttons to add LDAP servers to the list of selected servers. Use
LDAP Servers the up and down buttons to order the list.
The order in which the LDAP servers are listed is important. The system searches for MAC address
matches in the following order:
1. If the MAC address of the endpoint matches a manual entry, the system does not query servers
in the LDAP server list.
2. If no manual entries match, the system tries the first LDAP server.
3. If the request times out or gets rejected, the system tries the second, then the third, and so on.
NOTE: Each LDAP server that must be queried affects performance.
Server Catalog
Attributes If you have selected LDAP servers in the configuration, save the configuration. After you have saved
the configuration, the Attributes button is displayed. Click the Attributes button to display the LDAP
server catalog, which you can use to select or add attributes to be retrieved from the LDAP servers.

The user accounts table for the MAC address authentication server is shown in

click Update.
 To terminate the user session and delete the account, select the box next to the
user account record and click Delete.

Documentation
 Using an LDAP Server on page 316

 Configuring a MAC Address Authentication Realm on page 429
 Example: Using Endpoint Discovery and Profiling for MAC Address Authentication on
page 334
 Pulse Policy Secure: 802.1x
 EX Series: Access Control

Example: Using Endpoint Discovery and Profiling for MAC Address Authentication
This configuration example describes the Juniper Networks endpoint discovery and
profiling solution. It includes the following information:
 About Endpoint Discovery and Profiling on page 334

 Obtaining the MAG-SM360-PROFILER Service Module on page 335
 Installing the MAG-SM360-PROFILER Service Module on page 335
 Getting Started with Endpoint Profiler on the MAG-SM360-PROFILER Service
Module on page 336
 Licensing the Beacon Endpoint Profiler Software on page 337
 Using the Beacon Endpoint Profiler to Discover Devices in Your Network on page 338
 Configuring the Beacon Endpoint Profiler LDAP Features on page 338
 Configuring the Pulse Policy Secure MAC Address Authentication
Framework on page 344
 Configuring the EX Series Switch on page 360
About Endpoint Discovery and Profiling

Deploying a Juniper Networks endpoint and discovery solution enables an IT organization
to authenticate, secure, and manage user-based endpoints such as PCs and laptops.
User-based devices can be challenged for usernames and passwords or for
two-factor-based authentication. However, the endpoints on today’s enterprise network
are varied and might not be attached to a user or might not be able to run client software
for authentication. Examples of such endpoints are printers, VoIP handsets, WLAN access
points, and security systems.
IT organizations are challenged to discover, locate, and monitor such endpoints to

successfully deploy network-based authentication and network access control (NAC).
Once located, these devices must be provisioned with the appropriate level of network
access and monitored to ensure they behave in an acceptable manner given their known
identity. The discovery, location, and provisioning of these nonauthenticating endpoints
is a core function of the Endpoint Profiler, which is now available on MAG Series devices.
The combination of Endpoint Profiler and Pulse Policy Secure running on MAG Series
Pulse Secure Gateways provides a comprehensive network access control and profiling
solution for the enterprise.
The Endpoint Profiler provides a comprehensive accounting of all network-attached

endpoints. This inventory provides a real-time view of each network-attached device’s
location, MAC address, IP address, identity, and behavior, as well as a historical view of
these attributes. This information is used to facilitate the deployment of 802.1X access
control by relieving the requirement to discover all enterprise endpoints manually. The
Pulse Policy Secure sends Lightweight Directory Access Protocol (LDAP) queries to the
Endpoint Profiler software and performs MAC authentication based on the response.
Thus, effectively, the information stored within Endpoint Profiler is leveraged by the
Pulse Policy Secure to authenticate endpoints that are not running an authentication
client. This could be due to the endpoint being incapable of running a client (for example,

VoIP devices), being new to the enterprise, or in need of temporary access. In concert,
this solution provides authentication to the entire enterprise and avoids the costly and
unwieldy option of manually configuring all network ports.
Figure 47 on page 335 shows the deployment configured in this example.
Figure 47: Endpoint Profiler and Pulse Policy Secure Deployment
In this example, we use an IP phone profile. An IP phone connects to the network through
a Juniper Networks EX Series switch. The Beacon Endpoint Profiler builds an LDAP
directory of VoIP devices. The Pulse Policy Secure uses this LDAP directory for MAC
address authentication.
Obtaining the MAG-SM360-PROFILER Service Module

The MAG-SM360-PROFILER service module can be installed into a MAG6610 or MAG6611
chassis. The MAG-SM360-PROFILER service module hardware is similar to the
MAG-SM360 service module hardware, but it is a separate SKU, and you cannot change
the personality of a regular MAG-SM360 service module to load the Endpoint Profiler
software. You must order the specific MAG-SM360-PROFILER hardware SKU.
Installing the MAG-SM360-PROFILER Service Module

Install the MAG-SM360-PROFILER service module into a MAG6610 or MAG6611 chassis.
If you are new to MAG Series hardware, see the Pulse Secure Gateway Hardware topic
collection. If you are already familiar with MAG Series hardware, see Installing the
MAG-SM360-PROFILER Kit.

Getting Started with Endpoint Profiler on the MAG-SM360-PROFILER Service Module

Great Bay Software Beacon Endpoint Profiler is preinstalled on the
MAG-SM360-PROFILER service module. After you have installed the service module
into the chassis, you connect a console terminal or laptop running a terminal emulation
program to the appliance serial console port to configure the following basic network
settings:
 Passwords. The beacon system user password (a CLI account), the root user password
(CLI), and the administrator Web console admin user password.
 Hostname. Enter the hostname carefully; licensing is bound to the hostname.
 Management interface (eth0) IP address. The eth0 port is used for system
management, as well as the endpoint profiling traffic.
 Default gateway router address and netmask, DNS, and NTP.
 Beacon system type: All-in-One, Server Only, Remote Collector.
 Self-signed SSL certificate.
After you have configured these settings, you can use the Beacon Endpoint Profiler
administrator Web console to configure and use Endpoint Profiler features.
To configure basic network settings with the serial console:
1. Configure a console terminal or terminal emulation utility running on a computer, such

as HyperTerminal, with the following serial connection parameters:
 9600 bits per second
 8-bit no parity (8N1)
 1 stop bit
 No flow control
2. Connect the terminal or laptop to the serial cable plugged into the appliance console
port, and press Enter until you see the Beacon system login prompt, shown in
Figure 48: Beacon System Login Prompt
Upon logging in as root for the first time, the system displays the setup dialog box,
shown in Figure 49 on page 337.

Figure 49: Beacon Setup Dialog Box
3. Complete the setup wizard as described in the Great Bay Software Beacon Endpoint
Profiler Configuration Guide, beginning on page 4-6.
NOTE: If the screen shown in Figure 49 on page 337 is not shown upon first
login as the root system user, enter the command service profiler config to
start the Beacon startup scripts manually.
Licensing the Beacon Endpoint Profiler Software

Obtain license key files from your Pulse Secure sales contact. License key files are
tied to hostnames, so make plans and communicate with your sales contact precisely
about this point. The hostname value embedded in the license key is case sensitive.
You add license key files to the Beacon Endpoint Profiler as described in the Great Bay
Software Beacon Endpoint Profiler Configuration Guide, beginning on page 5-5.
To add a license key file to the Beacon Endpoint Profiler:
1. Copy the license key file to your local host computer or a location you can browse
from your local host computer.
2. Log into the Beacon Endpoint Profiler Web administrator console at https://<eth0
IP address>/beacon/login.html.
3. Navigate to Home > Upload Key.
4. Click Browse and select the license key file.
5. Click Import Key.
The system confirms you have imported the license key file. While it validates the license,
it indicates no valid key is loaded (Figure 50 on page 338). After validation, the page
refreshes and shows the validated license details (Figure 51 on page 338).

Figure 50: License Key Page During Validation
Figure 51: License Key Page After Validation
Using the Beacon Endpoint Profiler to Discover Devices in Your Network

Use the Great Bay Software Beacon Endpoint Profiler Configuration Guide to learn about
Endpoint Profiler features. Configure the Server Module, Collector Module, Endpoint
Profiles, Events, and so forth to build the Endpoint Profiler database inventory of attached
network devices.
Configuring the Beacon Endpoint Profiler LDAP Features

The Beacon Endpoint Profiler Server Module maintains an LDAP directory with records
of the endpoints profiled by the Beacon system. The Beacon LDAP directory responds
to LDAP queries initiated by the Pulse Policy Secure. The two systems use LDAP to
communicate. For complete information on implementing and managing Beacon LDAP
integration features, see Chapter 16 of the Great Bay Software Beacon Endpoint Profiler
Configuration Guide. The following procedure illustrates the key steps for integration with
the Pulse Policy Secure.

To configure the Beacon side of the LDAP communication:
1. Log into the Beacon Endpoint Profiler Web administrator console at https://<eth0
IP address>/beacon/login.html.
2. Use the Endpoint Profiles management pages to enable LDAP records for discovered
endpoints. For example:
a. Navigate to Configuration > Profiles to display the Endpoint Profiles management

page, shown in Figure 52 on page 339.
Figure 52: Endpoint Profiles Management Page
b. Click View/Edit Profiles to display the listings of predefined endpoint profiles, shown
in Figure 53 on page 339.
Figure 53: Endpoint Profiles Listing

c. Use the controls to find the profiles you are interested in. Figure 54 on page 340 uses
the Display by Group VoIP Phone filter to display VoIP phone listings.
Figure 54: Endpoint Profiles VoIP Phone Listing

d. Select the profile you want and click Modify to display its configuration page.
Figure 55 on page 341 shows the PolyComVOIP profile configuration page.
Figure 55: PolyComVOIP Profile Configuration Page
e. Select the Yes option to enable the profile and enable the LDAP setting, as shown
in Figure 55 on page 341.
f. Use Chapter 9 of the Great Bay Software Beacon Endpoint Profiler Configuration Guide
to configure the rules.
g. Click Save Profile.
TIP: Figure 53 on page 339 through Figure 55 on page 341 show how to select
and enable LDAP for a single profile. When you get started with endpoint
profiling, you more likely want to profile a wide range of endpoints, so you

can learn the baseline of endpoints in your network. Use the select all
options shown in Figure 56 on page 342 to select and enable LDAP for
multiple profiles.
Figure 56: Selecting and Enabling LDAP for All Profiles
3. Enable the Beacon system to accept LDAP queries and automatically synchronize
the LDAP directory with the Beacon database:
a. Navigate to Configuration > Integrations to display the Integrations management

Figure 57: Integrations Management Page
b. In the Internal LDAP Directory group of settings, select the Enable option. Verbose
logging is optional. Leave the "Bind to endpoint" option disabled unless you are

fully aware of the security implications of this option.
4. Update of the Beacon Modules is required for any configuration change to take effect.
Apply the configuration changes:
a. Navigate to Configuration > Apply Changes to display the Update Beacon Modules
Figure 58: Update Beacon Modules Page
b. Click Update Modules to apply the configuration changes and perform an initial
synchronization of the LDAP Directory.
5. Verify the progress of the update:
a. Navigate to the Configuration > Modules page to display the Configure Beacon
Modules page, shown in Figure 59 on page 343.
Figure 59: Configure Beacon Modules Page
b. Click List Beacon Modules to display the status page. When you initiate the update,
the status page reports the module processes are stopped, as shown in

Figure 60 on page 344. Refresh your browser page to see changes in the status page.
When the update is complete, the status page reports the module processes are
running, as shown in Figure 61 on page 344.
Figure 60: Modules Stopped
Figure 61: Modules Running
Configuring the Pulse Policy Secure MAC Address Authentication Framework

This section describes the Pulse Policy Secure configuration for this example. It includes
 Configuring the Authentication Protocol Set on page 345

 Configuring the Authentication Servers on page 346
 Configuring User Roles for the MAC Address Authentication Realm on page 353
 Configuring the MAC Address Authentication Realm and Role Mapping Rules on page 354
 Configuring the RADIUS Framework on page 357

Configuring the Authentication Protocol Set
Switches from various vendors may use the standard Password Authentication Protocol
(PAP), CHAP, or EAP-MD5 protocols for MAC authentication. These protocols are not
included in the default authentication protocol set for 802.1x deployments.
To add PAP, CHAP, and EAP-MD5 to the 802.1x protocol set:
1. Log into the Pulse Policy Secure Web administrator interface.
2. Select Authentication > Signing In > Authentication Protocols Sets to display the
Authentication Protocol Sets page, shown in Figure 62 on page 345.
Figure 62: Authentication Protocol Sets
3. Click the 802.1x link to edit the 802.1x authentication protocol set configuration.
4. Use the selector buttons to add PAP, CHAP, and EAP-MD5-Challenge to the 802.1x
authentication protocol set, as shown in Figure 63 on page 346.

Figure 63: Authentication Protocol Sets
Configuring the Authentication Servers
The MAC authentication with Beacon Endpoint Profiler solution uses two Pulse Policy
Secure authentication server configurations: an LDAP Server configuration and a MAC
Address Authentication configuration.
To configure the LDAP Server settings:
2. Select LDAP Server and click New Server, as shown in Figure 64 on page 346.
Figure 64: Selecting a New LDAP Authentication Server

3. Complete the configuration for the Beacon LDAP directory server. The Pulse Policy
Secure internal interface must be able to communicate with the LDAP Server.
Table 36 on page 347 provides guidelines for key settings. Figure 65 on page 348 shows
the complete configuration.
Table 36: Key LDAP Authentication Server Settings
Setting Guideline
Authentication Required? Admin DN: cn=root,o=beacon
Password: GBSbeacon
Finding User Entries Base DN: o=beacon
Filter: (& (objectClass=ieee802Device) (macAddress=<USER>))
Determining group membership Base DN: o=beacon
Filter: (& (objectClass=groupOfUniqueNames) (cn=<GROUPNAME>))
NOTE: The Filter setting for determining group membership shown in

Table 36 on page 347 is good for demonstration, validation, and
troubleshooting purposes because it allows you to click through to the
server catalog and see the LDAP-enabled profiles. However, we
recommend removing this filter configuration in production deployments
to reduce the number of lookups and resulting process utilization. In effect,
the setting shown in this example causes the Pulse Policy Secure to go
through every group and check whether the endpoint is a member of
that group. In production employments, you want to use a more precise
filter.

Figure 65: LDAP Authentication Server Settings
NOTE: You can ignore the Unable to Connect to LDAP Server warning
displayed after you save the configuration. You test the LDAP connection
in the next step.

NOTE: The LDAP Server settings shown Figure 65 on page 348 show an
unencrypted connection. Using an unencrypted connection is fine for
demonstration purposes. However, we recommend using the LDAPS
option to ensure better security in production deployments.
Figure 66 on page 350 shows the Pulse Policy Secure configuration for
LDAPS. On Beacon Endpoint Profiler, you use the service profiler
setupladps command to disable the unencrypted connection and enable
LDAPS on port 636. For detailed information, see page 16-10 of the Great
Bay Software Beacon Endpoint Profiler Configuration Guide.

Figure 66: LDAP Authentication Server Settings with LDAPS Option and
Port 636 Enabled
4. Test the configuration:
a. On the LDAP server configuration page, click the Server Catalog link, circled in
Figure 65 on page 348, to display the Server Catalog page, shown in
Figure 67: LDAP Server Catalog

b. Click Search to query the Beacon LDAP directory.
The LDAP connection is configured properly if the query returns profile entries
similar to Figure 68 on page 351. If this test fails, troubleshoot the Beacon Endpoint
Profiler configuration as described in Chapter 16 of the Great Bay Software Beacon
Endpoint Profiler Configuration Guide.
Figure 68: LDAP Server Query Results
To configure the MAC address authentication settings:
2. Select MAC Address Authentication and click New Server, as shown in


Figure 69: Selecting a New MAC Address Authentication Server
3. Complete the configuration for the MAC address authentication server. The key setting
in this configuration is to select the Beacon LDAP server under the Optional LDAP
Servers group of settings. Figure 70 on page 352 shows the complete configuration.
Figure 70: MAC Address Authentication Server Settings
NOTE: It is possible to add both the LDAP-determined entries and manual

entries to the MAC Address Authentication configuration. If the MAC address
of the endpoint matches a manual entry, that MAC address is not looked up
in the LDAP server.

Configuring User Roles for the MAC Address Authentication Realm
The Pulse Policy Secure access management framework evaluates authentication

requests to match endpoints to roles. You must configure user roles for the various types
of endpoints authenticated by the MAC address authentication framework.
To create a user role:
1. Select Users > User Roles.
2. Click New Role.
3. Complete the name and description configuration as shown in Figure 71 on page 353;
then save the configuration.
Figure 71: User Role General Configuration
4. Click Agent and deselect agent options, as shown in Figure 72 on page 354; then save
the configuration.

Figure 72: User Role Agent Configuration
5. Click Agentless and enable agentless access, as shown in Figure 73 on page 354; then
save the configuration.
Figure 73: User Role Agentless Configuration
NOTE: Do not configure role restrictions for roles used with a MAC address
authentication realm.
Configuring the MAC Address Authentication Realm and Role Mapping Rules
The MAC address authentication framework uses a special realm, called the MAC Address
Authentication Realm. When the access framework uses the MAC address authentication
realm, you do not need to configure a sign-in policy. In the User realm and the Admin
realm frameworks, the system uses sign-in policies to match authentication requests to
the appropriate realm; in the MAC Address authentication realm framework, any username
credential that matches one of the common variants of a MAC address format

(colon-separated, dash-separated, and the like) is sent to the MAC authentication realm
based on its format.
To configure the MAC Address authentication realm and role mapping rules:
1. Select UAC > MAC Address Realm.
2. Click New to create a new configuration.
3. Complete the configuration as shown in Figure 74 on page 355. Table 37 on page 355
summarizes the key settings.
Table 37: Key MAC Address Authentication Realm Settings
Setting Guideline
Authentication server Select the MAC Address authentication server configured earlier
Directory/Attribute server Select the LDAP authentication server configured earlier.
NOTE: The default Directory/Attribute Server setting is same as above.

Do not use this default. If you do not change this to reflect the LDAP server
added earlier in this example, the integration does not succeed.
Figure 74: MAC Address Authentication Realm Settings
Upon saving the new realm, the system displays the role mapping rules page.
5. Click New and complete the role mapping configuration as shown in

Figure 75 on page 356. Table 38 on page 356 summarizes key settings.

Table 38: Key MAC Address Authentication Realm Role Mapping Settings
Setting Guideline
Role based on Select User attribute.
Attribute  Click the Attributes button to browse the reference of Beacon LDAP directory
server attributes.
 Select memberOfGroup.
 Select the = operator.
 Type the cn value, for example, cn=Polycom IP phone*.
NOTE:
Be sure to use the wildcard * in your cn attribute expression, like the usage in the
cn=Polycom IP phone* expression shown above.
Role Select the role configured earlier in this example.
Figure 75: MAC Address Authentication Realm Role Mapping Settings
Figure 76 on page 357 shows the completed role mapping rule summary.

Figure 76: MAC Address Authentication Realm Role Mapping Rule

Summary
Configuring the RADIUS Framework
The switch initiates authentication by sending an 802.1X EAP Start, to which the endpoint
does not respond because it does not have a supplicant. The switch waits a configurable
timeout period; then, upon receiving no response, it sends a RADIUS request to the RADIUS
server, using PAP, for example, with the MAC address of the endpoint as the username
and one of several options (no password, MAC as password, configurable string as
password) as password.
In this example, the EX Series switch is the 802.1x authenticator and is configured to
allow MAC RADIUS authentication as a fallback for nonsupplicant endpoints. It sends a
RADIUS client request to the Pulse Policy Secure RADIUS server, which performs
authentication against the Beacon LDAP entries. The Pulse Policy Secure RADIUS
server returns a RADIUS return attribute to the RADIUS client. In this case, it sends the
EX Series switch the VLAN ID to which the MAC-authenticated endpoint can be admitted.

To configure the Pulse Policy Secure 802.1x framework for nonsupplicant endpoints:
1. Configure a location group:
a. Select UAC > Network Access > Location Group.
b. Complete the configuration as shown in Figure 77 on page 358. The key setting in
this configuration is the MAC authentication realm. Select the realm you configured
earlier in this example.
c. Save the configuration.
Figure 77: Location Group Settings
2. Configure a RADIUS client:
a. Select UAC > Network Access > RADIUS Client.
b. Complete the configuration as shown in Figure 78 on page 358. The key settings in
this configuration are connection settings for the EX Series switch and the Location
Group. Connection settings must match the EX Series switch configured in the next
section. Select the Location Group you configured earlier in this example.
NOTE: We recommend you enable the Support Disconnect Messages

option. This option enables the IC to terminate a MAC-authenticated
session by sending a RADIUS disconnect to a switch that supports
RADIUS Change of Authorization. This enables the Pulse Policy
Secure to take advantage of IF-MAP integration with the Beacon
Endpoint Profiler behavior monitoring capability, providing protection
against MAC spoofing.
Figure 78: RADIUS Client Settings

3. Configure a RADIUS return attributes policy:
a. Select UAC > Network Access > RADIUS Return Attributes.
b. Complete the configuration as shown in Figure 79 on page 359. The key settings for
this configuration are Location Group, VLAN, and Role. Select the Location Group
and Role you configured earlier in this example. Specify a VLAN on the EX Series
that allows access to the network, or select the Open port option to instruct the
switch to place the endpoint on the native VLAN configured on the port.
Figure 79: RADIUS Return Attribute Policy Settings

Configuring the EX Series Switch

The nonsupplicant devices, such as VoIP phones, connect to the network through an EX
Series switch using MAC RADIUS authentication. You configure the following EX Series
features to support this solution:
 Configure the switch as an 802.1x authenticator and enable MAC RADIUS protocols.
 Configure RADIUS client communication with the Pulse Policy Secure RADIUS
server.
 Configure Ethernet switching options and VLANs to provision a VLAN for VoIP phones.
The following example shows commands that configure the ge-0/1/0.0 and ge-0/1/1.0
interfaces as 802.1x authenticators, enable MAC RADIUS protocols, and create a reference
to the authentication profile used for integration with the Pulse Policy Secure RADIUS
server:
set protocols dot1x authenticator authentication-profile-name
juniper-access-profile
set protocols dot1x authenticator interface ge-0/1/0.0 supplicant multiple

set protocols dot1x authenticator interface ge-0/1/0.0 transmit-period 15

set protocols dot1x authenticator interface ge-0/1/0.0 mac-radius
set protocols dot1x authenticator interface ge-0/1/0.0 maximum-requests 2
set protocols dot1x authenticator interface ge-0/1/0.0 server-fail vlan-name
enterprise
set protocols dot1x authenticator interface ge-0/1/1.0 supplicant multiple
set protocols dot1x authenticator interface ge-0/1/1.0 quiet-period 5
set protocols dot1x authenticator interface ge-0/1/1.0 transmit-period 15
set protocols dot1x authenticator interface ge-0/1/1.0 mac-radius
set protocols dot1x authenticator interface ge-0/1/1.0 supplicant-timeout 15
set protocols dot1x authenticator interface ge-0/1/1.0 maximum-requests 2
set protocols dot1x authenticator interface ge-0/1/1.0 guest-vlan guest
set protocols dot1x authenticator interface ge-0/1/1.0 server-reject-vlan vlan-name
guest
set protocols dot1x authenticator interface ge-0/1/1.0 server-fail vlan-name
enterprise
The following example shows commands that configure the access profile for the Pulse
Policy Secure RADIUS server and the RADIUS client connection to it:
set access radius-server 10.0.1.5 port 1812

set access radius-server 10.0.1.5 secret "$9$JLZHmzF/t0I69Icrv7N24aZikmfT3/C"
set access radius-server 10.0.1.5 timeout 5
set access radius-server 10.0.1.5 retry 3
set access profile juniper-access-profile authentication-order radius
set access profile juniper-access-profile radius authentication-server 10.0.1.5
set access profile juniper-access-profile radius accounting-server 10.0.1.5
set access profile juniper-access-profile accounting order radius
The following example shows commands that configure the Ethernet switching options
and VLAN used for VoIP phones:
set ethernet-switching-options voip interface ge-0/0/10.0 vlan VoIP_Phone

set vlans VoIP_Phone description "VoIP Phones"
set vlans VoIP_Phone vlan-id 5
The following example shows the complete configuration hierarchy for the Ethernet
switch configuration:
system {
host-name Demo_EX;
root-authentication {
encrypted-password "$1$OOuTCh1K$/Z6JTJ/I9BnjTsKAoefLS."; ## SECRET-DATA
}
login {
user admin {
full-name Administrator;
uid 2000;
class super-user;
authentication {
encrypted-password "$1$RKLp.iDP$m//eueOcF.rExsnQXuZNb/"; ##
SECRET-DATA
}

}
}
services {
ssh;
telnet;
web-management {
http;
}
}
syslog {
user * {
any emergency;
}
file messages {
any notice;
authorization info;
}
}
}
chassis {
alarm {
management-ethernet {
link-down ignore;
}
}
}
interfaces {
ge-0/0/0 {
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members [ enterprise guest remediation VoIP_Phone ];
}
native-vlan-id default;
}
}
}
ge-0/0/1 {
unit 0 {
port-mode trunk;
vlan {
}
}
}
}
ge-0/0/2 {
unit 0 {
port-mode trunk;
vlan {
}

}
}
}
ge-0/0/3 {
unit 0 {
port-mode trunk;
vlan {
}
}
}
}
ge-0/0/4 {
unit 0 {
port-mode access;
}
}
}
ge-0/0/5 {
unit 0 {
port-mode access;
}
}
}
ge-0/0/6 {
unit 0 {
port-mode access;
}
}
}
ge-0/0/7 {
unit 0 {
port-mode access;
}
}
}
ge-0/0/8 {
unit 0 {
port-mode access;
}
}
}
ge-0/0/9 {
unit 0 {
port-mode access;
}
}

}
ge-0/0/10 {
unit 0 {
port-mode access;
}
}
}
ge-0/0/11 {
unit 0 {
port-mode access;
}
}
}
ge-0/1/0 {
unit 0 {
port-mode access;
}
}
}
ge-0/1/1 {
unit 0 {
port-mode access;
}
}
}
vlan {
unit 0 {
family inet {
address 10.0.1.10/24;
}
}
}
}
routing-options {
static {
route 0.0.0.0/0 next-hop 10.0.1.1;
}
}
protocols {
dot1x {
authenticator {
authentication-profile-name juniper-access-profile;
interface {
ge-0/1/0.0 {
supplicant multiple;
transmit-period 15;
mac-radius;
maximum-requests 2;
server-fail vlan-name enterprise;
}
ge-0/1/1.0 {
supplicant multiple;

quiet-period 5;
transmit-period 15;
mac-radius;
supplicant-timeout 15;
maximum-requests 2;
guest-vlan guest;
server-reject-vlan guest;
server-fail vlan-name enterprise;
}
}
}
}
}
access {
radius-server {
10.0.1.5 {
port 1812;
secret "$9$JLZHmzF/t0I69Icrv7N24aZikmfT3/C"; ## SECRET-DATA
timeout 5;
retry 3;
}
}
profile juniper-access-profile {
authentication-order radius;
radius {
authentication-server 10.0.1.5;
accounting-server 10.0.1.5;
}
accounting {
order radius;
}
}
}
ethernet-switching-options {
voip {
interface ge-0/0/10.0 {
vlan VoIP_Phone;
}
vlan VoIP_Phone;
}
vlan VoIP_Phone;
}
vlan VoIP_Phone;
}
vlan VoIP_Phone;
}
vlan VoIP_Phone;
}
vlan VoIP_Phone;
}

vlan VoIP_Phone;
}
vlan VoIP_Phone;
}
vlan VoIP_Phone;
}
}
}
vlans {
VoIP_Phone {
vlan-id 5;
}
default {
vlan-id 1;
interface {
ge-0/0/4.0;
ge-0/0/5.0;
}
l3-interface vlan.0;
}
enterprise {
vlan-id 2;
interface {
inactive: ge-0/0/5.0;
ge-0/0/6.0;
ge-0/0/7.0;
ge-0/1/0.0;
ge-0/1/1.0;
}
}
guest {
vlan-id 3;
interface {
ge-0/0/8.0;
ge-0/0/9.0;
}
}
remediation {
vlan-id 4;
interface {
ge-0/0/10.0;
ge-0/0/11.0;
}
}
}
poe {
interface all;
}
In addition to the configuration for the MAC authentication solution shown above, you
can also configure the switch to send data (SNMP traps) to the Beacon Endpoint Profiler
for use in profiling. The following example commands configure SNMP traps to the

Beacon Endpoint Profiler. The Beacon Endpoint Profiler can use the traps to build profile
entries:
set snmp description EX4200-VOIP-Switch

set snmp contact ex-admin@company.com
set snmp view jweb-view-all oid .1 include
set snmp community public view jweb-view-all
set snmp community public authorization read-only
set snmp community public clients <BeaconEndpointProfilerIPaddressOrSubnet>
set snmp trap-group Beacon version v2
set snmp trap-group Beacon categories link
set snmp trap-group Beacon targets <BeaconEndpointProfilerIPaddress>
TIP: To verify that the Beacon Endpoint Profiler can read the EX Series MIB,
run the following command from the Beacon Endpoint Profiler command
line:
snmpwalk -v 2c -c public <EXseriesIPaddress>
Related Great Bay Software Beacon Endpoint Profiler Configuration Guide

Documentation
 Juniper Networks Documentation Notes for Great Bay Software Beacon Endpoint Profiler

on MAG-SM360-PROFILER
 Pulse Secure Gateway Hardware
 Access Control on EX Series Switches
 RADIUS Server
 Access Management Framework
Using an NIS Server
This topic describes integration with the NIS server. It includes the following information:
 NIS Server Overview on page 367

 Configuring Authentication with an NIS Server on page 368
NIS Server Overview

Secure with the NIS server. It includes the following sections:
 Understanding NIS Server on page 367

Understanding NIS Server
Network Information Service (NIS) is an authentication server that allows a central server
to manage password authentication, hosts, services, and so on.

When you use an NIS server as the authentication and authorization service for your Pulse
Policy Secure access management framework, users can sign in to the Pulse Policy
Secure and Pulse Connect Secure using the same username and password that is
used for the NIS server.
Feature Support
Pulse Policy Secure access management framework supports the following NIS server
features:
 Password management feature enables users who access an NIS server to manage
their policies defined on the NIS server.
 Integrates NIS map data for passwords, groups, and hosts with corresponding objects
in Active Directory.
 Allows migration of NIS domains to Active Directory.
The following limitations apply when defining and monitoring an NIS server instance:
 You can only use NIS authentication with the system if your passwords are stored on
the NIS server using Crypt or MD5 formats.
 You can only add one NIS server configuration to the system, but you can use that
configuration to authenticate any number of realms.
 The username submitted to the system cannot contain two consecutive tilde symbols
(~~).
Configuring Authentication with an NIS Server

To configure authentication with the NIS server:
2. Select NIS Server and click New Server to display the configuration page.
Figure 80 on page 369 shows the configuration page for Pulse Policy Secure. Figure
81 on page 370 shows the configuration page for Pulse Connect Secure.

Figure 80: NIS Server Configuration Page – Pulse Policy Secure

Figure 81: NIS Server Configuration Page – Pulse Connect Secure
Table 39: NIS Server Settings
Settings Guidelines
NIS Server Specify the name or IP address of the NIS server.
NIS Domain Specify the domain name for the NIS server.

Synchronization


Figure 82 on page 371 shows the Users page for Pulse Policy Secure. The Users page
for Pulse Connect Secure is similar.
click Update.

Documentation


Using a RADIUS Server
This topic describes integration with the RADIUS server. It includes the following
information:
 RADIUS Server Overview on page 372

 Configuring Authentication with a RADIUS Server on page 383
RADIUS Server Overview

This section describes support for using an external RADIUS server. It includes the
following sections:
 Understanding RADIUS Server on page 372

 Using Challenge Expressions on page 373
 Using RADIUS Attributes on page 373
 Understanding RADIUS Accounting on page 380
Understanding RADIUS Server
A Remote Authentication Dial-In User Service (RADIUS) server is a type of server that
allows you to centralize authentication and accounting for users.
The following authentication schemes are supported:
 Access-Request–The user enters the username and password to request access to

RADIUS server.
 Access-Accept–The user is authenticated.
 Access-Reject–The user is not authenticated and is prompted to reenter the username

and password, or access is denied.
 Access-Challenge–A challenge is issued by the RADIUS server. The challenge collects

additional data from the user.
Feature Support
Pulse Policy Secure access management framework supports the following RADIUS
features:
 RADIUS authentication.
 RADIUS attributes that can be used in role mapping.
 RADIUS directory services to retrieve user attributes in role-mapping rules.

 RADIUS accounting to track the services and the network resources used.
 RADIUS proxy to configure your external RADIUS server as an inner or outer proxy
target. When you specify RADIUS proxy, some fields in the RADIUS server configuration
page are not applicable. This feature is supported only on Pulse Policy Secure.
Using Challenge Expressions
The Pulse Policy Secure access management framework supports the RSA
Authentication Manager using the RADIUS protocol and a SecurID token (available
from Security Dynamics). If you use SecurID to authenticate users, they must supply a
user ID and the concatenation of a PIN and a token value.
When you define a RADIUS server, the Pulse Policy Secure access management
framework allows administrators to use hard-coded (default) challenge expressions
that support Defender 4.0 and some RADIUS server implementations (such as Steel-
Belted RADIUS and RSA RADIUS) or to enter custom challenge expressions that allow
the system to work with many different RADIUS implementations and new versions of
the RADIUS server, such as Defender 5.0. The system looks for the response in the
Access-Challenge packet from the server and issues an appropriate Next Token, New
PIN, or Generic Passcode challenge to the user.
Using CASQUE Authentication
CASQUE authentication uses a token-based challenge/response authentication

mechanism employing a CASQUE player installed on the client system. Once configured
with CASQUE authentication, the RADIUS server issues a challenge with a response
matching the custom challenge expression (:([0-9a-zA-Z/+=]+):). The system then
generates an intermediate page that automatically launches the CASQUE player installed
on the user’s system.
PassGo Defender
If you are using a PassGo Defender RADIUS server, the user sign-in process is as follows:
1. The user is prompted for and enters a username and password.
2. The username and encrypted password are sent over the network to the RADIUS
server.
3. The RADIUS server sends a unique challenge string to the system. The system displays
this challenge string to the user.
4. The user enters the challenge string in a Defender token and the token generates a
response string.
5. The user enters the response string on the system and clicks Sign In.
Using RADIUS Attributes
Table 40 on page 374 describes the RADIUS attributes that are supported in RADIUS
role-mapping.

Table 40: RADIUS Attributes
Attribute Description
ARAP-Challenge-Response Contains the response to the challenge of a dial-in client. Sent in an Access-Accept packet
with Framed-Protocol of ARAP.
ARAP-Features Includes password information that the network access server (NAS) must send to the
user in an ARAP feature flags packet. Sent in an Access-Accept packet with Framed-
Protocol of ARAP.
ARAP-Password Appears in an Access-Request packet containing a Framed-Protocol of ARAP. Only one of

User-Password, CHAP-Password, or ARAP-Password must be included in an
Access-Request, or one or more EAP-Messages.
ARAP-Security Identifies the ARAP security module to be used in an Access-Challenge packet.
ARAP-Security-Data Contains the actual security module challenge or response, and is in Access-Challenge and
Access-Request packets.
ARAP-Zone-Access Indicates how to use the ARAP zone list for the user.
Access-Accept Provides specific configuration information necessary to begin delivery of service to the
user.
Access-Challenge Sends the user a challenge requiring a response, and the RADIUS server must respond to
the Access-Request by transmitting a packet with the Code field set to 11
(Access-Challenge).
Access-Reject Transmits a packet with the Code field set to 3 (Access-Reject) if any value of the received
Attributes is not acceptable.
Access-Request Conveys information specifying user access to a specific NAS, and any special services
requested for that user.
Accounting-Request Conveys information used to provide accounting for a service provided to a user.
Accounting-Response Acknowledges that the Accounting-Request has been received and recorded successfully.
Acct-Authentic Indicates how the user was authenticated, whether by RADIUS, the NAS itself, or another
remote authentication protocol.
Acct-Delay-Time Indicates how many seconds the client has been trying to send this record.
Acct-Input-Gigawords Indicates how many times the Acct-Input-Octets counter has wrapped around 2^32 over
the course of this service being provided.
Acct-Input-Octets Indicates how many octets have been received from the port during the current session.
Acct-Input-Packets Indicates how many packets have been received from the port during the session provided
to a Framed User.
Acct-Interim-Interval Indicates the number of seconds between each interim update in seconds for this specific
session.

Table 40: RADIUS Attributes (continued)
Acct-Link-Count Indicates the count of links known to have been in a given multilink session at the time the
accounting record is generated.
Acct-Multi-Session-Id Indicates a unique Accounting ID to make it easy to link together multiple related sessions
in a log file.
Acct-Output-Gigawords Indicates how many times the Acct-Output-Octets counter has wrapped around 2^32
during the current session.
Acct-Output-Octets Indicates how many octets have been sent to the port during this session.
Acct-Output-Packets Indicates how many packets have been sent to the port during this session to a Framed
User.
Acct-Session-Id Indicates a unique Accounting ID to make it easy to match start and stop records in a log
file.
Acct-Session-Time Indicates how many seconds the user has received service.
Acct-Status-Type Indicates whether this Accounting-Request marks the beginning of the user service (Start)
or the end (Stop).
Acct-Terminate-Cause Indicates how the session was terminated.
Acct-Tunnel-Connection Indicates the identifier assigned to the tunnel session.
Acct-Tunnel-Packets-Lost Indicates the number of packets lost on a given link.
CHAP-Challenge Contains the Challenge Handshake Authentication Protocol (CHAP) challenge sent by the
NAS to a PPP CHAP user.
CHAP-Password Indicates the response value provided by a PPP CHAP user in response to the challenge.
Callback-Id Indicates the name of a location to be called, to be interpreted by the NAS.
Callback-Number The dialing string to be used for callback.
Called-Station-Id Allows the NAS to send the phone number that the user called, using Dialed Number
Identification Service (DNIS) or similar technology.
Calling-Station-Id Allows the NAS to send the phone number that the call came from, using Automatic Number
Identification (ANI) or similar technology.
Class Sent by the server to the client in an Access-Accept and then sent unmodified by the client
to the accounting server as part of the Accounting-Request packet, if accounting is
supported.
Configuration-Token Used in large distributed authentication networks based on proxy.

Connect-Info Sent from the NAS to indicate the nature of the user's connection.
EAP-Message Encapsulates Extended Access Protocol [3] packets to allow the NAS to authenticate
dial-in users by means of EAP without having to understand the EAP protocol.
Event-Timestamp Records the time that this event occurred on the NAS, in seconds since January 1, 1970
00:00 UTC.
Filter-Id Indicates the name of the filter list for this user.
Framed-AppleTalk-Link Indicates the AppleTalk network number used for the serial link to the user, which is another
AppleTalk router.
Framed-AppleTalk-Network Indicates the AppleTalk Network number which the NAS can probe to allocate an AppleTalk
node for the user.
Framed-AppleTalk-Zone Indicates the AppleTalk Default Zone to be used for this user.
Framed-Compression Indicates the compression protocol to be used for the link.
Framed-IP-Address Indicates the address to be configured for the user.
Framed-IP-Netmask Indicates the IP netmask to be configured for the user when the user is a router to a network.
Framed-IPv6-Pool Contains the name of an assigned pool used to assign an IPv6 prefix for the user.
Framed-IPv6-Prefix Indicates an IPv6 prefix (and corresponding route) to be configured for the user.
Framed-IPv6-Route Indicates the routing information to be configured for the user on the NAS.
Framed-Interface-Id Indicates the IPv6 interface identifier to be configured for the user.
Framed-IPX-Network Indicates the IPX Network number to be configured for the user.
Framed-MTU Indicates the maximum transmission unit to be configured for the user, when it is not
negotiated by some other means (such as PPP).
Framed-Pool Indicates the name of an assigned address pool used to assign an address for the user.
Framed-Protocol Indicates the framing to be used for framed access.
Framed-Route Indicates the routing information to be configured for the user on the NAS.
Framed-Routing Indicates the routing method for the user, when the user is a router to a network.
Idle-Timeout Sets the maximum number of consecutive seconds of idle connection allowed to the user
before termination of the session or prompt.

Keep-Alives Uses SNMP instead of keepalives.
Login-IP-Host Indicates the system with which to connect the user when the Login-Service Attribute is
included.
Login-IPv6-Host Indicates the system with which to connect the user when the Login-Service Attribute is
included.
Login-LAT-Group Contains a string identifying the LAT group codes that this user is authorized to use.
Login-LAT-Node Indicates the node with which the user is to be automatically connected by LAT.
Login-LAT-Port Indicates the port with which the user is to be connected by LAT.
Login-LAT-Service Indicates the system with which the user is to be connected by LAT.
Login-Service Indicates the service to use to connect the user to the login host.
Login-TCP-Port Indicates the TCP port with which the user is to be connected when the Login-Service
Attribute is also present.
MS-ARAP-Challenge Only present in an Access-Request packet containing a Framed-Protocol Attribute with

the value 3 (ARAP).
MS-ARAP-Password-Change-Reason Indicates the reason for a server-initiated password change.
MS-Acct-Auth-Type Represents the method used to authenticate the dial-up user.
MS-Acct-EAP-Type Represents the Extensible Authentication Protocol (EAP) type used to authenticate the
dial-up user.
MS-BAP-Usage Describes whether the use of BAP is allowed, disallowed, or required on new multilink calls.
MS-CHAP-CPW-1 Allows the user to change password if it has expired.
MS-CHAP-CPW-2 Allows the user to change password if it has expired.
MS-CHAP-Challenge Contains the challenge sent by a NAS to a MS-CHAP user.
MS-CHAP-Domain Indicates the Windows NT domain in which the user was authenticated.
MS-CHAP-Error Contains error data related to the preceding MS-CHAP exchange.
MS-CHAP-LM-Enc-PW Contains the new Windows NT password encrypted with the old LAN Manager password
hash.
MS-CHAP-MPPE-Keys Contains two session keys for use by the Microsoft Point-to-Point Encryption (MPPE).

MS-CHAP-NT-Enc-PW Contains the new Windows NT password encrypted with the old Windows NT password
hash.
MS-CHAP-Response Contains the response value provided by a PPP MS-CHAP user in response to the challenge.
MS-CHAP2-CPW Allows the user to change password if it has expired.
MS-CHAP2-Response Contains the response value provided by an MS- CHAP-V2 peer in response to the challenge.
MS-CHAP2-Success Contains a 42-octet authenticator response string.
MS-Filter Transmits traffic filters.
MS-Link-Drop-Time-Limit Indicates the length of time (in seconds) that a link must be underutilized before it is
dropped.
MS-Link-Utilization-Threshold Represents the percentage of available bandwidth utilization below which the link must
fall before the link is eligible for termination.
MS-MPPE-Encryption-Policy Signifies whether the use of encryption is allowed or required.
MS-MPPE-Encryption-Types Signifies the types of encryption available for use with MPPE.
MS-MPPE-Recv-Key Contains a session key for use by the MPPE.
MS-MPPE-Send-Key Contains a session key for use by the MPPE.
MS-New-ARAP-Password Transmits the new ARAP password during an ARAP password change operation.
MS-Old-ARAP-Password Transmits the old ARAP password during an ARAP password change operation.
MS-Primary-DNS-Server Indicates the address of the primary domain name server (DNS) server to be used by the
PPP peer.
MS-Primary-NBNS-Server Indicates the address of the primary NetBIOS name server (NBNS) server to be used by
the PPP peer.
MS-RAS-Vendor Indicates the manufacturer of the RADIUS client machine.
MS-RAS-Version Indicates the version of the RADIUS client software.
MS-Secondary-DNS-Server Indicates the address of the secondary DNS server to be used by the PPP peer.
MS-Secondary-NBNS-Server Indicates the address of the secondary DNS server to be used by the PPP peer.
Message-Authenticator Signs Access-Requests to prevent spoofing Access-Requests using CHAP, ARAP, or EAP
authentication methods.

NAS-IP-Address Indicates the identifying IP address of the NAS that is requesting authentication of the user,
and must be unique to the NAS within the scope of the RADIUS server.
NAS-IPv6-Address Indicates the identifying IPv6 Address of the NAS that is requesting authentication of the
user, and must be unique to the NAS within the scope of the RADIUS server.
NAS-Identifier Contains a string identifying the NAS originating the Access-Request.
NAS-Port Indicates the physical port number of the NAS that is authenticating the user.
NAS-Port-Id Contains a text string that identifies the port of the NAS that is authenticating the user.
NAS-Port-Type Indicates the type of the physical port of the NAS that is authenticating the user.
Password-Retry Indicates how many authentication attempts a user is allowed to attempt before being
disconnected.
Port-Limit Sets the maximum number of ports to be provided to the user by the NAS.
Prompt Indicates to the NAS whether it should echo the user's response as it is entered, or not echo
it.
Proxy-State Indicates that a proxy server can send this attribute to another server when forwarding an
Access-Request. The attribute must be returned unmodified in the Access-Accept,
Access-Reject or Access-Challenge.
Reply-Message Indicates that the text that can be displayed to the user.
Service-Type Indicates the type of service the user has requested, or the type of service to be provided.
Session-Timeout Sets the maximum number of seconds of service to be provided to the user before
termination of the session or prompt.
State Indicates that the packet must have only zero or one State Attribute. Usage of the State
Attribute is implementation dependent.
Telephone-number Using the Calling-Station-Id and Called-Station-Id RADIUS attributes, authorization and
subsequent tunnel attributes can be based on the phone number originating the call, or
the number being called.
Termination-Action Indicates the action the NAS should take when the specified service is completed.
Tunnel-Assignment-ID Indicates to the tunnel initiator the particular tunnel to which a session is to be assigned.
Tunnel-Client-Auth-ID Specifies the name used by the tunnel initiator during the authentication phase of tunnel
establishment.
Tunnel-Client-Endpoint Contains the address of the initiator end of the tunnel.

Tunnel-Link-Reject Indicates the rejection of the establishment of a new link in an existing tunnel.
Tunnel-Link-Start Marks the creation of a tunnel link.
Tunnel-Link-Stop Marks the destruction of a tunnel link.
Tunnel-Medium-Type Indicates the transport medium to use when creating a tunnel for those protocols (such
as L2TP) that can operate over multiple transports.
Tunnel-Medium-Type Indicates the transport medium to use when creating a tunnel for those protocols (such
as L2TP) that can operate over multiple transports.
Tunnel-Password Specifies a password used to access a remote server.
Tunnel-Preference Indicates that if RADIUS server returns more than one set of tunneling attributes to the
tunnel initiator, you should include this attribute in each set to indicate the relative preference
assigned to each tunnel.
Tunnel-Private-Group-ID Indicates the group ID for a particular tunneled session.
Tunnel-Reject Marks the rejection of the establishment of a tunnel with another node.
Tunnel-Server-Auth-ID Specifies the name used by the tunnel terminator during the authentication phase of tunnel
establishment.
Tunnel-Server-Endpoint Indicates the address of the server end of the tunnel.
Tunnel-Start Marks the establishment of a tunnel with another node.
Tunnel-Stop Marks the destruction of a tunnel to or from another node.
Tunnel-Type Indicates the tunneling protocol(s) to be used (in the case of a tunnel initiator) or the
tunneling protocol in use (in the case of a tunnel terminator).
User-Name Indicates the name of the user to be authenticated.
User-Password Indicates the password of the user to be authenticated, or the user's input following an
Access-Challenge.
Vendor-Specific Allows vendors to support their own extended attributes not suitable for general usage.
Understanding RADIUS Accounting
You can configure the device to send session start and stop messages to a RADIUS
accounting server. The device sends a user-session start message after the user
successfully signs in and the device maps to a role.

Whenever a user session is terminated, the device sends a user-session stop message
to the accounting server. A user session is terminated whenever the user:
 Manually signs out
 Times out because of either inactivity or exceeding the maximum session length
 Is denied access because of Host Checker role-level restrictions
 Is manually forced out by an administrator as a result of dynamic policy evaluation
NOTE: If users are signed into a device cluster, the RADIUS accounting
messages might show the users signing in to one node and signing out of
another.
Table 41 on page 381 describes the attributes that are common to start and stop messages.
Table 42 on page 382 describes the attributes that are unique to start messages.
Table 43 on page 382 describes the attributes that are unique to stop messages.
Table 41: Attributes Common to Start and Stop Messages
User-Name (1) Specifies the string that the device administrator specifies during RADIUS server configuration.
NAS-IP-Address (4) Specifies the device’s IP address.
NAS-Port (5) The device sets this attribute to 0 if the user signed in using an internal port, or 1 if an external port
is used.
Framed-IP-Address (8) Specifies the user’s source IP address.
NAS-Identifier (32) Specifies the configured name for the device client under the RADIUS server configuration.
Acct-Status-Type (40) The device sets this attribute to 1 for a start message, or 2 for a stop message in a user-session or
a subsession.
Acct-Session-Id (44) Specifies the unique accounting ID that matches start and stop messages corresponding to a
user-session or to a subsession.
Acct-Multi-Session-Id Specifies the unique accounting ID that you can use to link together multiple related sessions. Each
(50) linked session must have a unique Acct-Session-Id and the same Acct-Multi-Session-Id.
Acct-Link-Count (51) Specifies the count of links in a multilink session at the time the Policy Secure gateway generates
the accounting record.

Table 42: Start Attributes
Acct-Authentic (45) The device sets this attribute to:
 RADIUS—if the user is authenticated to a RADIUS server.

 Local—if the user is authenticated to a local authentication server.
 Remote—if the user is authenticated through any other RADIUS server.
Table 43: Stop Attributes
Acct-Session-Time (46) Specifies the duration of the user-session or the subsession.
Acct-Terminate-Cause The device uses one of the following values to specify the event that caused the termination of a
(49) user session or a subsession:
 User Request (1) – User manually signs out.

 Idle Timeout (4) – User is Idle and times out.
 Session Timeout (5) – User’s maximum session times out.
 Admin Reset (6) – User is forced out from active users page.
You must configure the third-party RADIUS server to communicate with the Pulse
Policy Secure access management framework.
On the RADIUS server, configure the following settings:
 Host name.
 Network IP address.
 Client type, if applicable. If this option is available, select Single Transaction Server or
its equivalent.
 Type of encryption for authenticating client communication. This choice should

correspond to the client type.
 Shared secret.
The following are the requirements and limitations for Interim update feature:
 If you want a server to receive interim accounting messages, you can statically configure
an interim value on the client, in which case, the locally configured value overrides any
value that might be included in the RADIUS Access-Accept message.
 The octet count reported in the accounting messages is the cumulative total since the
beginning of the user session.
 The interim update byte count is only supported based on a user session, not on SAM
or NC sessions.

Configuring Authentication with a RADIUS Server

To configure authentication with the RADIUS server:
2. Select RADIUS Server and click New Server to display the configuration page.

Figure 83: RADIUS Server Configuration Page – Pulse Policy Secure

Figure 84: RADIUS Server Configuration Page – Pulse Connect Secure

Table 44: RADIUS Server Settings
Settings Guidelines
NAS-Identifier Specify the name that identifies the Network Access Server (NAS) client to the RADIUS server.
NOTE:
 If you do not specify the NAS identifier, the value specified in the Hostname field on the System
> Network > Overview page of the administrator console is used.
 If you use the RADIUS proxy feature, the NAS-Identifier field is not used. Proxy passes on the
entire RADIUS packet including the NAS identifier from the client.
Primary Server
Radius Server Specify the name or IP address of the RADIUS server.
Authentication Port Specify the authentication port value for the RADIUS server.
Default port number: 1812, 1645 (legacy servers)
NAS-IP-Address Specify the NAS IP address.
NOTE:
 If you leave this field empty, the internal IP address is passed to RADIUS requests.
 If you configure the NAS IP address, then the system passes the value regardless of which cluster
node sends the requests.
 If you use the RADIUS proxy feature, this field is not used.
Proxy passes on the entire RADIUS packet including the NAS IP address from the client.
Timeout (seconds) Specify the interval of time to wait for a response from the RADIUS server before timing out the
connection.
Retries Specify the number of times to try to make a connection after the first attempt fails.
Users authenticate using Select this option to prompt the user for a token instead of a password.
tokens or one-time
passwords. For example, you can use this option to dynamically prompt for a password or token based on
sign-in policies by configuring two instances of the same authentication server. You can use one
instance for wireless users with this option enabled and that prompts the user for a token, and
another instance for wired users with this option disabled and that prompts the user for a password.
NOTE: If you are using RADIUS proxy feature, this option is not used.
Backup Server (required only if Backup server exists)

Table 44: RADIUS Server Settings (continued)
Settings Guidelines
Radius Server Specify the secondary RADIUS server.
The authentication request is first routed to the primary RADIUS server, then to the specified backup
server if the primary server is unreachable.
Accounting messages are sent to the RADIUS server by each cluster node without consolidation.
RADIUS accounting follows these assumptions:
 If the cluster is active/passive, all users are connected to one node at a time.
 If the cluster is active/active and does not use a balancer, users are connected to different nodes
but are static.
 If the cluster is active/active and uses a balancer, the balancer usually enforces a persistent
source IP. In this case, users are always connected to the same node.
NOTE: RADIUS does not support load balancing.
Authentication Port Specify the authentication port.
Shared Secret Specify the shared secret.
Accounting Port Specify the accounting port.
Radius Accounting
User-Name Specify the user information to the RADIUS accounting server.
You can enter any of the applicable session variables. Applicable variables include those that are
set the time after the user signs in and maps to a role.
The default variables for this field are as follows:
 USER: Logs the username to the accounting server.

 REALM: Logs the realm to the accounting server.
 ROLE SEP=”,”: Logs the list of comma-separated roles assigned to the user.
 ROLE: Logs the role to the accounting server.
NOTE: If you assign the user to more than one role, the system separates them with commas.
Interim Update Interval Select this option to achieve more precise billing for long-lived session clients and during network
(minutes) failure.
NOTE:
 If you are using the RADIUS proxy feature, the fields in this section are not used.
 The minimum interim update interval is 15 minutes. The data statistics (bytes in and bytes out)
for RADIUS accounting might not be sent for a J-SAM/W-SAM/NC session if the session is less
than 30 seconds long and the applications keep the connections open all the time.

Settings Guidelines
Use NC assigned IP Select the Use NC assigned IP Address for FRAMED-IP-ADDRESS attribute value in Radius
Address for Accounting checkbox to use the IP address returned from the Pulse Connect Secure for the
FRAMED-IP-ADDRESS Framed-IP-Address attribute. Two IP addresses are recorded: one prior to authenticating with the
attribute value in Radius Pulse Connect Secure, and one returned by VPN Tunneling after authentication. Select this option
Accounting to use the VPN Tunneling IP address for the Framed-IP-Address attribute instead of the
pre-authenticated (original) IP address.
Custom challenge expressions

This feature is applicable for Pulse Policy Secure
(Optional) Three types of challenge expressions exist with each automatically set to its pre-populated default. The custom
option allows the administrator to configure the actual string pattern to match for any of the three modes. To add a custom
expression, select the check box for the appropriate challenge expression type, and add a custom expression in the associated
text box.
NOTE:
 If you use SecureID to authenticate users, then provide the user ID and the concatenation of PIN and the token value.
 When using CASQUE authentication, specify:([0-9a-zA-Z/+=]+): as the custom expression for the Generic Login Challenge
Expression.
 If you are using the RADIUS proxy feature, the fields in this section are not used.
Next Token Specify the appropriate Next Token.
New PIN Specify the New PIN.
Generic Login Specify the Generic Login challenge to the user.
Custom Radius Rules

This feature is applicable for Pulse Connect Secure

Settings Guidelines
(Optional) Click New Radius Rule to add a custom challenge rule that determines the action to take for an incoming packet.
When a user enters his or her username and password, the initial authorization request is sent to the server. The server may
respond with a Challenge or Reject packet. In the Add Custom Radius Challenge Rule window, you select the packet type
(Challenge or Reject) and then specify what action to take. For example, you can show a login page with a specific error message
to the user, or automatically send an ACCESS-REQUEST packet back to the server.
To create a custom challenge rule:
1. Select the incoming packet type:

 Access Challenge—sent by the RADIUS server requesting more information in order to allow access
 Access Reject—sent by the RADIUS server rejecting access
2. Specify an expression to evaluate, based on the Radius attribute, and click Add. If you specify more than one expression,
the expressions are “ANDed” together. To remove an expression, click the delete icon next to the expression.
3. Choose the action to take by selecting one of the following radio buttons:
 show NEW PIN page—user must enter a new PIN for the token
 show NEXT TOKEN page—user must enter the next tokencode
 show GENERIC LOGIN page—display an additional page to the user in response to an Access Challenge sent by the server.
Sometimes a Radius server returns a Challenge packet and requires the user to enter additional information to continue
the login process. For example, a server receives the initial username and password and sends an SMS message to the
user’s mobile phone with a one-time password (OTP). The user enters the OTP in the generic login page.
 show user login page with error—display the standard login page with an embedded error message. This option lets you
bypass the standard message string sent by the Pulse Connect Secure and display a custom error message to the user.
Enter your custom message in the Error Message text box. There is no maximum character limit for this message.
 send ACCESS REQUEST with additional attributes—send an ACCESS-REQUEST packet with the specified attribute/value
pair(s). Select an attribute, enter its value and click Add. To delete an attribute, click the delete icon next to the
attribute/value pair.
You must set User-Password to <PASSWORD> otherwise an “Invalid username or password” message appears.
4. Click Save Changes to save your edits, then click Close to close this window.
Your custom rules appear in the table under the Custom Radius Authentication Rule section. To delete a rule, select the
checkbox next to the rule and click Delete.


click Update.

Documentation

Using an ACE Server
This topic describes integration with an ACE Server (now named RSA Authentication
Manager). It includes the following information:
 RSA Authentication Manager Overview on page 391

 Configuring Authentication with RSA Authentication Manager on page 393

RSA Authentication Manager Overview

Secure with an ACE Server (now named RSA Authentication Manager). It includes the
following sections:
 Understanding RSA Authentication Manager on page 391

Understanding RSA Authentication Manager
RSA Authentication Manager (formerly known as ACE/Server) is an authentication and

authorization server that allows user authentication based on credentials from the RSA
®
SecurID product from RSA Security Inc.
When you use RSA Authentication Manager as the authentication and authorization
service for your Pulse Policy Secure access management framework, users can sign in
to the Pulse Policy Secure and Pulse Connect Secure using the same username and
password stored in the backend server.
Table 45 on page 391 describes RSA SecurID hardware token and software token user
sign-in methods.
Table 45: Sign-in Methods
Method Action
Using a hardware token and The user browses to the standard system sign-in page, and then enters the username and
the standard system sign-in password (consisting of the concatenation of the PIN and the RSA SecurID hardware token’s
page current value). The system then forwards the user’s credentials to the authentication server.
Using a software token and The user browses to the SoftID custom sign-in page. Then, using the SoftID plug-in, the user
the custom SoftID system enters the username and PIN. The SoftID plug-in generates a passphrase by concatenating
sign-in page the user’s PIN and token and passes the passphrase to the authentication server. For information
about enabling the SoftID custom sign-in pages, see
http://www.juniper.net/techpubs/software/ive/admin/j-sa-sslvpn-7.0-customsigninpages.pdf.
If the RSA Authentication Manager positively authenticates the user, the user gains access
to the system. Otherwise, the RSA Authentication Manager:
 Denies the user access to the system.
 Prompts the user to generate a new PIN (New PIN mode) if the user is signing in to the
system for the first time. Users see different prompts depending on the method they
use to sign in.
If the user signs in using the SoftID plug-in, then the RSA prompts the user to create a
new pin; otherwise the Pulse Policy Secure and Pulse Connect Secure prompt the
user to create a new PIN.
 Prompts the user to enter the next token (Next Token mode) if the token entered by
the user is out of sync with the token expected by RSA Authentication Manager. Next

Token mode is transparent to users signing in using a SoftID token. The RSA SecurID
software passes the token through the system to RSA Authentication Manager without
user interaction.
 Redirects the user to the standard system sign-in page (SoftID only) if the user tries
to sign-in to the RSA SecurID Authentication page on a computer that does not have
the SecurID software installed.
Feature Support
Pulse Policy Secure access management framework supports the following RSA
Authentication Manager features:
 New PIN mode
 Next-token mode
 Data Encryption Standard (DES)/ Secure Dial-In (SDI) encryption
 Advanced Encryption Standard (AES) encryption
 Slave Authentication Manager support
 Name locking
 Clustering
The following limitations apply when defining and monitoring an RSA Authentication
Manager instance:
 You can only add one RSA Authentication Manager configuration to the system, but
you can use that configuration to authenticate any number of realms.
 You cannot customize the load balancing algorithm.
 When you enter the New PIN or Next Token mode, enter the required information within
three minutes. Otherwise, the system cancels the transaction and notifies the user to
reenter the credentials.
 The system can handle a maximum of 200 RSA Authentication Manager transactions
at any given time. A transaction only lasts as long as is required to authenticate against
the RSA Authentication Manager.
For example, when a user signs into the system, the RSA Authentication Manager
transaction is initiated when the user submits the request for authentication and ends
once the RSA Authentication Manager has finished processing the request. The user
may then keep his or her session open, even though the RSA Authentication Manager
transaction is closed.

Configuring Authentication with RSA Authentication Manager

To configure authentication with an ACE server:
2. Select ACE Server and click New Server to display the configuration page.
Figure 86: ACE Server Configuration Page – Pulse Policy Secure

Figure 87: ACE Server Configuration Page – Pulse Connect Secure
Table 46: ACE Server Settings
Settings Guidelines
ACE Port Specify the default port of the authentication server.
NOTE: If no port is specified in the sdconf.rec file, the default port is used.
Configuration File

Table 46: ACE Server Settings (continued)
Settings Guidelines
Current config file Specify the RSA Authentication Manager configuration file.
NOTE: You must update this file on the device anytime you make changes to the source file.
Imported on Display the date on which the config file is imported.
Import new config file Use the Choose File button to upload the sdconf.rec configuration file.
Node Verification File

Node Save the configuration to redisplay the configuration page. The updated page includes a section
that lists a timestamp for the negotiation of the node secret between the system and the backend
RSA server. The negotiation and verification automatically occurs after first successful login. Do
not expect entries in the table until at least one user has authenticated successfully.

Synchronization

click Update.


Documentation
 How to: Secure Access Service: Implementing Authentication with RSA SecurID

 KB: Troubleshooting Error AD-37 while importing RSA sdconf.rec
 KB: Seamless authentication integration with RSA SecurID
Using a SiteMinder Server
This topic describes integration with the SiteMinder server. It includes the following
information:
 SiteMinder Server Overview on page 396

 Configuring the Back-End SiteMinder Server on page 399
 Configuring Authentication with a SiteMinder Server on page 403
SiteMinder Server Overview

Secure with the SiteMinder server. It includes the following sections:
 Understanding SiteMinder Server on page 396

Understanding SiteMinder Server
CA SiteMinder server is an authentication and authorization server.

When you configure the Pulse Policy Secure access management framework to
authenticate users with a SiteMinder policy server, the system passes the user’s
credentials to SiteMinder during authentication. Once SiteMinder receives the
credentials, it may use standard username and password authentication, RSA
Authentication Manager SecurID tokens, or client-side certificates to authenticate the
credentials.
The system also passes a protected resource URL to SiteMinder during authentication
to determine which SiteMinder realm it should use to authenticate the user. When the
system passes the protected resource URL, SiteMinder authorizes the user’s URL against
the realm that is associated with the resource and allows the user to seamlessly access
any resources whose protection levels are equal to or less than the URL that was passed.
Feature Support
The Pulse Policy Secure access management framework supports the following
SiteMinder features:
 Single Sign-on Using SMSESSION Cookies on page 397

 Automatic Sign-In on page 397
 Authentication Schemes on page 398
Single Sign-on Using SMSESSION Cookies
The Pulse Policy Secure access management framework enables single sign-on (SSO)
to SiteMinder-protected resources using SMSESSION cookies. An SMSESSION cookie
is a security token that encapsulates SiteMinder session information. Depending on
your configuration, either the SiteMinder Web agent or the system creates an
SMSESSION cookie and then posts the cookie to the following locations so the user
does not have to reauthenticate to access additional resources.
 Pulse Policy Secure access management framework-If the user tries to access a
SiteMinder resource within the session (for example, from the system file browsing
page), the system passes its cached SMSESSION cookie to the Web agent for
authentication.
 The user’s Web browser-If the user tries to access a SiteMinder resource from outside
the session (for example, when using a protected resource on a standard agent),
SiteMinder uses the cached SMSESSION cookie stored in the user’s Web browser to
authenticate/authorize the user.
Automatic Sign-In
If you enable the Automatic Sign-In option, the system can use an SMSESSION cookie
generated by another agent to enable single sign-on from a SiteMinder resource. When
a user accesses the system sign-in page with an SMSESSION cookie, the system verifies
the SMSESSION cookie. Upon successful verification, the system establishes a session
for the user. You can use the following authentication mechanisms when you enable
automatic sign-in through the system:
 Custom agent-The system authenticates the user against the policy server and
generates a SMSESSION cookie. When you select this option, you can enable SSO on
other SiteMinder agents that use the same policy server. To enable SSO on these
agents, update each of them to accept third-party cookies. If you select this option

and the user enters his system session with an SMSESSION cookie, the system attempts
automatic sign-in when the user enters the session.
 HTML form post-The system posts credentials to a standard Web agent that you have
already configured. The Web agent then creates SMSESSION cookies. If you select
this option, you cannot use SecurID New Pin and Next Token modes or client-side
certificate authentication. If you select this option and the user enters his session with
an SMSESSION cookie, the system attempts automatic sign-in when the user enters
the session.
 Delegated authentication-The system delegates authentication to a standard agent.

If this option is enabled, the system tries to determine the FCC URL associated with
the protected resource. The system then redirects the user to the FCC URL with the
system sign-in URL as the target. Upon successful authentication, the user is redirected
back to the system with an SMSESSION cookie and the system does an automatic
sign-in for the user.
Authentication Schemes
The Pulse Policy Secure access management framework works with the following
types of SiteMinder authentication schemes:
 Basic username and password authentication—The user’s name and password are
passed to the SiteMinder policy server. The policy server authenticates them to another
server for authentication.
 RSA Authentication Manager SecurID token authentication—The SiteMinder policy

server authenticates users based on a username and password generated by an RSA
Authentication Manager SecurID token.
 Client-side certificate authentication—The SiteMinder policy server authenticates users

based on their client-side certificate credentials. If you choose this authentication
method, the Web browser displays a list of client certificates from which users can
select. If you choose to authenticate users with this method, you must import the client
certificate through the System > Certificates > Trusted Client CAs tab.
The following requirements and limitations apply:
 The Automatic Sign-in feature is not supported for administrator roles. This feature is
only available for end users.
 If you use the Authenticate using custom agent option, update all other Web agents
to accept the device generated cookie, and apply a software patch to all other Web
agents.
 Pulse Policy Secure supports SiteMinder server version 6.0, version 5.5, and version
12.0. If you run older agents than the supported agents, you might experience cookie
validation problems, including crossed log entries and intermittent user timeouts.
 You can choose which SiteMinder server version you want to support when you create
a server instance. You can choose version 5.5, which supports both versions 5.5 and
6.0, or you can choose version 6.0, which supports only version 6.0, or version 12.0.

There is no difference in the SiteMinder authentication server functionality based on

which version you select. This option only controls the version of the SDK to use. We
recommend you match the compatibility mode with the version of the policy server.
 When you use SiteMinder to authenticate, the primary and backup policy servers must
run the same SiteMinder server software version. A mixed deployment (where the
primary server runs a different server software version than the backup) is not supported.
 SiteMinder does not store the IP address in the SMSESSION cookie, and therefore
cannot pass it to the system.
 SiteMinder sends the SMSESSION cookie to the system as a persistent cookie. To

maximize security, the system resets the persistent cookie as a session cookie once
authentication is complete.
 When you use SiteMinder to authenticate, the Pulse Policy Secure access
management framework disregards any system session and idle timeouts and uses
session and idle timeouts set through the SiteMinder realm instead.
 When you use SiteMinder to authenticate, users must access the system using a fully
qualified domain name. This is because the SiteMinder SMSESSION cookie is only sent
for the domain for which it is configured. If users access the system using an IP address,
they might receive an authentication failure and will be prompted to authenticate
again.
 You can update all of your standard Web agents to the appropriate Siteminder Agent
Quarterly Maintenance Release (QMR) to accept the cookies. If you are running
SiteMinder version 5 Web agents, use the QMR5 hot fix. The system is compatible with
version 5.x and later SiteMinder agents. Older versions of SiteMinder agents are
susceptible to cookie validation failures.
 You can set the Accept Third Party Cookie attribute (AcceptTPCookie) to yes in the
Web agent’s configuration file (webagent.conf) or to 1 in the Windows Registry for the
IIS Web server. The location of the attribute depends on the SiteMinder version and
Web server you are using. Refer to the documentation provided with your SiteMinder
server.
Configuring the Back-End SiteMinder Server

The following sections do not give complete SiteMinder configuration instructions—they
are only intended to help you make SiteMinder work with the Pulse Policy Secure
access management framework. For in-depth SiteMinder configuration information,
refer to the documentation provided with your SiteMinder policy server.
 Configuring the SiteMinder Agent on page 400

 Configuring the Authentication Scheme on page 400
 Configuring the SiteMinder Domain on page 402
 Configuring the SiteMinder Realm on page 402
 Configuring a Rule or Response Pair to Pass Usernames on page 402

Configuring the SiteMinder Agent
A SiteMinder agent filters user requests to enforce access controls. For instance, when
a user requests a protected resource, the agent prompts the user for credentials based
on an authentication scheme and sends the credentials to a SiteMinder policy server. A
Web agent is simply an agent that works with a Web server. When configuring SiteMinder
to work with the Pulse Policy Secure access management framework, you must
configure the system as a Web agent in most cases.
If you select the Delegate authentication to a standard agent option, you must set the
following options in the agent configuration object of the standard Web agent to host
the FCC URL:
 <EncryptAgentName=no>
 <FCCCompatMode=no>
To configure the system as a Web agent on the SiteMinder policy server:
1. In the SiteMinder Administration interface, click the System tab.
2. Right-click Agents and select Create Agent.
3. Enter a name for the Web agent and a description. You must enter this name when
creating a SiteMinder realm.
4. Select the Support 5.x agents option for compatibility with the system.
5. Under Agent Type, select SiteMinder and then select Web Agent from the list. This
setting is required for compatibility with the system.
6. Under IP Address or Host Name, enter the name or IP address of the system.
7. In the Shared Secret box, enter and confirm a secret for the Web agent. Note that you
must enter this secret when configuring the system.
8. Click OK.
Configuring the Authentication Scheme
Within SiteMinder, an authentication scheme is a way to collect user credentials and

determine the identity of a user. You may create different authentication schemes and
associate different protection levels with each. For example, you may create two
schemes—one that authenticates users based solely on the users’ client-side certificates
and provides them a low protection level, and a second that uses RSA Authentication
Manager SecurID token authentication and provides users a higher protection level.
To configure a SiteMinder authentication scheme:
1. In the SiteMinder Administration interface, select the System tab.
2. Right-click Authentication Schemes and select Create Authentication Scheme.
3. Enter a name for the scheme and (optionally) a description. You must enter this name
when configuring the SiteMinder realm.

4. Under Authentication Scheme, select one of the following options:
 Basic Template
 HTML Form Template
 SecurID HTML Form Template-If you are using SecurID authentication, you must
choose SecurID HTML Form Template (instead of SecurID Template). Choosing
this option enables the Policy Server to send ACE sign-in failure codes.
 X509 Client Cert Template
 X509 Client Cert and Basic Authentication
NOTE:
You must select HTML Form Template to handle reauthentication.
 If you select X509 Client Cert Template or X509 Client Cert and Basic
Authentication, you must import the certificate through System >
Certificates > Trusted Client CAs.
5. Enter a protection level for the scheme. Note that this protection level carries over to
the SiteMinder realm that you associate with this scheme.
6. Select Password Policies Enabled for this Authentication Scheme if you want to
reauthenticate users who request resources with a higher protection level than they
are authorized to access.
7. Select Scheme Setup tab, and enter the options required by your authentication
scheme type.
If you want the system to reauthenticate users who request resources with a higher
protection level than they are authorized to access, you must enter the following
settings:
 Under Server Name, enter the host name (for example, sales.yourcompany.net).
 Select the Use SSL Connection check box.
 Under Target, enter the sign-in URL defined plus the parameter “ive=1” (for example,
/highproturl?ive=1). The system must have a sign-in policy that uses */highproturl
as the sign-in URL and only uses the corresponding SiteMinder authentication realm.
 Clear the Allow Form Authentication Scheme to Save Credentials check box.
 Leave Additional Attribute List empty.
8. Click OK.
If you change a SiteMinder authentication scheme on the policy server, you must flush
the cache using the Flush Cache option on the Advanced tab.

Configuring the SiteMinder Domain
Within SiteMinder, a policy domain is a logical grouping of resources associated with one
or more user directories. Policy domains contain realms, responses, and policies. When
configuring the Pulse Policy Secure access management framework to work with
SiteMinder, you must give user access to a SiteMinder resource within a realm, and
then group the realm into a domain.
To configure a SiteMinder domain:
1. Select the System tab, right-click Domains and select Create Domain, or click Domains
and select an existing SiteMinder domain.
2. Add a realm to the domain.
Configuring the SiteMinder Realm
Within SiteMinder, a realm is a cluster of resources within a policy domain grouped

together according to security requirements. When configuring SiteMinder to work with
the Pulse Policy Secure access management framework, you must define realms to
determine which resources the users might access.
To configure a SiteMinder Realm:
1. In the SiteMinder Administration interface, select the Domains tab.
2. Expand the domain that you created.
3. Right-click Realms and select Create Realm.
4. In the Agent field, select the Web agent that you created.
5. In the Resource Filter field, enter a protected resource. This resource inherits the
protection level specified in the corresponding authentication scheme.
For the default protection level, enter /ive-authentication. You must enter this resource
when configuring the system. If you use sign-in policies with nondefault URLs such
as */nete or */cert, you must have corresponding resource filters in the SiteMinder
configuration.
6. From the Authentication Schemes list, select the scheme that you created.
7. Click OK.
Configuring a Rule or Response Pair to Pass Usernames
Within SiteMinder, you can use rules to trigger responses during authentication or
authorization. A response passes DN attributes, static text, or customized active responses
from the SiteMinder policy server to a SiteMinder agent. When you configure SiteMinder
to work with the Pulse Policy Secure access management framework, you must create
a rule that triggers when a user successfully authenticates. Then, you must create a
corresponding response that passes the user’s username to the system Web agent.

To create a new rule:
2. Expand the domain that you created and then expand Realms.
3. Right-click the realm that you created and select Create Rule under Realm.
4. Enter a name and (optionally) description for the rule.
5. Under Action, select Authentication Events and then select OnAuthAccept from the
drop down list.
6. Select Enabled.
7. Click OK.
To create a new response:
2. Expand the domain that you created.
3. Right-click Responses and select Create Response.
4. Enter a name and (optionally) a description for the response.
5. Select SiteMinder and then select the Web agent.
6. Click Create.
7. From the Attribute list, select WebAgent-HTTP-Header-Variable.
8. Under Attribute Kind, select Static.
9. Under Variable Name, enter IVEUSERNAME.
10. Under Variable Value, enter a username.
11. Click OK.
Configuring Authentication with a SiteMinder Server

To configure authentication with SiteMinder server:
2. Select SiteMinder Server and click New Server to display the configuration page.
After you have saved the configuration, the page that is redisplayed includes an
Advanced tab.
5. Click the Advanced tab to display the configuration page.

Figure 91 on page 411 shows the Advanced configuration page for Pulse Policy Secure.
Figure 92 on page 412 shows the Advanced configuration page for Pulse Connect
Secure.

Figure 89: SiteMinder Server Configuration Page – Pulse Policy Secure

Figure 90: SiteMinder Server Configuration Page – Pulse Connect Secure

Table 47: SiteMinder Server Settings
Settings Guidelines
Policy Server Specify name or IP address of the policy server.
Backup Server(s) (Optional) Specify a comma-delimited list of backup policy servers.
Failover Mode? Select one of the following failover mode options:
 Yes–The device uses the main policy server unless it fails.

 No–The device does the load balancing among all the specified policy servers.
Agent Name Specify the agent name configured on the policy server.
Secret Specify the shared secret configured on the policy server. The value is case sensitive.
Compatible with Select a SiteMinder server version.
 5.5 Policy Servers–Supports version 5.5 and version 6.0. This is the default.
6.0 Policy Servers–Supports only version 6.0 of the SiteMinder server API.
12.0 Policy Servers–Supports only version 12.0.
On logout, redirect to Specify a URL to which users are redirected when they sign out of the device (optional). If you leave
this field empty, users see the default sign-in page.
The On logout, redirect to setting is included in the product release for backwards-compatibility.
We strongly recommend that you use the customizable sign-in pages feature instead.
Protected Resource Specify a default protected resource. If you do not create sign-in policies, the system uses this
default URL to set the user’s protection level for the session. The system also uses this default URL
if you select the Automatic Sign-In option. If your users are signing in to the “*” URL (default device
sign-in page), enter any URL (“/ive-authentication” is the default) to set the protection level to the
default value. If you do create sign-in policies, the device uses those sign-in policies instead of this
default URL.
You must enter a forward slash (/) at the beginning of the resource. For example, enter
/local-authentication.
Resource Action Displays the resource action configured on the back-end SiteMinder server.
Users authenticate using Select this option if you want the device to prompt the user for a token instead of a password; that
tokens or one-time is, if users submit tokens or one-time use passwords to the device.
passwords
For example, you can use this option to dynamically prompt for a password or token based on
sign-in policies by configuring two instances of the same authentication server. You can use one
instance for wireless users who have this option enabled and it prompts the user for a token, and
another instance for wired users who have this option disabled and it prompts the user for a
password.
This feature is available only on Pulse Policy Secure.
Server Catalog Use the Server Catalog button to display the Server Catalog in a new window. Add the SiteMinder
user attributes (such as the cookiename) that you want to use for role mapping.

Table 47: SiteMinder Server Settings (continued)
Settings Guidelines
SMSESSION cookie settings

When sending cookies to Specify the cookie domain for either the end user or the device. A cookie domain is a domain in
the end-user’s browser which the user’s cookies are active. For example, the system sends cookies to the user’s browser
in this domain.
Multiple domains should use a leading period and be comma-separated. For example,
.sales.myorg.com, .marketing.myorg.com.
Domain names are case-sensitive. You cannot use wildcard characters. For example, if you define
“.juniper.net” , the user must access the device as “http://ive.juniper.net” to ensure that his
SMSESSION cookie is sent back to the device.
Select HTTPS to send cookies securely if other Web agents are set up to accept secure cookies, or
HTTP to send cookies nonsecurely.
Cookie Domain and Enter the valid Internet domain for the cookie and where the browser of the user sends cookie
Protocol When the Cookie contents. This cookie domain should be the same as the IVE domain. For example, .jnpr.net
is Set on the Device
Select HTTPS to send cookies securely if other Web agents are set up to accept secure cookies,
or HTTP to send cookies non-securely.
SiteMinder authentication settings

Automatic Sign In Select this option to automatically sign in users with a valid SMSESSION cookie. Then, select the
authentication realm to which the users are mapped. If you select this option, note that:
 If the protection level associated with a

user’s SMSESSION cookie is different from the protection
level of the realm, the protection level associated with the cookie is used.
 This
option uses SMSESSION cookie, which is already present in the browser to enable single
sign-on.
 This option provides a single sign-on experience for users.
 This option enables users to sign in using a standard Siteminder Web Agent that generates an
SMSESSION cookie.
When you select this option, you must also configure the following suboptions:
 To assign user roles, use this user authentication realm–Select an authentication realm for
automatically signed-in users. The users are mapped to a role based on the role mapping rules
defined in the selected realm.
 If
Automatic Sign In fails, redirect to–Enter an alternative URL for users who sign in through the
automatic sign-In mechanism. The users are redirected to the specified URL if the authentication
fails and if there is no redirect response from the SiteMinder policy server. If you leave this field
empty, users are prompted to sign back in.
Authenticate using Select this option if you want to authenticate using the custom Web agent. Using this option, the
custom agent system generates the SMSESSION cookie, just like any other Web agent configured within the
organization.

Settings Guidelines
Authenticate using HTML Select this option if you want to post user credentials to a standard Web agent that you have
form post already configured rather than contacting the SiteMinder policy server directly.
If you select this option, the Web agent contacts the policy server to determine the appropriate
sign-in page to display to the user.
To configure the system to “act like a browser” that posts credentials to the standard Web agent,
you must enter the following information.
 Target–Specify the target URL.

 Protocol–Specify the protocol for communication between the system and the specified Web
agent. Select HTTP for non-secure communication. Select HTTPS for secure communication.
 Webagent–Specify the name of the Web agent to obtain SMSESSION cookies. An IP address is
not allowed for this field. (Specifying the IP address as the Web agent prevents some browsers
from accepting cookies.)
 Port– Specify the port for the protocol. Enter port 80 for HTTP or port 443 for HTTPS.
 Path–Specify the path of the Web agent’s sign-in page. The path must start with a backslash
(/) character. In the Web agent sign-in page URL, the path appears after the Web agent.
 Parameters– Specify the post parameters to be sent when a user signs in. Common SiteMinder
variables that you can use include _ _USER_ _, _ _PASS_ _, and _ _TARGET_ _. These variables are
replaced by the username and password entered by the user on the Web agent’s sign-in page
and by the value specified in the Target field. These are the default parameters for login.fcc—if
you have made customizations, you may need to change these parameters.
Delegate authentication Select this option to delegate authentication to a standard agent. When the user accesses the
to a standard agent system sign-in page, the FCC URL associated with the protected resource’s authentication scheme
is determined. The system redirects the user to that URL, setting the system sign-in URL as the
target. After successfully authenticating with the standard agent, an SMSESSION cookie is set in
the user’s browser and the user is redirected back. The system then automatically signs in the user
and establishes a session.
You must enable the Automatic Sign-In option to use this feature. If you enable this option and a
user already has a valid SMSESSION cookie when trying to access a resource, the system tries to
automatically sign in using the existing SMSESSION cookie. If the cookie is invalid, the SMSESSION
cookie and corresponding system cookies are cleared and a “timeout” page is displayed. The system
successfully delegates authentication when the user clicks the sign back in option. If you select this
option, your authentication scheme must have an associated FCC URL.
SiteMinder This feature is available only on Pulse Connect Secure.

authorization settings
Authorize requests Use SiteMinder policy server rules to authorize user Web resource requests. If you select this option,
against SiteMinder policy make sure that you create the appropriate rules in SiteMinder that start with the server name
server followed by a forward slash, such as: www.yahoo.com/, www.yahoo.com/*, and
www.yahoo.com/r/f1.
If authorization fails, Specify an alternative URL that users are redirected to if the device fails to authorize and no redirect
redirect to response is received from the SiteMinder policy server. If you leave this field empty, users are
prompted to sign back into the device.
If you are using an authorization-only access policy , you must enter an alternative URL in this field
regardless of whether the Authorize requests against SiteMinder policy server option is selected.
Users are redirected to this URL when an access denied error occurs.

Settings Guidelines
Resource for insufficient Specify a resource on the Web agent to which the users are redirected when they do not have the
protection level appropriate permissions.
Ignore authorization for Specify the file extensions corresponding to file types that do not require authorization.
files with extensions
Enter the extensions of each file type that you want to ignore, separating each with a comma. For
example, enter .gif, .jpeg, .jpg, .bmp to ignore various image types. You cannot use wildcard
characters (such as *, *.*, or .*) to ignore a range of file types.

Synchronization

Figure 91: SiteMinder Advanced Settings – Pulse Policy Secure

Figure 92: SiteMinder Advanced Settings – Pulse Connect Secure

Table 48: SiteMinder Advanced Configuration Options
Settings Guidelines
Poll Interval (seconds) Specify the interval at which the system polls the SiteMinder policy server to check for a new key.
Max. Connections Control the maximum number of simultaneous connections that the system is allowed to make
to the policy server. The default setting is 20.
Max. Requests/ Agent Control the maximum number of requests that the policy server connection handles before the
system ends the connection. If necessary, tune to increase performance. The default setting is
1000.
Idle Timeout (minutes) Control the maximum number of minutes a connection to the policy server may remain idle (the
connection is not handling requests) before the system ends the connection. The default setting
of “none” indicates no time limit.
Authorize while Specify that the system should look up user attributes on the policy server immediately after
Authenticating authentication to determine if the user is truly authenticated.
For example, if your SiteMinder server authenticates users based on an LDAP server setting, you
can select this option to indicate that the system should authenticate users through the SiteMinder
server and then authorize them through the LDAP server before granting them access. If the user
fails authentication or authorization, the user is redirected to the page configured on the policy
server.
Enable Session Grace Eliminate the overhead of verifying a user’s SMSESSION cookie each time the user requests the
Period same resource by indicating that the system should consider the cookie valid for a certain period
of time.
If you do not select this option, the system checks the user’s SMSESSION cookie on each request.
Note that the value entered here does not affect session or idle timeout checking.
Validate cookie every N Specify the time period for the system to eliminate the overhead of verifying a user’s SMSESSION
seconds (seconds) cookie each time the user requests the same resource by indicating that the system should consider
the cookie valid for a certain period of time.
Ignore Query Data Specify that the system does not cache the query parameter in its URLs. Therefore, if a user requests
the same resource as is specified in the cached URL, the request should not fail.
Accounting Port Specify that the value entered in this field must match the accounting port value entered through
the Policy Server Management Console in the Web UI. By default, this field matches the policy
server’s default setting of 44441.
Authentication Port Specify that the value entered in this field must match the authentication port value entered through
the Policy Server Management Console. By default, this field matches the policy server’s default
setting of 44442.
Authorization Port Specifies that the value entered in this field must match the authorization port value entered
through the Policy Server Management Console. By default, this field matches the policy server’s
default setting of 44443.
Agent Configuration Settings

Table 48: SiteMinder Advanced Configuration Options (continued)
Settings Guidelines
Overlook Session for Compare the request method to the methods listed in this parameter. If a match is found, Web
Methods Agent does not create a new or update an existing SMSESSION cookie, nor will it make any updates
to the cookie provider for that request.
You can enter multiple methods; use a comma to separate method names.
If Overlook Session for Methods parameter is set but not Overlook Session for URLs, then all
requests that match the methods defined in this parameter are processed (SMSESSION cookie
creation/update is blocked).
If both Overlook Session for Methods and Overlook Session for URLsparameters are set, both the
method and the URL of the request are matched before proceeding. Then, all URLs with specified
methods are processed (SMSESSION cookie creation/update is blocked).
Overlook Session for Compare the request URL to the URLs listed in this parameter. If a match is found, Web Agent does
URLs not create a new or update an existing SMSESSION cookie, nor will it make any updates to the
cookie provider for that request.
Specify a relative URL. For example: If the URL is http://fqdn.host/MyDocuments/index.html, enter

/MyDocuments/index.html
If Overlook Session for URLs is set but not Overlook Session for Methods, then all requests, regardless
of the methods, matching the URLs defined in this parameter are processed (SMSESSION cookie
creation/update is blocked).
If both Overlook Session for Methods and Overlook Session for URLsparameters are defined, both
the method and the URL of the request are matched before proceeding. Then, all URLs with specified
methods are processed (SMSESSION cookie creation/update is blocked).
SiteMinder caching
Flush Cache Select this option to delete the resource cache, which caches resource authorization information
for 10 minutes.

click Update.


Documentation
 Troubleshooting the SiteMinder Server Configuration on page 415

 How To: Configuring SiteMinder
 KB: SiteMinder Protected Resource
 KB: SiteMInder User Access Log
Troubleshooting the SiteMinder Server Configuration

Problem At some point, you may encounter problems configuring the eTrust SiteMinder server
interactions with the Pulse Secure client. You can use the following debugging tools to
identify and resolve problems:
Solution  Review

the system log file. The system tracks failures of cookie validation and key
rollovers.
 Review the Policy Server Authentication log files.
 Review the Standard Web Agent log file if you selected the Authenticate using HTLM
Form POST option.
 Confirm that the system contains the proper suffix that you defined in the Cookie
Domain field. If the system is not properly addressed, the browser might not forward
the correct SMSESSION cookie to the system and you miight not be able to sign in.
You must enter the system FQDN on the browser, not the system IP address, or the
login fails.

 Confirm that the system time is synchronized with the SiteMinder server system time.
If the two system times are too divergent, the timeout settings might not function
correctly, and might reject attempts to sign in.
 In the SiteMinder server, confirm that you have defined the proper Session Timeout
options max timeout and idle in the SiteMinder Realm dialog.
 To view the CA SiteMinder error codes select System > Log/Monitoring > User Access
page. For information on the CA SiteMinder error codes, see the SiteMinder
documentation.
Related Using a SiteMinder Server on page 396

Documentation

Using an SQL Server
This topic describes integration with the SQL server. It includes the following information:
 SQL Server Overview on page 416

 Configuring Authentication with an Oracle SQL Server on page 419
SQL Server Overview

This section describes support for using the SQL (also known as Oracle Database server)
as a Pulse Policy Secure authentication server. It includes the following sections:
 Understanding SQL Server on page 416

Understanding SQL Server
The SQL server is widely deployed in the enterprise. Some enterprises use the SQL server
to store user credentials (usernames and passwords), MAC addresses, and other
organizational information, such as group affiliations that are often the basis for
authorization decisions. To support authentication and authorization against SQL server
databases, the Pulse Policy Secure supports an authentication server configuration
that configures an Oracle Instant Client connection as well as relevant queries to the
backend SQL server.
Feature Support
The Pulse Policy Secure uses Oracle Instant Client 11.2.0.2.0 to communicate with the
SQL server. The SQL server version must support this version of the client. The Pulse
Policy Secure access management framework depends on the SQL server features
described in this section.
 SQL SELECT Statements on page 417

 SQL Stored Procedures on page 417

 SQL Format Specifiers on page 418

 SQL Statement Parameters on page 418
 SQL Password Hash Format on page 419
You can use the SQL queries for authentication, authorization and role mapping, or both.
SQL SELECT Statements
The authentication transaction is based on an SQL query that returns a password (and
possibly other information) based on the name entered by the user attempting to log in.
While a sample SQL query is provided in the original configuration file, you must configure
the SQL entry of the configuration file with a query appropriate to your database. The
query you enter must be either an SQL SELECT or an SQL EXECUTE statement that
contains additional syntax elements that are preprocessed by the SQL authentication
module.
The SQL authentication module executes SQL statements in parameterized form. This
means that the SQL statement is compiled once, with parameter markers (usually
question marks) as placeholders for data items that vary from one execution to the next.
Only upon execution of the statement are the actual data values supplied.
The SQL statement you compose must not include parameter markers directly. Instead,
include the names of the parameters where parameter markers would appear, in an
appropriate format.
This is an example of a parameter marker:
SELECT password, profile, fullname FROM usertable WHERE username = :name
The SQL authentication module translates the SQL statement provided, replacing
parameter names with parameter markers prior to passing the SQL statement to the
database engine.
The SQL statement can be very simple. Basically, all that is required is to look up a
password and possibly some optional information based on a username. The SQL
statement can also be quite complex; it can include inner joins, and it can contain
expressions. The underlying database engine is responsible for handling the SQL
statement; the SQL authentication module performs no interpretation of the SQL
statement other than to translate parameter names to parameter markers.
SQL Stored Procedures
A stored procedure is a sequence of SQL statements that form a logical unit and perform
a particular task. You can use stored procedures to encapsulate a set of queries or
operations that can be executed repeatedly on a database server. For example, you can
code operations on an employee database, such as password lookup, as stored
procedures that can be executed by application code. Stored procedures can be compiled
and executed with different parameters and results. Stored procedures can use any
combination of input parameters (the values passed to the stored procedure at execution
time) and output parameters (the values set or returned by the stored procedure to the
calling application or environment).

This is an example of a called procedure:
BEGIN; myCalledProcedure( :name, :password!os, ipAddr!ios, filterId!o); END;
As shown in the example, the procedure is called myCalledProcedure with input variables
as name and ipAddr, output parameters as password, ipAddr, and filterId. The names of
the output parameters are the names of the attributes added to the server catalog used
for role mapping and return attributes. The parameter consists of a colon (:), the name
of the parameter, and a format specifier.
SQL Format Specifiers
Table 49 on page 418 describes the SQL statement format specifiers with parameters in
called procedures.
Table 49: SQL Statement Format Specifiers
Specifier Definition
i Input parameter (Default if none is specified)
io Input/output parameter
o Output parameter
s String type (default if none is specified)
n Int type
SQL Statement Parameters
Table 50 on page 418 describes the SQL statement parameter names and types.
Table 50: SQL Statement Parameter Names and Types
Item Type Meaning for SQL Authentication
:user String Specifies the username as presented to the authentication server.
:password String Specifies the password as presented to the authentication server.
:realm String Specifies the realm as presented to the authentication server.
:ipAddr String Specifies the source IP address (L3 authentications only), which is sent as a
string. For example, 10.17.1.155.
:userAgent String Specifies the user agent string.
The value of the string is as follows:
 Blank for third-party supplicants

 Juniper-OAC for OAC
 Juniper-PULSE for Pulse
:loginTime Int Specifies the login time presented in the number of seconds.

Table 50: SQL Statement Parameter Names and Types (continued)
Item Type Meaning for SQL Authentication
:loginURL String Specifies the user URL of the sign-in policy of the user.
:callingStationId String Specifies the MAC address of the client presented as xx-xx-xx-xx-xx-xx for L3
authentications and in the format specified by the RADIUS client for L2
authentications.
:language String Specifies the language used by client as specified by IETF language tag. For
example, en-US for English as used in the United States.
SQL Password Hash Format
Table 51 on page 419 describes the different SQL password types.
Table 51: Password Hash Format
Hash/Name Definition Password Format Supported RADIUS Protocols
Automatic Automatically determines All

hash format based on Format.
Clear Text No Encryption PasswordText PAP, CHAP, MSCHAP,

MSCHAP-V2, EAP-JUAC,
EAP-MSCHAP-V2,
EAP-MD5-Challenge
SHA 1 SHA1+Base64 hash {SHA}HashHashHash PAP, EAP-JUAC
Salted SHA 1 salted SHA1+Base64 hash {SSHA}HashHashHashSalt PAP, EAP-JUAC
NT Hash** MD4 hash of the unicode form {md4}HashHash PAP, MSCHAP, MSCHAP-V2,
of password EAP-JUAC, EAP-MSCHAP-V2
The following limitation applies when defining and monitoring an SQL server instance:
The maximum number of connections to an Oracle database is limited to 50 connections

for L2 and L3 logins (concurrent and open RADIUS protocol), without any browser logins.
Configuring Authentication with an Oracle SQL Server

To configure authentication with an SQL server:
2. Select SQL Server and click New Server to display the configuration page.

Figure 94: SQL Server Configuration Page
Table 52: SQL Server Settings
Settings Guidelines

Table 52: SQL Server Settings (continued)
Settings Guidelines
SQL Server Specify the SQL server host name or IP address. The default value is 1521.
SQL Port Specify the SQL port number through which the SQL server is accessed.
Backup SQL Server (Optional) Specify the backup SQL server host name.
Backup SQL Port (Optional) Specify the backup SQL port number.
SQL Service Name (Optional) Specify the SQL service name if SQL service name has been defined in the SQL server
configuration.
Admin Specify the administrator username.
Password Specify the password.
Connection Timeout Specify the connection timeout value from 5 to 60 seconds. If this time is exceeded, and if there
is a backup server defined, then the device attempts to reach the backup server.
Search Timeout Specify the search timeout value from 5 to 60 seconds. It specifies the maximum amount of time
the device will wait for the SQL server to return search results.
SQL Vendor Select Oracle. Read and accept the license agreement. You cannot save or test the configuration
until you have accepted the license agreement.
Finding user entries

SQL Statement Specify the SQL statement to find the user entries.
For example:
SELECT password FROM usertable WHERE username = :name AND realm = :realm
Password Attribute Name Specify the attribute name specified in the SQL statement that the device uses for password
authentication. If the username that is entered exists in the database, then the authentication
succeeds. If you are using the SQL server for authorization, no password is necessary here.
Full Username Attribute (Optional) Specify the attribute name specified in the SQL statement for the system to use when
Name displaying the user's full name.

Table 52: SQL Server Settings (continued)
Settings Guidelines
SQL Password Type Select one of the following SQL password types:
 Automatic
 Clear Text
 SHA 1
 Salted SHA 1
 NT Hash
The SQL password type setting specifies the format of the hash used for the password. The values
for the SQL password type include a prefix index that indicates how the password has been
processed. The prefix is in clear-text between curly braces { } and is immediately followed by a
hash value computed from the password. If no prefix is present in the value retrieved from the table
Password column, the entire password is assumed to be in clear-text format.
Test User Lookup

Select Statement Values Enter the attributes necessary to fill in the WHERE part of the SQL statement and click the Test
Connection button to save the server configuration and attempt to connect to the database server
with the information you have entered.
Upon a successful connection and retrieval of the user record, the server displays the results. It
displays the entire returned user record (hiding the password) from the SELECT portion of the SQL
statement. An error line is displayed if the connection to the SQL server fails or if the user record
could not be retrieved. The user record is displayed in the following format: attribute Name1 = value,
attribute name2 = value, and so on.
NOTE: When trying to populate the server catalog attributes for the SQL server, you must enter
data into all columns of interest for a particular record. Columns that are not assigned data are
ignored during the lookup and are therefore not added appropriately to the server catalog.
Save SQL Column Names Select this option to use the SQL query statement variables as server catalog attributes. You can
or Called Procedure use the server catalog in role mapping rules.
variable names as
Attribute names in the
Server Catalog
Server Catalog
Attributes The Attributes button appears after you have saved the server information or performed a test
connection operation. Click the Attributes button to display the server catalog.

Figure 95 on page 423 shows the user accounts table for Pulse Policy Secure.

click Update.

Documentation
 KB: Pulse Policy Secure Troubleshooting: Err Code 22053

 Troubleshooting Oracle Error Codes on page 423
Troubleshooting Oracle Error Codes
Table 53 on page 424 describes the Oracle error codes, cause, and action.

Table 53: Oracle Error Codes
Error code Cause Action
ORA-00018: maximum number All session state objects are in use. Increase the value of the SESSIONS
of sessions exceeded initialization parameter.
ORA-00019: maximum number All licenses are in use. Increase the value of the LICENSE MAX
of session licenses exceeded SESSIONS initialization parameter.
ORA-00020: maximum number All process state objects are in use. Increase the value of the PROCESSES
of processes (string) exceeded initialization parameter.
Related Using an SQL Server on page 416

Documentation


CHAPTER 11
Authentication Realms

 Before Configuring a Realm on page 426
 Configuring a MAC Address Authentication Realm on page 429
 Defining Authentication Access Policies on page 432
 Specifying Role Mapping Rules for an Authentication Realm on page 433
 Customizing User Realm UI Views on page 440
Understanding Authentication Realms
You create authentication realms to permit clients to request authentication from the
Policy Secure gateway. The Policy Secure gateway supports different types of agent
access: UAC agents, (OAC, Pulse, the Java agent, or endpoints using agentless
access), third-party 802.1X supplicants, and 802.1X phones.
Depending on the client and the authentication server you are using, different
authentication protocols can be paired with different realms. You pair realms with the
appropriate authentication protocol sets when you configure sign-in policies.
An authentication realm specifies the conditions that users must meet to sign in to the
Policy Secure gateway. A realm consists of a grouping of authentication resources,
including:
 An authentication server—Verifies that the identity of the user. The Policy Secure
gateway forwards credentials that a user submits to an authentication server.
 A directory server—An LDAP server that provides user and group information to the
Policy Secure gateway that the Policy Secure gateway uses to map users to one or
more user roles.
 An authentication policy—Specifies realm security requirements that must be met

before the Policy Secure gateway submits a user's credentials to an authentication
server for verification.

 Role-mapping rules—Conditions a user must meet in order for the Policy Secure
gateway to map the user to one or more user roles. These conditions are based
either on user information returned by the realm's directory server or the username.
 Session migration—You configure authentication groups for realms for which you want
to permit session migration. With session migration configured, users can access
Policy Secure gateways and Connect Secure gateways within the same federated
network without requiring reauthentication. Session migration is supported only with
Pulse.
Related Before Configuring a Realm on page 426

Documentation

Before Configuring a Realm
Topic Details
About RADIUS Proxy The Policy Secure gateway supports RADIUS proxy for both inner and
outer authentication. RADIUS proxy allows you to use an external
RADIUS server for authentication. If the authentication server for a
realm is a RADIUS server, three option buttons: Proxy RADIUS Inner
Authentication, Proxy RADIUS Outer Authentication, and Do not proxy are
visible. If the authentication server is not a RADIUS server, the proxy
check boxes are hidden.
RADIUS Proxy limitations When RADIUS proxy is used, realm or role restrictions cannot be
enforced. Host Checker policies, Source IP restrictions, and any other
limits that have been assigned will be bypassed.Use RADIUS proxy only
if no restrictions have been applied.
LDAP and attribute server behavior If the LDAP server is down, user authentication fails. You can find
messages and warnings in the event log files. When an attribute server
is down, user authentication does not fail. Instead, the groups/attributes
list for role-mapping and policy evaluation is empty.
Dynamic Policy Evaluation If you select Dynamic policy evaluation and you do not select Refresh
roles and Refresh resource policies, the Policy Secure gateway
evaluates the realm’s authentication policy, role-mapping rules, and
role restrictions only.

Chapter 11: Authentication Realms
Topic Details
Performance impacts with Dynamic Policy Evaluation Because dynamic policy evaluation can potentially impact system
performance, keep these guidelines in mind:
 Since automatic (timer-based) refreshing of user roles and resource

policies can affect system performance, you can improve performance
by disabling either or both of the Refresh roles and Refresh resource
policies options to reduce the scope of the refresh.
 To improve performance, set the Refresh interval option to a longer
time period.
 Use the Refresh Now button at times when users are not likely to be
affected.
Related Understanding Authentication Realms on page 425

Documentation

Creating an Authentication Realm
To create an authentication realm:
1. In the admin console, select Administrators > Admin Realms or Users > User Realms.
2. On the respective Authentication Realms page, click New. Alternatively, select a realm
and click Duplicate to base your realm on an existing realm.
3. Enter a name to label this realm and, optionally, a description.
4. If you are copying an existing realm, click Duplicate. Then, if you want to modify any
of its settings, click the realm’s name to enter into edit mode.
5. Select When editing, start on the Role Mapping page if you want the Role Mapping tab
to be selected when you open the realm for editing.
6. Under Servers, specify:
 An authentication server to use for authenticating users who sign in to this realm.
 (Optional) A directory/attribute server to use for retrieving user attribute and group
information for role-mapping rules and resource policies.
 (Optional) A RADIUS accounting server to use to track when a user signs in and out
of the Policy Secure gateway .
7. If you previously selected a RADIUS server for Authentication, the RADIUS Proxy option
buttons appear. Select Proxy Outer Authentication or Proxy Inner Authentication to
allow the Policy Secure gateway to proxy EAP authentication methods. Select Do
not proxy if you do not want to use RADIUS proxy.

8. To use dynamic policy evaluation for this realm, select Dynamic policy evaluation to
enable an automatic timer for dynamic policy evaluation of this realm’s authentication
policy, role-mapping rules, and role restrictions. Then:
a. Select the Refresh interval option to specify how often the Policy Secure gateway
performs an automatic policy evaluation of all currently signed in realm users.
Specify the number of minutes (5 to 1440).
b. Select Refresh roles to refresh the roles of all users in this realm. (This option does
not control the scope of the Refresh Now button.)
c. Select Refresh resource policies to also refresh the resource policies (not including
Meeting and e-mail Client) for all users in this realm. (This option does not control
the scope of the Refresh Now button.)
d. Click Refresh Now to manually evaluate the realm’s authentication policy,

role-mapping rules, role restrictions, user roles, and resource policies of all currently
signed-in realm users. Use this button if you make changes to an authentication
policy, role-mapping rules, role restrictions, or resource policies and you want to
immediately refresh the roles of this realm’s users.
9. To use session migration for endpoints with the Pulse client, select the Session
Migration check box. Then enter the Authentication Group and specify whether you
want to receive user attributes from IF-MAP or from a directory server. Note that you
must also configure IF-MAP Federation for all of the Policy Secure gateway and
Connect Secure gateway devices in a session migration network.
10. Click Save Changes to create the realm on the Policy Secure gateway. The General,
Authentication Policy, and Role Mapping tabs for the authentication realm appear.
11. Perform the next configuration steps:
a. Configure one or more role-mapping rules.
b. Configure an authentication policy for the realm.
12. After you configure the authentication realm, select Authentication > Signing In >
Sign-in Policies, add the realm to a sign-in policy, and associate the realm with an
authentication protocol set.
Related Defining Authentication Access Policies on page 432

Documentation
 Before Configuring a Realm on page 426

 Configuring and Managing Sign-In Policies on page 480

Configuring a MAC Address Authentication Realm
The MAC address authentication framework uses a special realm, called the MAC Address
Authentication Realm. When the access framework uses the MAC address authentication
realm, you do not need to configure a sign-in policy. In the User realm and the Admin
realm frameworks, the system uses sign-in policies to match authentication requests to
the appropriate realm; in the MAC Address authentication realm framework, any username
credential that matches one of the common variants of a MAC address format
(colon-separated, dash-separated, and the like) is sent to the MAC authentication realm
based on its format.
To configure a MAC Address Authentication Realm:
1. Select UAC > MAC Address Realms.
2. Click New to display the configuration page shown in Figure 96 on page 430.

Figure 96: MAC Address Authentication Realm Configuration Page

Table 54: MAC Address Authentication Realm Configuration Guidelines
Settings Guidelines
Name Specify a name to identify the realm in the system.
Description Specify a description to inform other administrator users of the purpose of this configuration.
When editing, start ... Select this option if you want the role mapping page to be the first page displayed when editing this
configuration (instead of the general settings page).
Servers
Authentication Select a MAC Address authentication server.
Directory/Attribute Select a directory or attribute server to be used in role mapping rules, typically an LDAP server.
NOTE: Beginning with Release 4.4, you can select same as above to specify that the attributes are
derived from the LDAP server that has been specified in the MAC address authentication server
configuration. Prior to Release 4.4, you had to specify the LDAP server explicitly.
Accounting Select a RADIUS server, if one has been configured, and you want to use RADIUS accounting to track
when a client signs in and signs out of the system.
Dynamic Policy Evaluation

Dynamic Policy Select this option to enable an automatic timer for dynamic policy evaluation of this realm’s
Evaluation authentication policy, role-mapping rules, and role restrictions; and to display the settings listed
below for the dynamic policy evaluation feature.
Refresh interval Specify the interval, in minutes, to run the evaluation for active sessions. The default is 60, which
runs role mapping evaluation every 60 minutes. The valid range is 5 to 1440.
Refresh roles Select this option if you want dynamic policy evaluation to refresh the user role, if applicable, for
active sessions.
Refresh resource Select this option if you want dynamic policy evaluation to refresh allow/deny resource access
policies decisions for active sessions.
Refresh Now Click this button to manually evaluate the realm’s authentication policy, role-mapping rules, role
restrictions, user roles, and resource policies of all current sessions. Use this button when you make
changes to an authentication policy, role-mapping rules, role restrictions, or resource policies and
you want to immediately refresh the roles of this realm’s sessions.
Other Settings
Displays information about the associated authentication policy and role mapping rules.
Related Using the MAC Address Authentication Server on page 328

Documentation

 Example: Using Endpoint Discovery and Profiling for MAC Address Authentication on
page 334

Defining Authentication Access Policies
An authentication policy is a set of rules that controls one aspect of access

management—whether or not to present a realm’s sign-in page to a user. An
authentication policy is part of an authentication realm’s configuration, specifying rules
for the Policy Secure gateway to consider before presenting a sign-in page to a user. If a
user meets the requirements specified by the authentication policy the Policy Secure
gateway presents the corresponding sign-in page to the user and then forwards the
user's credentials to the appropriate authentication server. If this server authenticates
the user, the Policy Secure gateway continues to the role evaluation process.
To specify authentication realm access policies:
1. In the admin console, select Administrators > Admin Realms or Users > User Realms.
2. On the respective Authentication Realms page, select a realm and then click the
Authentication Policy tab.
3. On the Authentication Policy page, configure one or more access management options.
Related Using Source IP Access Restrictions on page 241

Documentation

Understanding Role Mapping Rules
Role-mapping rules are conditions a user must meet in order for the Policy Secure
gateway to map the user to user roles. These conditions are based either on user
information returned by the realm's directory server or the user's username. You must
specify role-mapping directives in the following format: If the specified condition is|is
not true, then map the user to the selected roles.
To create a role-mapping rule use Role Mapping tab of an authentication realm. When
you click New Rule on this tab, the Role Mapping Rule page is displayed with an inline
editor for defining the rule. This editor leads you through the three steps of creating a
rule:
 Specify the type of condition on which to base the rule. Options include:
 Username
 Certificate or certificate attribute
 Custom expressions

 Specify the condition to evaluate. Options include:
 One or more usernames, certificate attributes, or expressions depending on the type

of condition you select. Outer proxy cannot be used for the realm if a role-mapping
rule based on usernames is created, as the Policy Secure gateway cannot see the
username, and a session cannot be created.
 To what the value(s) must equate, which might include a list of usernames, client-side
certificate values (static or compared to LDAP attributes), or predefined custom
expressions. If you are using proxy RADIUS for outer authentication, you cannot
create a role-mapping rule based on username.
 Specify the roles to assign to the authenticated user.
The Policy Secure gateway compiles a list of eligible roles to which a user can be mapped.
These roles are specified by the role-mapping rules to which the user conforms. Next,
the Policy Secure gateway evaluates the definition for each role to determine whether the
user complies with any role restrictions. The Policy Secure gateway uses this
information to compile a list of valid roles, for which the user meets any additional
requirements. Finally, the Policy Secure gateway either performs a permissive merge of
the valid roles or presents a list of valid roles to the user, depending on the
configuration specified on the realm’s Role Mapping tab.
Related Understanding User Roles on page 261

Documentation
 Specifying Role Mapping Rules for an Authentication Realm on page 433

Specifying Role Mapping Rules for an Authentication Realm
When you create a new rule that uses LDAP or SiteMinder user attributes, LDAP group
information, or custom expressions, you must use the server catalog.
To specify role-mapping rules for an authentication realm:
1. Select Administrators > Admin Realms , Users > User Realms, or UAC > MAC Address
Realms.
2. On the Authentication Realms page, select a realm and then click the Role Mapping
tab.
3. Click New Rule to access the Role Mapping Rule page. This page provides an inline
editor for defining the rule.
4. In the Rule based on list, select one of the following:
 Username—The Policy Secure gateway username entered on the sign-in page.

Select this option if you want to map users to roles based on their Policy Secure
gateway usernames. If this is a RADIUS realm, and you are using RADIUS proxy for
outer authentication, you cannot configure a role-mapping rule with a username.
 User attribute—A user attribute from a RADIUS, LDAP, or SiteMinder server. Select
this option if you want to map users to roles based on an attribute from the
corresponding server. This type of rule is available only for realms that use a RADIUS

server for the authentication server, or that use an LDAP or SiteMinder server for
either the authentication server or the directory server. After choosing the User
attribute option, click Update to display the Attribute list and the Attributes button.
Click the Attributes button to display the server catalog.
 To add SiteMinder user attributes, enter the SiteMinder user attribute cookie
name in the Attribute field in the server catalog. Then click Add Attribute. When
you are finished adding cookie names, click OK. The Policy Secure gateway
displays the names of the SiteMinder user attribute cookies in the Attribute list
on the Role Mapping Rule page.
 Certificate or Certificate attribute—Certificate or Certificate attribute is an attribute

supported by the users’ client-side certificate. Select this option to map users to
roles based on certificate attributes. The Certificate option is available for all realms.
The Certificate attribute option is available only for realms that use LDAP for the
authentication or directory server. After choosing this option, click Update to display
the Attribute text box.
 Group membership—Group membership is group information from an LDAP or

native Active Directory server that you add to the server catalog Groups tab. Select
this option to map users to roles based on either LDAP or Active Directory group
information. This type of rule is available only for realms that use an LDAP server
for either the authentication server or directory server or that use an Active Directory
server for authentication. (Note that you cannot specify an Active Directory server
as an authorization server for a realm.)
 Custom Expressions—Custom Expressions is one or more custom expressions that

you define in the server catalog. Select this option to map users to roles based on
custom expressions. This type of rule is available for all realms. After you select this
option, click Update to display the Expressions lists. Click the Expressions button
to display the Expressions tab of the server catalog.
5. Under Rule, specify the condition to evaluate, which corresponds to the type of rule
you select and consists of the following:
CAUTION: If you are creating a role mapping rule for a MAC address
authentication realm, the attributes list cannot be edited. If there is an
LDAP server assigned to this MAC authentication server and you want to
use and edit the attributes assigned to that LDAP server, please specify
the LDAP server as the Directory/Attribute server.
a. Specifying one or more usernames, SiteMinder user attribute cookie names, RADIUS
or LDAP user attributes, certificate attributes, LDAP groups, or custom expressions.
b. Specifying to what the value must equate, which might include a list of Policy
Secure gateway usernames, user attribute values from a RADIUS, SiteMinder, or
LDAP server, client-side certificate values (static or LDAP attribute values), LDAP
groups, or custom expressions.

For example, you can choose a SiteMinder user attribute cookie named
“department” from the Attribute list, choose is from the operator list, and then
enter "sales" and "eng" in the text box.
Alternatively, you can enter a custom expression rule that references the SiteMinder
user attribute cookie named department:
<userAttr.department = ("sales" and "eng")>
6. Under ...then assign these roles:
a. Specify the roles to assign to the authenticated user by adding roles to the Selected
Roles list.
b. Select Stop processing rules when this rule matches if you want the Policy Secure
gateway to stop evaluating role-mapping rules if the user meets the conditions
specified for this rule.
7. Click Save Changes to create the rule on the Role Mapping tab. When you finish creating
rules, be sure to order role-mapping rules in the order in which you want the Policy
Secure gateway to evaluate them. This task is particularly important when you want
to stop processing role-mapping rules when a match is identified.
Related Understanding Role Mapping Rules on page 432

Documentation

on page 234
Using the LDAP Server Catalog
The LDAP server catalog is a secondary window through which you specify additional
LDAP information for the Policy Secure gateway to use when mapping users to roles,
including:
 Attributes—The Server Catalog Attributes tab shows a list of common LDAP attributes,
such as cn, uid, uniquemember, and memberof. This tab is accessible only when
accessing the Server Catalog of an LDAP server. You can use this tab to manage an
LDAP server’s attributes by adding custom values to and deleting values from its
Policy Secure gateway server catalog. Note that the Policy Secure gateway
maintains a local copy of the LDAP server’s values; attributes are not added to or
deleted from your LDAP server’s dictionary.
 Groups—The Server Catalog Groups tab provides a mechanism to easily retrieve group
information from an LDAP server and add it to the server’s Policy Secure gateway
server catalog. You specify the BaseDN of your groups and optionally a filter to begin
the search. If you do not know the exact container of your groups, you can specify the
domain root as the BaseDN, such as dc=juniper, dc=com.The search page returns a
list of groups from your server, from which you can choose groups to enter into the
Groups list.

NOTE: The BaseDN value specified in the LDAP server’s configuration page
under "Finding user entries" is the default BaseDN value. The Filter value
defaults to (cn=*).
You can also use the Groups tab to specify groups. You must specify the fully qualified
domain name (FQDN) of a group, such as cn=GoodManagers, ou=HQ, ou=Juniper,
o=com, c=US, but you can assign a label for this group that is displayed in the Groups
list. Note that this tab is accessible only when accessing the Server Catalog of an LDAP
server.
 Expressions—The Server Catalog Expressions tab provides a mechanism to write

custom expressions for the role-mapping rule.
To display the LDAP server catalog:
 After you select the User attribute option on the Role Mapping Rule page, click Update
to display the Attribute list and the Attributes button.
 Click the Attributes button to display the LDAP server catalog. (You can also click
Groups after choosing the Group membership option, or click Expressions after choosing
the Custom Expressions option.)

Figure 97: Adding an Attribute for LDAP in the Server Catalog

Figure 98: Adding LDAP Groups

To add a group, type a name and click Add Group. To edit an existing group, select it, make your
changes and click Save Changes. When you are done, click OK.
Account 0 erators
Name: jBackup Operators
ON: CN=Backup
Operators, CN=Builtin,DC=QA,DC=danastreet, DC=net
Type: static
Save Changes
OK New.. Delete Search..
Server Catalog for LDAP
OU
sAMAccountName Attribute: jnewAccount
sn
st Save Changes
title
uid
OK New.. Delete

Figure 99: Adding Active Directory Groups
Related Specifying Role Mapping Rules for an Authentication Realm on page 433
Documentation
 Using Custom Expressions in Rule Configuration on page 843

Customizing User Realm UI Views
You can use customization options on the User Authentication Realms page to quickly
view the settings that are associated with a specific realm or set of realms. For instance,
you can view the role-mapping rules that you associated with all your user realms.

Additionally, you can use these customized views to easily link to the authentication
policies, servers, role-mapping rules, and roles associated with a user realms.
To view a subset of data on the User Authentication Realms page:
1. Select one of the following options from the View menu:
 Overview—Displays the authentication servers and dynamic policy evaluation

settings that you have set for the specified user realms. You can also use this setting
to link to the specified server configuration pages.
 Authentication Policy—Displays Host Checker restrictions that you have enabled

for the specified user realms. You can also use this setting to link to the specified
Host Checker configuration pages.
 Role Mapping—Displays rule conditions and corresponding role assignments that

you have enabled for the specified user realms. You may also use this setting to link
to the specified rule conditions and role assignments configuration pages.
 Servers—Displays authentication server names and corresponding types that you

have enabled for the specified user realms. You may also use this setting to link to
the specified server configuration pages.
 Roles—Displays role assignments and corresponding permissive merge settings

that you have enabled for the specified user realms.
2. Select one of the following options from the For list:
 All realms—Displays the selected settings for all user realms.
 Selected realms—Displays the selected settings for the user realms you choose. If
you select this option, select one or more of the check boxes in the Authentication
Realm list.
3. Click Update.


CHAPTER 12
IF-MAP Federation

 IF-MAP Federation Quick Start on page 450
 Task Summary: Configuring IF-MAP Federation on page 451
 Configuring IF-MAP Server Settings on page 453
 Configuring IF-MAP Client Settings on page 454
 Understanding Session-Export and Session-Import Policies on page 455
 Configuring Session-Export Policies on page 458
 Configuring Session-Import Policies on page 460
 Modifying Session-Export and Session-Import Policies on page 461
 Troubleshooting the IF-MAP Federation Network on page 462
 Viewing Active Federated Session Tables on page 462
 Understanding IF-MAP Server Replicas on page 463
 Configuring IF-MAP Server Replicas on page 465
 Understanding Clustering in a Federated Deployment on page 465
 Understanding Coordinated Threat Control in an Federated Deployment on page 467
 Using IDP Devices in a Federated Deployment on page 469
 Using IF-MAP Enabled Network Equipment on page 469
Understanding Federated Deployments
This topic describes Pulse Policy Secure services federated deployments. It includes the
 IF-MAP Federation Overview on page 444

 Example Topology on page 445
 IF-MAP Federation Configuration Overview on page 447
 Supported IF-MAP Clients on page 448
 IF-MAP and Session Migration on page 448
 IF-MAP Federation Licensing on page 448
 IF-MAP Logging on page 449

 IF-MAP Federation Network Timing Considerations on page 449

 About IF-MAP Federation Performance on page 449
IF-MAP Federation Overview

You can configure the Policy Secure gateway to store user session information from
other Policy Secure gateways and Connect Secure gateways. Federation allows
users to access a single Policy Secure gateway or Connect Secure gateway, and then
access resources that are protected by Infranet Enforcers that are connected to
different Policy Secure gateways.
Federation enhances network performance. If a user must log in to multiple Policy

Secure gateways or Connect Secure gateways during the course of a day to access
different resources, each device must perform authentication and Host Checking, often
with periodic Host Checker updates throughout the day. The overhead can lead to
decreased performance not only on the devices, but also on the network and on the
endpoint. Imported IF-MAP sessions eliminate redundant logins and host checks.
Federation on the Policy Secure gateway uses the standard IF-MAP (Interface for
Metadata Access Point) protocol to share session information and other data between
connected devices over distributed networks. IF-MAP is a protocol defined by the
Trusted Network Connect Working Group (TNC-WG) as a standard interface between
different network elements and devices. Federation is accomplished using an IF-MAP
server and IF-MAP clients.
It is important as an administrator to understand the fundamental underlying

communication method for data transmission in a Federation network over IF-MAP.
Policies that you configure on the Policy Secure gateway and the Connect Secure
gateway permit this communication. You configure Policy Secure gateways as IF-MAP
servers and IF-MAP clients. You configure Connect Secure gateways as IF-MAP clients.
In a federated network, the IF-MAP server functions as the repository, or data store for
IF-MAP clients to use for publishing information regarding activity on the network. For
example, Policy Secure gateway and Connect Secure gateway IF-MAP clients can publish
information about sessions on the network, and Juniper Networks IDP devices can
communicate information about potential threats to the IF-MAP client for publishing.
IF-MAP clients can search for information about sessions or threats, and an IF-MAP
client can establish a subscription so the IF-MAP server notifies the client when other
clients publish new or changed information. In addition, IF-MAP clients can purge data
that is no longer valid. All transactions are initiated by the IF-MAP client. Figure 100 on
page 445 shows a simple IF-MAP transaction. Not all of the steps for IF-MAP Federation
are shown in this example.

Chapter 12: IF-MAP Federation
Figure 100: IF-MAP Overview
1. The endpoint accesses the IF-MAP client (a Policy Secure gateway or Connect Secure
gateway). IF-MAP client 1 publishes session information to the IF-MAP server.
2. The endpoint attempts to access protected resources that are behind the Infranet
Enforcer.
3. The Infranet Enforcer notifies the Policy Secure gateway (also an IF-MAP client).
IF-MAP client 2 searches for session information on the IF-MAP server.
4. The Policy Secure gateway subscribes to session information about the endpoint’s IP
address.
5. The Policy Secure gateway notifies the Infranet Enforcer that session information
exists for the IP address that is attempting to access resources, and the Infranet
Enforcer provisions an auth table entry.
6. Access is granted to the protected resources. If any session information about the
user changes, the authenticating IF-MAP client publishes the new information. Having
subscribed to the user’s session information, the Policy Secure gateway is notified of
any changes and provisions access in accordance with the changed session
information.
NOTE: IF-MAP Federation is required if you want to configure session

migration for the Policy Secure gateway and Connect Secure gateways for
clients that use Pulse.
Example Topology
Figure 101 on page 446 depicts a scenario in which two Policy Secure gateways are
configured as IF-MAP clients, one Connect Secure gateway is configured as an IF-MAP
client, and another Policy Secure gateway configured as the IF-MAP server. Endpoints
who access any of the IF-MAP clients

can access protected resources behind the enforcement point attached to Policy
Secure gateway 1.
Figure 101: Federation IF-MAP Topology
Interaction among the endpoints, the clients and the server is as follows:
 An endpoint accesses the Connect Secure gateway and starts Network Connect or
Pulse.
 The Connect Secure gateway provisions an IP address for the endpoint to use on
the internal network. Once the endpoint’s IP address on the internal network is
known, the Connect Secure gateway derives IF-MAP data from the endpoint’s
session.
 The Connect Secure gateway IF-MAP client publishes the session information as IF-
MAP data to the IF-MAP server using Session-Export policies.
 When the user attempts to access resources behind the enforcement point, access is
blocked because the Infranet Enforcer has no information about the endpoint. The
Infranet Enforcer sends a dynamic discovery message that includes the endpoint’s
source IP address.
 Policy Secure gateway 1 uses the IP address to retrieve session data from the IF-MAP
server.
 The Policy Secure gateway uses Session-Import policies to retrieve session data
from the IF-MAP server.
The interaction is similar for the endpoint authenticated through Policy Secure gateway
2. The principal difference is that the endpoint behind the Policy Secure gateway can
use IPsec to communicate, while the endpoint behind the Connect Secure gateway
uses Source IP. Additionally, the endpoint authenticated through the Connect Secure
gateway must be running Network Connect.

Imported user sessions do not count against the maximum user count for either platform,
because each user is counted on the Policy Secure gateway or Connect Secure
gateway from which they authenticated.
Note that if the Infranet Enforcer is configured for captive portal, the federated network
works as follows: The Infranet Enforcer redirects the browser to the Policy Secure
gateway that controls the Infranet Enforcer. The Policy Secure gateway waits until
importing the session succeeds or fails. If importing succeeds, the browser is
redirected to the protected resource. If importing fails, the browser is redirected to the
Policy Secure gateway login page.
IF-MAP Federation Configuration Overview

You can configure the Policy Secure gateway as an IF-MAP client or an IF-MAP server.
You can configure the Connect Secure gateway as an IF-MAP client for an IF-MAP
server. A Policy Secure gateway configured as an IF-MAP server is automatically a
client of itself: an IF-MAP server can function as a fully functional Policy Secure
gateway, and any endpoint sessions with an IP address created on an IF-MAP server
are automatically published to that IF-MAP server.
You can create IPsec policies and source IP policies for endpoints that access a Policy
Secure gateway (IPsec is for OAC and Pulse on endpoints that connect through the Policy
Secure gateway only) and source IP policies for endpoints that access a Connect
Secure gateway to permit access to resources behind Infranet Enforcers (ScreenOS
Enforcers and Junos Enforcers).
Session-Export policies that you configure on the IF-MAP clients allow the clients to
publish endpoint user data to the IF-MAP server. Policy Secure gateways that are IF-
MAP clients can subscribe to the information on an IF-MAP server and can act as the
policy decision point for attached Infranet Enforcers.
When a user accesses a Policy Secure gateway or a Connect Secure gateway that is
configured as an IF-MAP client, the client publishes basic session information,
including the IP address,
username and roles, to the IF-MAP server. The server stores the information as metadata.
Other IF-MAP clients in the network can poll the server for metadata when session
information is needed as a result of an endpoint attempting to access protected resources
behind an Infranet Enforcer.
When an authenticated user from a Policy Secure gateway or a Connect Secure gateway
that is configured as an IF-MAP client attempts to access resources that are protected
by an Infranet Enforcer for a Policy Secure gateway that is also configured as an IF-
MAP client, the second Policy Secure gateway automatically provisions an auth table
entry for the user without requiring the user to access the second Policy Secure
gateway.
The second Policy Secure gateway subscribes to session information and other endpoint
data based on the originating IP address. The authenticating Policy Secure gateway or
Connect Secure gateway (the original IF-MAP client) publishes any changes in session
parameters to the IF-MAP server. Because the Policy Secure gateway that is protecting
the accessed resources subscribes to the metadata on the Federation server, session
information is always current.
Federation requires dynamic auth table provisioning on the Infranet Enforcer. The Infranet
Enforcer allows or denies traffic based on the resource access policies that are configured

on the Policy Secure gateway to which it is connected.

You configure server settings on the Policy Secure gateway that will be the IF-MAP
server. You configure client settings on each of the Policy Secure gateways and
Connect Secure gateways that will be connected in the network. With client and server
settings, you can configure Policy Secure gateways and Connect Secure gateways to
utilize Federation by being configured as IF-MAP clients to an IF-MAP server or group
of IF-MAP servers configured as replicas in a high availability configuration. You
configure each IF-MAP client to connect to one IF-MAP server. You configure an entry
for each IF-MAP client on the IF-MAP server.
It is important to coordinate server and client settings accurately, as endpoints rely on

communication between the IF-MAP server and the IF-MAP client. In addition to the
server and client settings, you configure Session-Export policies and Session-Import
policies.
IF-MAP allows servers and clients to publish, search, poll, and subscribe to data within
a network of IF-MAP servers and clients. All of the data from the Policy Secure
gateways and Connect Secure gateways in the network that is published to the IF-
MAP server uses the IF-MAP protocol. Session-Export and Session-Import polices that
you configure on the Policy Secure gateway and the Connect Secure gateway allow the
devices to utilize the IF-MAP protocol to share session information.
Session-Export policies specify how to translate an endpoint’s session on the Policy

Secure gateway or the Connect Secure gateway into IF-MAP data. To translate session
information into IF-MAP data, you enter detailed user information. The Policy Secure
gateway or the Connect Secure gateway evaluates the Export policies to determine a
session’s IF-MAP roles, capabilities, identities, and device attributes, and then
publishes the data to the IF-MAP server.
The Session-Import policies that you configure on the Policy Secure gateway specify
how the device derives a username and a set of roles based on IF-MAP data that it
receives from the IF-MAP server from other Policy Secure gateways or Connect Secure
gateways. Import policies are similar to role-mapping rules on a realm. You must be
precise when you configure Export and Import policies, otherwise roles cannot be
assigned properly.
Supported IF-MAP Clients

The Policy Secure gateway publishes to the IF-MAP server for any endpoint that
connects with any client. The Connect Secure gateway publishes to IF-MAP for
endpoints running Network Connect or Pulse.
IF-MAP and Session Migration

Sessions can be migrated between Policy Secure gateways and Connect Secure
gateways that are in the same IF-MAP federated network: either using the same IF-MAP
server, or if the IF-MAP servers are replicas of one another.
IF-MAP Federation Licensing
IF-MAP functionality is included with all Pulse Policy Secure user licenses. To deploy
the Pulse Policy Secure as an IF-MAP server in "hybrid mode," where it can be
configured as both an IF-MAP server and an IF-MAP client, the user count license must
be 51 or greater. You can accomplish this by leasing a license for 51 or more users from
a license server or by installing a 100 user (or greater) ACCESS license.

IF-MAP Federation is not supported for non-root IVS on the Connect Secure gateway.

IF-MAP Logging
IF-MAP related events are logged on both the IF-MAP server and the IF-MAP client.
IF-MAP Federation Network Timing Considerations

It is important that the time on all IF-MAP servers and clients is correct and coordinated,
because timeout issues are critical to ensure that IF-MAP provides complete and timely
information between servers, replicas, cluster members, and clients.
The components are designed to fail-secure. If complete and timely information cannot
be provided user sessions are purged from the data stores. For example, if the chain of
connections between an IF-MAP client that publishes a session and a client that grants
access to a resource breaks, the client that granted access removes the session. The
fail-secure time limit is 3 minutes.
The timeout limit for IF-MAP is 3 minutes and applies to the following events:
 An IF-MAP server (or cluster) loses contact with one of its IF-MAP clients.
 An IF-MAP server (or cluster) loses contact with one of the other IF-MAP servers (or
clusters) in the IF-MAP federation.
 An IF-MAP client loses contact with its IF-MAP server (or cluster) for too long.
 An IF-MAP server (or cluster) loses contact with an IF-MAP server replica.
If a connection between an IF-MAP client and an IF-MAP server is interrupted gracefully,

for example, the client is shut down, or if an IF-MAP server replica connection from another
server replica is interrupted, the server keeps the connection open for three minutes,
giving the client or server time to reboot.
However, if a connection is severed without a graceful close, for example, an IF-MAP

client crashes or a router fails, the server gives the other component about nine minutes
to reconnect. (This is to give the network time to stabilize if a router reboots.)
About IF-MAP Federation Performance

Federation is a new technology created by Pulse Secure. Numerous variables involved in
an IF-MAP Federation deployment scenario can affect performance and capacity. For
example:
 Is the IF-MAP Federation server a dedicated device, or is it also used as a production

Policy Secure gateway?
 Is the IF-MAP Federation server deployed as a replica?
 How many sessions are expected to be imported?
Latency and bandwidth between IF-MAP replicas affect the amount of time taken to
replicate large amounts of data during heavy IF-MAP server utilization. Pulse Secure is
performing ongoing quality and performance testing of IF-MAP Federation, and results
will be made available upon completion of the testing.

IF-MAP Federation server support is currently available on the IC6500, IC6000, and
IC4500 devices. Federated session limitations apply to all platforms. Optimal performance
is achieved with the IC6500 as a Federation server. The IC4500 can be used with up to
1,000 active clients and 5,000 federated sessions from another device.
Related Task Summary: Configuring IF-MAP Federation on page 451

Documentation
 IF-MAP Federation Quick Start on page 450

IF-MAP Federation Quick Start
Use this section as a quick guide to establish the federated network framework. Read
the detailed IF-MAP section to create more complex policies.
What you need to get started:
 Two Policy Secure gateways, or one Policy Secure gateway and one Connect Secure
gateway. Users who access the Connect Secure gateway must use Network Connect
or Pulse. Users who access the IC must use OAC or Pulse).
 A Pulse Secure security device (Infranet Enforcer), either a Junos Enforcer or

ScreenOS Enforcer (ScreenOS 6.1 or Junos 9.4 are required). See ScreenOS Enforcer
and Junos Enforcer.
 An IF-MAP server license, or a user license installed on the Policy Secure gateway that
will be an IF-MAP server. A Connect Secure gateway can be only an IF-MAP client. IF-
MAP clients do not require licensing.
 Dynamic auth table allocation enabled.
 The client must trust the issuer’s device certificate. Ensure that the client regards the
Certificate Authority (CA) that issued that certificate as a trusted server CA. If the
device certificate is self-signed, place that certificate in the client’s list of trusted server
CAs. Ensure that the hostname in the server certificate matches the hostname in the
IF-MAP URL on the client.
 At least one matching role name on all devices (for example, a role named executives
on each device).
Perform the following actions:
1. Select a Policy Secure gateway to be the IF-MAP server (for this example, Policy
Secure gateway 1). In the admin console, select System > IF-MAP Federation >
Overview and select
IF-MAP Server.
2. On the This Server tab, click the Clients subtab and then click Add New IF-MAP Client.
3. Enter a name for the other device, the IP address of the other device (for this example,
Policy Secure gateway 2), select basic authentication, and enter a username and
password.
4. On Policy Secure gateway 2, select System > IF-MAP-Federation > Overview , and
athen select IF-MAP Client. For the Server URL, enter the complete server URL of
Policy Secure gateway 2 (example: https://ic 1 IP address/dana-ws/soap/dsifmap),
select Basic
authentication, and enter the username and password you entered on Policy Secure
gateway
1. The status light on the server’s IF-MAP Federation > This Server > Clients page is
green when the client and server are successfully connected.
5. For the initial IF-MAP setup, use the default Session-Import Policy and Session-Export
Policy. The default Session-Import Policy automatically imports any IF-MAP sessions
on the IF-MAP server. The default Session-Export policy automatically exports all
sessions to the IF-MAP server.
6. Connect one Policy Secure gateway to an Infranet Enforcer.
7. Access the device that is not connected to the Infranet Enforcer (for example, configure
the client to connect to the Policy Secure gateway or Connect Secure gateway). You
can see that the session was exported to the IF-MAP server by looking in IF-MAP
Federation > This Server > Federation-Wide Sessions.
8. Send traffic through the Infranet Enforcer (that is, attempt to access a resource). The
traffic passes through and accesses the resource. You can see that the session was
imported by viewing IF-MAP > Federation > Active Users > Imported on the Policy
Secure gateway that is connected to the Infranet Enforcer.
Related Task Summary: Configuring IF-MAP Federation on page 451

Documentation
 Understanding Dynamic Auth Table Allocation on page 151

Task Summary: Configuring IF-MAP Federation
Configuring an IF-MAP federated network requires coordination between administrators

of the devices in the federated network. This document describes IF-MAP deployments
that include Policy Secure gateways, Connect Secure gateways, Infranet Enforcer
firewalls, and Juniper Networks IDP. For implementations that incorporate third-party
components, contact Pulse Secure Technical Support.
The mix of devices in a federated network is important when planning the network. Will
the network consist of only Policy Secure gateways, or will you incorporate Connect
Secure gateways? Do the devices in the network have similar role-mapping policies, or is
each device different?
Determine and understand your goals for the federated network. The big picture guides
your implementation as it becomes more complex. Pulse Secure recommends that you
begin slowly. For example, start with a single role on each device, and then build the
network incrementally.
In the simplest model, you can use the default policies. Using this model, you can quickly
establish a federated network, and session information will automatically be shared
among distributed devices in the network. This simple model should be adequate for
most implementations in which the devices in the federated network have identical or
very similar role-mapping policies.

If your configuration requires more complex policies, you must perform a number of tasks
to achieve your intended results.
 Ensure that communications between IF-MAP servers and IF-MAP clients are
established.
 Determine the resources to be shared among the devices.
 Define who can access specific resources.
 Distribute resources and users into roles.
 Establish a naming convention that is shared and implemented across all administrators
and devices.
 Create Session-Export and Session-Import policies that reflect the role designations
you configure on the devices.
To use IF-MAP Federation, you perform the following tasks:
1. Enable dynamic auth table provisioning on any connected Infranet Enforcers that you
want to use with Federation.
2. Configure IF-MAP server settings to permit the server to communicate with IF-MAP
clients.
3. Configure IF-MAP client settings to permit clients to communicate with the IF-MAP
server.
4. Coordinate Session-Import policies, Session-Export policies, roles, and resource access

policies among all of the clients in the Federated network.
5. Configure Session-Export policies on Policy Secure gateways and Connect Secure

gateways to define how sessions are translated to IF-MAP data.
6. Configure Session-Import policies on Policy Secure gateways that correspond with

Export policies to translate IF-MAP data into Policy Secure gateway roles.
7. Configure Source IP policies for endpoints that use Source IP to access the network.
For more information see ScreenOS Enforcer and Junos Enforcer.
8. Configure IPsec policies for Pulse or OAC endpoints that will use IPsec to access the
network. For more information see ScreenOS Enforcer and Junos Enforcer.

Documentation

 Configuring IF-MAP Server Settings on page 453
 Configuring IF-MAP Client Settings on page 454
 Understanding Session-Export and Session-Import Policies on page 455

Configuring IF-MAP Server Settings
You must add all IF-MAP clients to the Policy Secure gateway IF-MAP server. To add
clients, you must specify the IP address and the security mechanism and credentials
for the client.
An IF-MAP server certificate must be installed on the IF-MAP server. The client verifies
the server certificate when it connects to the server. The server certificate must be signed
by a CA), the client must be configured to trust certificates signed by that CA, and the
hostname in the server certificate must match the hostname in the IF-MAP URL on the
client.
On an IC6500 FIPS device, select the Configuration > Certificates > New CSR button to
create a CSR. You pass the CSR request to an external CA, and then import the generated
certificate file into the Pending Certificate Signing Request page.
The Configuration > Certificates > Device Certificate > Import Certificate and Key button
is disabled on the FIPS device.
When you configure the Policy Secure gateway as an IF-MAP server, at startup a large
amount of virtual memory is used. This is normal, as the IF-MAP server is required to
set aside a cache to accommodate imported sessions.
To configure IF-MAP server settings on the Policy Secure gateway that is the IF-MAP
server:
1. In the admin console, select System > IF-MAP Federation > Overview.
2. Under Choose whether this Policy Secure gateway runs an IF-MAP Server, an IF-MAP
client, or no IF-MAP, select the IF-MAP Server option button.
4. In the admin console select System > IF-MAP Federation > This Server > Clients.
5. Click New IF-MAP Client.
6. Under IF-MAP Client, enter a name and optionally a description for this client.
7. Type one or more IP addresses of the client. If the client is multihomed, for best results
list all of its physical network interfaces. If the client is a Policy Secure gateway or
Secure Access cluster, list the internal and external network interfaces of all nodes.
You must enter all of the IP addresses for all of the interfaces, because equipment
failures may cause traffic between the IF-MAP client and the IF-MAP server to be re-
routed through a different network interface. Listing all of the IP addresses
maximizes the probability that IF-MAP Federation still works in the event of a
failure.
8. Under Authentication, select the Client Authentication Method: Basic or Certificate.
a. If you select Basic, enter a Username and Password. The same information should
be added to the IF-MAP server.

b. If you select Certificate, choose which Certificate Authority (CA) to use to verify
the certificate for this client. Optionally, specify certificate attributes or restrictions
to require values for certain client certificate attributes.
9. Click Save Changes to save the IF-MAP Client instance on the IF-MAP server.
Related Configuring IF-MAP Client Settings on page 454

Documentation

Configuring IF-MAP Client Settings
You must identify the IF-MAP server to each Policy Secure gateway and Connect
Secure gateway IF-MAP client. To add the server, you specify the IF-MAP URL of the
server and how to access the server. Match the URL and security settings to equal
those on the IF-MAP server(s) to which the IF-MAP client will connect.
To configure IF-MAP client settings on the Policy Secure gateways or Connect Secure
gateways that will be IF-MAP clients:
1. In the admin console select System > IF-MAP Federation > Overview.
2. Under Choose whether this Policy Secure gateway runs an IF-MAP Server, an IF-MAP
client, or no IF-MAP, select the IF-MAP Client option button.
3. Type the Server URL for IF-MAP Web service on the IF-MAP server. Append the server
URL with /dana-ws/soap/dsifmap for all Pulse Secure IF-MAP servers.
4. Select the Client Authentication Method: Basic or Certificate.
a. If you select Basic, enter the same username and password. This is the same as
the information that you entered on the IF-MAP server.
b. If you select Certificate, select the Device Certificate to use.
Ensure that the certificate of the CA that signed the IF-MAP server certificate is
added from the Trusted Server CA page.
The IF-MAP client validates the IF-MAP server certificate. If validation fails, the
connection fails. Ensure that the hostname in the IF-MAP URL on the client machine
matches the hostname of the server certificate on the IF-MAP server, and that the
CA that signed the server certificate is configured as a trusted server CA on the
IF-MAP client.
Related Configuring IF-MAP Server Settings on page 453

Documentation


Understanding Session-Export and Session-Import Policies
This topic describes how to use IF-MAP session export and session import policies. It
includes the following content:
 Session-Export and Session-Import Policies Overview on page 455

 Default Session-Export and Session-Import Policy Action on page 457
 Advanced Session-Export and Session-Import Policies on page 457
 Administrative Domains in Session-Export Policies on page 457
Session-Export and Session-Import Policies Overview
NOTE: The Policy Secure gateway contains default Session-Export and

Session-Import policies. The Session-Import Policy imports all of the sessions
that are on the IF-MAP server. The Session-Export policy exports all sessions
to the IF-MAP server.
You configure Session-Export policies on all of the Policy Secure gateways and
Connect Secure gateways in the Federation network that are IF-MAP clients. These
policies allow IF-MAP clients to translate outgoing session information into IF-MAP
data and incoming IF-MAP data into session information. These translations enable
sessions to be shared between Connect Secure gateways and Policy Secure gateways
and Connect Secure gateways even if the devices sharing sessions have different role
configurations.
To accurately configure Session-Export and Session-Import policies, you need a minimal

understanding of IF-MAP identifiers and IF-MAP metadata. An identifier is a unique value
required for all metadata operations. Each instance of metadata is associated with an
identifier. Examples of identifiers include access-request, identity, IP address, and MAC
address. Examples of metadata include capability, role, and device-attribute.
IF-MAP recognizes two metadata types that are similar to roles on the Policy Secure
gateway and Connect Secure gateway: IF-MAP roles and IF-MAP capabilities. An IF-
MAP role is an attribute assigned to a user in the organization. When IF-MAP metadata
is published to the IF-MAP server, this information could be one way to identify
individuals on the network. This is somewhat different from the concept of roles on the
Policy Secure gateway. An IF-MAP capability is closer to the concept of a role on the
Policy Secure gateway. An IF-MAP capability is a collection of privileges assigned as a
result of an access request. This is more analogous to a Policy Secure gateway or
Connect Secure gateway role since they are derived through role-mapping in an
authentication realm.
The data that is published to the IF-MAP server about a user session is derived by applying
the Session-Export policies to the user session. The Session-Import policies are applied
to the data from the IF-MAP server to assign a set of roles to the user.
When an endpoint attempts to access protected resources associated with a Policy

Secure gateway, the device queries the IF-MAP server for data. The Policy Secure
gateway uses
Session-Import policies to derive roles and a username from the IF-MAP data. For

example, you can configure a Session-Import policy that looks for a specific Host Checker
policy (you specify the Host Checker policy in the Session-Import policy). If the Policy
Secure gateway finds a match (in this case the Host Checker device attribute), the user
can be assigned a role specified in the Session-Import policy.
All administrators who are configuring devices in the IF-MAP Federation network must
agree on a set of capabilities, roles, and device attributes and their meanings to be used
with IF-MAP. Then, each administrator configures their device to map between local
sessions and IF-MAP data. Figure 102 on page 456 illustrates a coordinated IF-MAP
Federated network configuration with policies that permit a user to access protected
resources.
Figure 102: Session-Import and Session-Export Policies
Note the following Pulse Secure IF-MAP conventions:
 A Policy Secure gateway or Connect Secure gateway maps to the identical IF-MAP
username.
 A role on a Policy Secure gateway or Connect Secure gateway is paired with an IF-MAP
capability.
 Capabilities can have the same name as the roles they are paired with, or a different
name.
 When different IF-MAP clients have different but equivalent role names (such as Legal
and Law, both of which refer to members of the corporate legal department), a single
IF-MAP capability must be chosen.
 Not every role must be paired with an IF-MAP capability. Roles can be local to a
Policy Secure gateway or Connect Secure gateway.

 After you decide on pairings between IF-MAP capabilities and the roles on the
Connect Secure gateway or Policy Secure gateway, you create a Session-Export
policy for each pairing. On a Policy Secure gateway that controls Infranet Enforcers,
you create a Session-Import policy.
 The only parameters for the policies are the Infranet Enforcer or Connect Secure
gateway roles and the IF-MAP capability; all other parameters are fixed.
Default Session-Export and Session-Import Policy Action

By default, Session-Import and Session-Export IF-MAP policies are configured to allow
IF-MAP capabilities (the equivalent of Policy Secure gateway or SA series appliance
roles) to be published to the IF-MAP server and retrieved from the IF-MAP server,
provided there are matching roles on each IF-MAP client. You can open new Session-
Import and Session-Export policies on each device and then name and close the
policies. Any matching roles that the IF-MAP clients in the federated network have can
be used to access resources.
Advanced Session-Export and Session-Import Policies

By default, advanced policy actions are not visible unless you click the advanced options
links on the Session-Export and Session-Import policy pages. In default mode, you
configure Session-Export and Session-Import policies using IF-MAP capabilities and
Policy Secure gateway roles.
You can access device attributes, IF-MAP roles, and identities through the advanced
options links. IF-MAP capabilities and Policy Secure gateway roles should provide the
functionality that most Policy Secure gateway and Connect Secure gateway IF-MAP
Federation requires.
Administrative Domains in Session-Export Policies

In a Layer 2 environment, session information on the IF-MAP server includes a MAC
address. If an export policy specifies an Administrative Domain, the domain is associated
with the MAC address published to the IF-MAP server (the administrative domain is also
associated with the identity published to the IF-MAP server).
A DHCP server assigns an IP address to the endpoint after authentication. An IF-MAP

enabled DHCP server publishes an ip-mac link to IF-MAP, associating the endpoint’s IP
address with its IF-MAP session information. Including administrative domains in MAC
addresses allows the ip-mac link to be created based on the administrative domain.
If your IF-MAP Federated network spans different administrative domains, configure

separate Session-Export policies for each domain to prevent MAC address spoofing.
Each administrative domain must have an associated DHCP server and unique
Session-Export policies.
Other aspects of the Session-Export policies within the IF-MAP Federated network can
overlap.
Related Configuring Session-Export Policies on page 458

Documentation


Configuring Session-Export Policies
Session-export policies map Pulse Policy Secure roles to IF-MAP identifiers.
The default session-export policy exports all user sessions. It translates each role into
an IF-MAP capability of the same name. The default policy accommodates most use
cases, particularly Pulse Policy Secure and Pulse Connect Secure deployments that use
the same access management role-mapping framework. You might replace the
default policy with your own configuration in the following cases:
 If the Pulse Policy Secure or Pulse Connect Secure devices that are the IF-MAP
clients do not have complete accord on role names.
 If third-party IF-MAP clients have special requirements.
 If too many user sessions are exported, harming performance.
If necessary, you can create a custom session-export policy that specifies the data that
is exported to the IF-MAP server. For example, you can configure a session-export policy
to specify that any users that belong to the “engineering” role are identified with the
“engineering” IF-MAP capability on the IF-MAP server. That identity is included in the
session information to which other IF-MAP clients subscribe.
You must also create a corresponding session-import policy for Pulse Policy Secure IF-
MAP clients. The import policy enables the IF-MAP client collect IF-MAP data from
the IF-MAP server.
To configure a session-export policy:
1. In the admin GUI select System > IF-MAP > Session-Export Policies.
2. Click New to create a new policy.
3. Enter a policy name and, optionally, a description.
4. (Optional) Use the role selector controls to specify the roles for which this policy
applies. If you do not add any roles, the policy applies to all sessions. However, if you
have roles assigned to non-interactive devices, such as printers, that do not need
access, you might want to specify roles so that you can exclude those roles.
5. Under Policy Actions, select Set IF-MAP Capabilities and select the applicable option:
 Copy Matching Roles—Copies all of the user roles that match the roles specified in
the Roles section of this policy into the IF-MAP capabilities data.
 Copy all Roles—Copies all of the roles from the user session to the IF-MAP capabilities
data.
 Set capabilities specified below—Enter capabilities, one per line.
6. Select Stop processing policies when this policy matches to make the policy a terminal
policy—that is, if this policy matches, policies listed below it in the policies table are
not consulted.
7. Select Save Changes or continue to configure advanced actions.

If necessary, you can configure advanced options to define particular details of the IF-MAP
export. The advanced options are not required for most Pulse Policy Secure and Pulse
Connect Secure IF-MAP deployments.
To configure advanced options:
1. Select the View Advanced Actions link to display additional options.
2. Select Set IF-MAP Identity and configure identity settings:
 Identity Type —Select an element used to specify identity. Options include aik-name,
distinguished-name, dns-name, email-address, kerberos-principal,
trusted-platform-model, username, sip-uri, tel-uri, and other. For example, for a
regular employee named Bob Smith you can select username as the Identity Type
and enter the Identity as username bsmith.
 Identity—Identity is normally specified as <NAME>, which assigns the user’s login

name. Any combination of literal text and context variables may be specified. If you
select other for Identity Type, enter a unique Identity Type in the text box.
 Administrative Domain—This optional information is applied to identity and MAC

address data. One example for using this field is in a large network environment
with several domains in which a username could be duplicated. By supplying the
domain, you ensure that the correct user is identified.
 Other—This field is provided for advanced use cases when none of the predefined
options are applicable.
3. Select Set IF-MAP Roles and select the applicable option:
 Copy Matching Roles—Copies all of the user roles that match the roles specified in
the Roles section of this policy into the IF-MAP capabilities data.
 Copy all Roles—Copies all of the roles from the user session to the IF-MAP capabilities
data.
 Set capabilities specified below—Enter capabilities, one per line.
4. Select Set IF-MAP Device Attributes. Device attributes represent a passed Host Checker
policy on the Pulse Policy Secure or Pulse Connect Secure. Select the applicable
option:
 Copy Host Checker policy names—Name of each Host Checker policy that passed
for the session is copied to a device attribute.
 Set Device Attributes—Enter device attributes, one per line.
5. Select Save Changes.
Related Understanding Session-Export and Session-Import Policies on page 455

Documentation


Configuring Session-Import Policies
A session-import policy matches imported IF-MAP data to Pulse Policy Secure roles.
The default session-import policy imports all user sessions. It translates each IF-MAP
capability into a Pulse Policy Secure role of the same name. The default policy
accommodates most use cases, particularly Pulse Policy Secure and Pulse Connect
Secure deployments that use the same access management role-mapping framework.
You might replace the default policy with your own configuration in the following cases:
 If the Pulse Policy Secure or Pulse Connect Secure devices that are the IF-MAP
clients do not have complete accord on role names.
 If third-party IF-MAP clients have special requirements.
 If too many user sessions are exported, harming performance.
To configure session-import policies:
1. In the admin GUI, select System > IF-MAP > Session-Import Policies.
2. Click New to create a new policy.
3. Type a policy name and, optionally, a description.
4. Under Conditions when Policy Applies, select Match IF-MAP Capabilities.
5. Enter IF-MAP capabilities exactly as they appear in the corresponding session-export

policy. For example, if you assigned the value “engineering” to an IF-MAP capability
in the session-export policy, enter “engineering” here.
6. Under “Assign these roles,” select Use these roles and select the roles for which the
policy applies.
7. Alternatively, select Copy IF-MAP Capabilities. If you select this check box, IF-MAP
session capabilities on the IF-MAP server are converted to Pulse Policy Secure roles
with the same name. You can use this option if Pulse Policy Secure roles and IF-MAP
capabilities have the same name. This option is typically not required for Pulse
Policy Secure deployments.
8. Select Stop processing policies when this policy matches to make the policy a terminal
policy—that is, if this policy matches, policies listed below it in the policies table are
not consulted.
9. Select Save Changes, or continue to configure Advanced Conditions.
You can configure advanced options that would further require that Identity, Role, or
Device Attributes in the IF-MAP data for a session must match before applying the role
matching. The advanced options are not required for most Pulse Policy Secure and
Pulse Connect Secure IF-MAP deployments.
To configure advanced options:
1. Select the View Advanced Conditions link to additional options.

2. Select one or more of the following check boxes to specify which IF-MAP criteria to
use for assigning roles:
 If you select Match IF-MAP Identity, complete the following settings:
 Identity Type—Select an element used to specify identity. Options include

aik-name, distinguished-name, dns-name, email-address, kerberos-principal,
trusted-platform-model, username, sip-uri, tel-uri, and other. For example, for a
regular employee named Bob Smith you can select username as the Identity Type
and enter the Identity as username bsmith.
 Identity—Identity is normally specified as <NAME>, which assigns the user’s login

name. Any combination of literal text and context variables may be specified. If
you select other for Identity Type, enter a unique Identity Type in the text box.
 Administrative Domain—This optional information is applied to identity and MAC

address data. One example for using this field is in a large network environment
with several domains in which a username could be duplicated. By supplying the
domain, you ensure that the correct user is identified.
 Other—This field is provided for advanced use cases when none of the predefined
options are applicable.
 Match IF-MAP Roles—Enter individual roles in the provided text box.
 Match IF–MAP Device Attributes—Enter individual device attributes in the provided

text box.

Documentation

Modifying Session-Export and Session-Import Policies
If you modify a Session-Export policy, existing exported sessions are preserved on the
IF-MAP Federation server. IF-MAP data based on the new policy is published to the
IF-MAP server as applicable. IF-MAP data that is no longer valid for a session is deleted
and new IF-MAP data is added.
Modifying a Session-Import policy results in all of the imported session information on

the If-MAP client being reimported. If the new policy specifies that roles for a user have
changed, the session is not deleted, but the eligible roles for the session reflect the
updated policy.

Documentation


Troubleshooting the IF-MAP Federation Network
The following diagnostic tools on the Policy Secure gateway and Connect Secure
gateway can assist you in troubleshooting a federated network:
 IF-MAP Client User Messages—On the IF-MAP client, logs information that is published
to and removed from the IF-MAP server.
Enable IF-MAP Client User Messages by selecting Log/Monitoring > User Access >
Settings on the Policy Secure gateway and Connect Secure gateway IF-MAP client.
 IF-MAP Server Trace—On the IF-MAP server, logs the XML for all IF-MAP requests and
responses.
Enable the IF-MAP Server Trace by selecting Log/Monitoring > Events > Settings on
the IF-MAP server.
IF-MAP Server Trace should only be enabled for troubleshooting purposes, because
running this diagnostic incurs a large performance impact.
Related Viewing Active Federated Session Tables on page 462

Documentation

Viewing Active Federated Session Tables
This topic describes how to view active users on both the IF-MAP client and the IF-MAP
server. It includes the following content:
 Viewing Active Users on the IF-MAP Client on page 462

 Viewing Active Users on the IF-MAP Server on page 463
Viewing Active Users on the IF-MAP Client

On an IF-MAP client, you can view all sessions from other Policy Secure gateways or
Connect Secure gateways that currently access the client (the imported sessions). You
can view the username, roles, the user’s endpoint IP address, and the IP address of the
Policy Secure gateway or Connect Secure gateway that authenticated the user. You
can select and remove sessions either temporarily or permanently. A temporarily
removed session can be restored in response to a request for continued access. A
permanently removed session cannot be restored.
To view, de-activate, or activate current sessions on an IF-MAP client:
1. In the IF-MAP client admin console select System > IF-MAP > Active Users.
2. Select Imported or Exported.
3. Select Activate or De-activate.

Viewing Active Users on the IF-MAP Server

On an IF-MAP server, you can view all sessions that have been published to the server.
In addition to username, roles assigned to the user, and endpoint IP address, you can
view the MAC address of the endpoint, the capabilities, the device attributes, sign-in time,
authenticated by, Network Access Device, and any events associated with the user
session, such as IDP warnings or messages. You can sort lists by user and by signed-in
IP address.
The IF-MAP server purges sessions about 3.5 minutes after the client disconnects. The
exceptions are if the server is currently involved in a purge or immediately after the server
starts. It takes several minutes to scan the database before a purge can begin.
To view details about users and their sessions, and perform detailed searches:
1. Select System > IF-MAP Federation > This Server > Federation-Wide Sessions.
2. Enter users and administrative domain and click Update to search for specific session
information.
3. Sort users on the page by selecting User or Signed in IP Address.
NOTE: The maximum number of session entries displayed in the

Federation-Wide Sessions table or returned by the query to the table is 5,000
entries.
TIP: You can also view IF-MAP session-export details by selecting the IF-MAP
check box at Troubleshooting > User Sessions > Policy Tracing in the admin
console.
Related Troubleshooting the IF-MAP Federation Network on page 462

Documentation

Understanding IF-MAP Server Replicas
You can configure an IF-MAP server to replicate all of its IF-MAP data to other IF-MAP
servers. For example, if you have a network in Boston and a network in London, you can
run IF-MAP servers in both places and configure the IF-MAP servers in both locations to
replicate data to one another. These connected IF-MAP servers are known as replicas.
NOTE: A Release 4.0 (or later) IF-MAP server cannot perform replication
with a Release 3.x IF-MAP server.
Each replica communicates bidirectionally with all of the connected IF-MAP server
replicas so that the data on each IF-MAP server is available on every server. This
configuration can result in improved performance.

An IF-MAP server can have several replicas. For example, Figure 103 on page 464 shows
different Policy Secure gateways and a Connect Secure gateway connected to multiple
IF-MAP servers. An endpoint that accesses a Policy Secure gateway or the Connect
Secure gateway can access protected resources behind any of the Policy Secure
gateways depicted.
Figure 103: Replication of IF-MAP Servers
You configure separate replica settings on each IF-MAP server to allow

cross-communication between replicas. Replica settings include the IP address of the
replica and authentication parameters.
Bandwidth issues determine the effectiveness of the entire IF-MAP Federation’s operation.
A key to timeliness is that IF-MAP servers should generally be placed geographically
close to IF-MAP clients to ensure the most efficient operation. Replicas in an IF-MAP
federated network allow user session data to be shared over greater distance. For
example, the user in Boston can connect with servers in London via the replicated IF-MAP
server in London. An IF-MAP federation can have up to four IF-MAP servers or
active/passive IF-MAP server clusters located in other parts of the world.
IF-MAP servers (including clusters) communicate with each other over SSL. There are
two connections between each pair of IF-MAP servers, and each server initiates a
connection to the other.
To clear and repopulate the database on an IF-MAP replica, select No IF-MAP.
Related Configuring IF-MAP Server Replicas on page 465

Documentation
 Understanding Clustering in a Federated Deployment on page 465


Configuring IF-MAP Server Replicas
To configure IF-MAP server replicas to communicate:
1. In the admin console, select System > IF-MAP > This Server.
2. Click the Replicas tab. Then select New IF-MAP replica to configure Replica settings.
3. Type a Name for the replica IF-MAP server.
4. (Optional) Enter a Description for the replica or replica network.
5. For Hostname, enter the hostname that exactly matches the replica’s device certificate.
This is used when this IF-MAP server initiates a connection to the replica Use the fully
qualified domain name (FQDN) of the replica's internal or external interface should
be used; for a cluster, use the FQDN of the internal or external VIP.
6. After IP addresses, provide one or more IP addresses from which the replica can initiate
connections to this server. If the replica is standalone, for survivability list both the
internal and external network interfaces. If the replica is a cluster, for survivability list
the internal and external network interfaces of both cluster nodes.
7. Select the Authentication method: Basic or Certificate.
a. For Basic, enter a username and password.
b. For Certificate, select the CA that issued the IF-MAP replica’s certificate. Enter
restrictions, one per line. If any restrictions match, (for example
CN=ic.example.com), the certificate is accepted.
8. Click Save Changes to create the connection for the replica.
Related Understanding IF-MAP Server Replicas on page 463

Documentation

Understanding Clustering in a Federated Deployment
This topic provides an overview of clusters in a federated deployment. You can deploy
clustered Policy Secure gateways as IF-MAP servers, and you can deploy clustered
Policy Secure gateways or Connect Secure gateways as IF-MAP clients. This topic
 IF-MAP Server Clustering on page 465

 IF-MAP Client Clustering on page 467
IF-MAP Server Clustering

You can configure IF-MAP servers in an active/passive cluster. IF-MAP clients must be
configured with the cluster’s virtual IP (VIP) and must communicate with only the active
node.
You can also use clustered Policy Secure gateways as server replicas.

Figure 104 on page 466 illustrates a complex network of clustered and standalone Policy
Secure gateways.
Figure 104: IF-MAP Server Clustering
The active node and the passive node IF-MAP servers must establish a trust model. You
can either import the self-signed certificate of the passive node, or a CA-generated device
certificate and the CA or intermediary for that CA into the active node.
NOTE: If you install an internal device certificate on an IF-MAP server cluster

(rather than accepting the original self-signed internal certificate), you must
add the CA that issued that certificate as a trusted server CA. Otherwise,
IF-MAP data will not get replicated from the active to the passive node.
Session changes in Federation cluster networks are propagated rapidly. Clients can
access resources without experiencing delays, and there is no single point of failure. If
any single device fails, the passive node recovers in seconds.
With IF-MAP server clustering, up to eight Policy Secure gateways can be deployed in a
configuration with each replica in the cluster using both the internal and external ports
to accept traffic. In this clustering configuration, up to ten IP addresses should be added
in the replica Hostnames namespace: the cluster VIP the internal VIP, and the IP addresses
of each internal and external interface.
When an IC or SA cluster publishes data to an IC acting as an IF-MAP server, the

Authenticated-By address viewable in the Federation-wide sessions display is the address
of one node of the cluster. However, it is not necessarily the node that performed the
authentication. The access device compares the addresses in host byte order. The access
device selects one IP address and uses it consistently, until and unless a node is added
to or removed from the cluster.

IF-MAP Client Clustering

In a cluster of Policy Secure gateway IF-MAP clients, you configure a cluster as a single
IF-MAP client with internal and external IP addresses for each member. In an
active/passive cluster, there is no need to enter the cluster VIP, because the individual
Policy Secure gateways IP addresses are used.
One node of the cluster at a time can connect to the IF-MAP server and performs all of
the importing and exporting of sessions for the cluster.
Related Understanding IF-MAP Server Replicas on page 463

Documentation
 Configuring IF-MAP Server Replicas on page 465

Understanding Coordinated Threat Control in a Federated Deployment
You can use Juniper Networks IDP Series Intrusion Detection and Prevention Appliance
with Federation to detect attacks from within the network. Any endpoint that is on any
connected Policy Secure gateway or Connect Secure gateway can be monitored for
suspect activity. IF-MAP clients can work together to provide coordinated threat
control across all attached enforcement points.
Endpoints running Network Connect that access a Connect Secure gateway can be
monitored by standalone IDP. Endpoints that access a Policy Secure gateway can be
monitored by either standalone IDP, Integrated Security Gateway Intrusion Detection
and Prevention ISG-IDP, or SRX Series Services Gateway IDP.
The IDP device reports attacks to the Policy Secure gateway or Connect Secure gateway
to which it is connected. The Policy Secure gateway or Connect Secure gateway
configured as an IF-MAP client reports the user’s activity to the IF-MAP server using IF-
MAP. The IF-MAP server notifies the authenticating Policy Secure gateway or Connect
Secure gateway about the attack, and the authenticating device applies its IDP sensor
policies. If new roles or restrictions are imposed on the endpoint based on policies
configured on the device, the Policy Secure gateway or the Connect Secure gateway
publishes the new session information for the endpoint to the IF-MAP server.
When any other Policy Secure gateway or Connect Secure gateway polls the IF-MAP
server, the newly published session information for the user determines the protected
resources that the user can access.
See the Pulse Policy Secure Administration Guide.
Figure 105 on page 468 demonstrates a configuration with IDP incorporated.

Figure 105: IF-MAP Federation in a Heterogeneous Network with IDP
The following steps summarize the interaction with IDP in an IF-MAP federated network.
1. The endpoint successfully accesses Policy Secure gateway or Connect Secure

gateway 1 and publishes session data to the IF-MAP server through Session-Export
policies.
2. The endpoint attempts to access protected resources behind the Infranet Enforcer,
which is connected to Policy Secure gateway 3. Policy Secure gateway 3 uses IF-
MAP to query the IF-MAP server for session information about the endpoint. After
receiving session information, Policy Secure gateway 3 uses Session-Import
policies to determine roles and then provisions an auth table entry on the Infranet
Enforcer. Policy Secure gateway 3 subscribes to updates about the endpoint’s
session data.
3. After the endpoint is successfully connected to resources behind the Infranet Enforcer,
IDP detects an attack originating from the endpoint.
4. IDP notifies Policy Secure gateway 2 of the attack. (If IDP is standalone IDP, Policy
Secure gateway 2 could also be a Connect Secure gateway. If IDP is an Infranet
Enforcer with the ISG-IDP security module, Policy Secure gateway 2 cannot be a
Connect Secure gateway, because the Connect Secure gateway does not
communicate with the Infranet Enforcer.)
5. Policy Secure gateway 2 updates the endpoint session data on the IF-MAP
server with information about the attack.
6. The IF-MAP server notifies Policy Secure gateway 1 or Connect Secure gateway 1
(the original authenticating device) about the attack. The authenticating Policy
Secure gateway or Connect Secure gateway is responsible for consuming the
attack.
7. The authenticating Policy Secure gateway or Connect Secure gateway applies its
sensor policies to the endpoint and updates the endpoint’s session according to
actions specified in the sensor policies. For example, the endpoint must be assigned
a more restrictive role. The Policy Secure gateway or Connect Secure gateway
publishes the new session information to the
IF-MAP server, and the new information replaces the old data.
8. The IF-MAP server notifies any Policy Secure gateways that subscribe to updates

about the endpoint. This includes Policy Secure gateway 3, which is connected to
the Infranet Enforcer.

9. Policy Secure gateway 3 applies Session-Import policies to the new session data
for the endpoint and pushes the resulting roles to the Infranet Enforcer.
10. If the new set of roles denies access to the protected resources, access is denied.
Related Using IDP Devices in a Federated Deployment on page 469

Documentation

Using IDP Devices in a Federated Deployment
This example details how to configure two Policy Secure gateway clusters with an ISG-
IDP device to provide protection in an IF-MAP federated network.
1. Configure data center 1 active/passive cluster as an IF-MAP server. Data center 1

resources are protected with an ISG-IDP Infranet Enforcer.
2. Configure data center 2 active/passive cluster as an IF-MAP client connected to data

center 1.
3. Configure source IP policies on the data center 1 Enforcer for users who need access
to protected resources, including users whose sessions are federated from data center
2.
4. Configure the IDP sensor to communicate with the Policy Secure gateway in data
center 1. Make addresses to monitor on the IC Series Appliances in data center 1 to
include IP addresses from users from data center 2.
5. Configure sensor event policies on each IC in the network. Configure the sensor event
policy on the IC Series appliance through which users are authenticated. Each
authenticating IC or SA needs to have sensor event policies configured, even if the
authenticating device does not connect directly to a sensor.
When a user successfully accesses data center 1 and attempts to access resources on
data center 2, the user's session is published to the IF-MAP server. The data center 2 IC
appliance subscribes to the session information. If the user launches an attack, the IDP
rules configured on data center 1 are applied.
Related Understanding Coordinated Threat Control in an Federated Deployment on page 467

Documentation

Using IF-MAP Enabled Network Equipment
You can incorporate IF-MAP enabled network equipment in a Pulse Secure IF-MAP
network. For example, you can use an IF-MAP enabled DHCP server.
With OAC or Pulse, endpoints that authenticate at Layer 2 can access resources protected
by Infranet Enforcers because the Policy Secure gateway learns the IP address of the
endpoint from the client. Non-Pulse Secure supplicants do not communicate their IP
addresses directly to the Policy Secure gateway.
You can set up an IF-MAP compatible DHCP server in your distributed network to provide
IP addresses for non-Pulse Secure 802.1X supplicants to permit these clients to access
resources protected by an Infranet Enforcer.

The non-Pulse Secure supplicant accesses the Policy Secure gateway using 802.1X
without an IP address, and the Policy Secure gateway IF-MAP client publishes the
session data to the IF-MAP server. The session data includes the MAC address of the
endpoint, which is obtained from the Calling-Station ID of the RADIUS access request
during 802.1X authentication.
When the authenticated endpoint requests an IP address from the DHCP server, the
IF-MAP enabled DHCP server responds by provisioning an IP address for the endpoint.
The DHCP server (an IF-MAP client) publishes the IP address along with the MAC address
to the IF-MAP server. The IF-MAP server then sends the IP and MAC association to the
Policy Secure gateway IF-MAP client that authenticated the endpoint. The
authenticating Policy Secure gateway, or any other Policy Secure gateway in the
network, can then provision an auth table entry to an Infranet Enforcer based on the IP
address obtained from the IF-MAP server.
Always configure NADs to send RADIUS accounting stop requests to the Policy Secure
gateway when an endpoint disconnects. If the NAD is not configured correctly there is a
potential security concern.
The accounting stop request ensures that when the endpoint disconnects, the session
is terminated immediately. The auth table entry is removed from the Infranet Enforcer.
An endpoint’s DHCP lease typically lasts until the lease times out, leaving the potential
for an attacker to pose as the legitimate user by employing the IP address of the unexpired
DHCP lease to access restricted resources.
Related Understanding Federated Deployments on page 443

Documentation


CHAPTER 13
Sign-in Policies

 Task Summary: Configuring Sign-In Policies on page 472
 About Configuring Sign-In Policies on page 473
 Configuring Administrator Sign-In Policies on page 474
 Associating Authentication Realms and Protocols with User Sign-in Policies on page 475
 Before Configuring Sign-In Policies on page 479
 Configuring and Implementing Sign-In Notifications on page 483
 Configuring Sign-In Pages on page 485
About Sign-In Policies
Sign-in policies define both the URLs that users and administrators use to access the
Policy Secure gateway and the sign-in pages that they see. The Policy Secure gateway
has two types of sign-in policies—one for users and one for administrators. When you
configure sign-in policies, you associate realms, sign-in pages, and URLs that are
provided for users when they first log in to the Policy Secure gateway.
To allow users to sign in to the Policy Secure gateway, you add user authentication
realms to sign-in policies. You can associate realms with a variety of authentication
protocols to accommodate different types of endpoints. For example, a Pulse Secure
client (OAC or Pulse), IP phones, and non-Pulse Secure 802.1X supplicants can access
the Policy Secure gateway, but each of these endpoints might require different
authentication protocols.

NOTE: You can create multiple sign-in policies to enable different users to
sign in to different URLs and pages. When you configure a sign-in policy, you
associate it with a sign-in URL, a sign-in page, one or more realms, and an
authentication protocol set. Only members of the specified authentication
realm may sign in using the URL defined in the policy.
When you define sign-in policies, you can use different hostnames (such as
users1.yourcompany.com and users2.yourcompany.com) or different paths
(such as yourcompany.com/users1 and yourcompany.com/users2) to
differentiate between URLs.
For Windows systems, you can display different sign-in pages for users based
on whether or not you want the endpoint to download OAC or Pulse.
You specify whether you want the Policy Secure gateway to install OAC,
Pulse, the Java agent, or agentless access on endpoints at the role level. If
you use
role-mapping to associate roles with specific realms, you can specify which
users get OAC or Pulse installed and which users do not, and you can specify
the associated message that each group views on the sign-in page.
For example, if you have contract employees with noncompany machines

onto which you do not want to install a Pulse Secure client, you can create two
roles: one that allows agentless access and another requiring installation of
OAC or Pulse. Then you can create two associated realms: one for agentless
access and one for the Pulse Secure client. Add role-mapping rules based on
usernames to assign the contract employees to the agentless role, and
employees to the Pulse Secure client role. When a user attempts to log in,
they are assigned to a role that either provisions agentless access or installs a
Pulse Secure client.
You can associate the different realms with different sign-in policies and
sign-in pages, so users who login to a resource can see a sign-in page based
on whether or not they are a regular employee or a contractor.
Related Task Summary: Configuring Sign-In Policies on page 472

Documentation

Task Summary: Configuring Sign-In Policies
User sign-in policies determine the realm that users and administrators can access.
Depending on whether a sign-in policy is for endpoints (users) or administrators, the

configuration options differ. For users, alternate authentication protocol sets can be
configured, and realm selection is based on the authentication method that is associated

Chapter 13: Sign-in Policies
with the realm. In most applications, configuring authentication protocol sets is not
required.
To configure sign-in policies:
1. In the admin console, select Administrators > Admin Realms or the Users > User Realms
to create an authentication realm.
2. (Optional) To modify an existing sign-in page or create a new one using options, select
Authentication > Signing In > Sign-in Pages.
3. (Optional) Create a new authentication protocol set to associate with the realm. This
step is necessary only if the realm is required to provide access for a non-UAC
supplicant (for example, Microsoft Vista with a Statement of Health Host Checker
policy). For users authenticating with OAC, Pulse, the Java agent for Linux clients, or
agentless access, use the default 802.1X protocol set.
4. Select Authentication > Signing In > Sign-in Policies and specify a sign-in policy that
associates a realm, sign-in URL, and sign-in page.
5. If you differentiate between URLs using hostnames, you must either associate each
host name with its own certificate, or upload a wildcard certificate into the Policy
Secure gateway using options. Select System > Configuration > Certificates > Device
Certificates.
Related About Sign-In Policies on page 471

Documentation

 Configuring Sign-In Pages on page 485
About Configuring Sign-In Policies
User sign-in policies determine the realm that users and administrators can access.
Depending on whether a sign-in policy is for endpoints (users) or administrators, the

configuration options differ. For users, alternate authentication protocol sets can be
configured, and realm selection is based on the authentication method that is associated
with the realm. In most applications, configuring authentication protocol sets is not
required.
Related Configuring Administrator Sign-In Policies on page 474

Documentation


Configuring Administrator Sign-In Policies
1. In the admin console, select Authentication > Signing In > Sign-in Policies.
2. To create a new sign-in policy, click New URL. To edit an existing policy, click a URL in
the Administrator URLs or the User URLs column.
3. To create an administrator sign-in policy, select the Administrators option button at

the top of the page. (By default, the Users option button is selected.)
4. In the Sign-in URL field, enter the URL to associate with the policy. Use the format
<host>/<path> where <host> is the hostname of the Policy Secure gateway, and
<path> is any string users must enter. For example: users1.yourcompany.com/ic. To
specify multiple hosts, use the asterisk (*) wildcard character. For instance:
To specify that all administrator URLs must use the sign-in page, enter */admin.
NOTE: Use wildcard characters (*) only at the beginning of the hostname
portion of the URL. The Policy Secure gateway does not recognize
wildcards in the URL path.
5. (Otional) Enter a Description for the policy.
6. From the Sign-in Page list, select the page that you want to associate with the policy.
You can select the default page that comes with the Policy Secure gateway, a
variation of the standard sign-in page, or a custom page that you create using the
customizable UI feature.
7. For administrator sign-in policies, under Authentication realm, specify which realm
maps to the policy, and how users and administrators must choose from among
realms. If you select:
 User types the realm name—The Policy Secure gateway maps the sign-in policy
to all authentication realms but does not provide a list of realms from which the
administrator can choose. Instead, the administrator must manually enter the realm
name into the sign-in page.
 User picks from a list of authentication realms—The Policy Secure gateway maps
the sign-in policy to only the authentication realms that you choose. The Policy
Secure gateway presents this list of realms when the administrator signs-in to the
Policy Secure gateway and allows a realm to be chosen from the list. (Note that
the Policy Secure gateway does not provide a list of authentication realms if the
URL is mapped only to one realm. Instead, only the realm you specify is displayed).
8.
9. Click the Add button to add available realms to the Selected realms box.
Related Before Configuring Sign-In Policies on page 479

Documentation


Associating Authentication Realms and Protocols with User Sign-in Policies
Different types of endpoints can request authentication through the Policy Secure
gateway including UAC agents, third-party 802.1X supplicants (including 802.1X IP
phones), switches, and endpoints that request authentication with agentless access.
A UAC agent is software that can use the JUAC protocol. UAC agents include OAC,
Pulse, and the Java agent. By default, the Policy Secure gateway can communicate
with UAC agents, the Java agent, and endpoints with agentless access. To
accommodate other types of endpoint clients, you might need to create
authentication protocol sets within sign-in policies.
When you add a realm in a sign-in policy, you select an authentication protocol set to be
used with that realm. There are two default authentication protocol sets. For UAC agents,
use the default 802.1X authentication protocol set. For 802.1X IP phones, use the default
802.1X-Phones protocol set.
Third-party 802.1X supplicants cannot use the preconfigured 802.1X protocol set that is
used by default with UAC agents. For example, some switches can request authentication
using CHAP or EAP-MD5-Challenge. You must define a specific authentication protocol
set for these requests.
To define an endpoint’s authentication method, you add authentication realms to sign-in

policies. You configure authentication protocol sets as required, based on authentication
methods that are compatible with the authentication server that you are using. The
Policy Secure gateway maps the sign-in policy to the authentication realms that you
choose. Users who sign in using the URL that you provide have access only to those
realms that you specify.
For non-UAC agents, you must select the protocols that the client and the authentication
server are compatible with. See Table 55 on page 475 for details of what authentication
protocols are compatible with different authentication servers.
Table 55: RADIUS Sub-Protocols and Compatible Authentication Servers
Authentication Servers
Protocols Certificate Local LDAP Active ACE Mac

Directory Auth
EAP-GTC - - - - Y -
PAP - Y Y Y Y -
CHAP, - Y Y - - -
EAP-MD5-Challenge
MS-CHAP - Y Y Y –

Table 55: RADIUS Sub-Protocols and Compatible Authentication

Servers (continued)
Authentication Servers
MS-CHAP-V2, - Y Y Y - -
EAP-MS-CHAP-V2
EAP-TLS Y - - - - -
Mac-based auth - - - - - Y
EAP-JUAC Y Y Y Y Y -
NOTE: For 802.1X, AD authentication server used as LDAP is not supported

for the following protocols: MS-CHAP, MS-CHAP-V2, and EAP-MS-CHAP-V2.
The decision of what realms are available to the user within a sign-in policy is based on
two factors. First, the order of realms in the list is considered. Realms at the top of the
list are attempted. Second, the authentication protocol set that you choose must be
compatible with the client or supplicant.
To determine a compatible realm, the Policy Secure gateway looks for a RADIUS
subprotocol that is compatible with the client or supplicant’s available protocols, and
the Policy Secure gateway automatically selects compatible realms. If the endpoint is
using a UAC agent, the Policy Secure gateway presents a list of realms. Any realm with
both outer and inner protocols that match the outer and inner protocols on the client is
considered compatible.
Protocol compatibility does not guarantee authentication. For example, CHAP and
EAP-MD-5 challenge sign-in succeeds only if the stored password is retrievable as
cleartext. In addition, if the client or supplicant is configured with a non-JUAC protocol
(for example, the Windows Vista supplicant), the Policy Secure gateway searches for a
realm without TNC Host Checker restrictions, browser restrictions, or certificate
restrictions.
NOTE: If you are configuring a realm for a Windows client, with a Statement
of Health Host Checker policy, you must use an authentication protocol set
with the EAP-SOH protocol. When you select EAP-SOH in an authentication
protocol set, EAP-SOH is always offered first, regardless of protocol ordering.
If an endpoint is using UAC agent software, the Policy Secure gateway presents the list
of realms to the user or administrator when the user signs in to the Policy Secure
gateway and allows the user to choose a realm from the list. The Policy Secure
gateway does not display a list of authentication realms if the URL is mapped only to
one realm. Instead, it automatically uses the realm you specify.
For endpoints that use a non-UAC agent, you can select the User may specify the realm
name as a username suffix check box. When the user provides a username with a suffix

in the format user@realm, the suffix determines the realm assignment. If you do not
select this option, the endpoint is assigned to the first realm in the list whose
authentication server is a match with the endpoint’s software. For example, if the
endpoint’s software is configured for tokens (EAP-Generic Token Card), and if the sign
in policy permits EAP-GTC, the endpoint is assigned the first realm in the list whose
authentication server supports tokens.
When an 802.1X IP phone connects to the Policy Secure gateway through a realm
with the 802.1X-Phone protocol set selected, the device is automatically directed to
the proper realm for authentication based on the compatible protocol.
If you are using inner or outer RADIUS proxy with a selected realm, routing with respect
to authentication protocols is different. The Policy Secure gateway forwards all traffic to
a proxy target, which rejects protocols it does not support. With an outer proxy realm,
the Policy Secure gateway ignores the authentication protocol set. For an inner proxy
realm, the authentication protocol set directs the Policy Secure gateway as it negotiates
the outer protocol (EAP-PEAP or EAP-TTLS) but does not affect the inner protocol.
Figure 106 on page 477, Figure 107 on page 478, and Figure 108 on page 479 illustrate the
realm selection process.
Figure 106: Realm Selection, Phase 1



Documentation

Before Configuring Sign-In Policies
Topic Details

Wildcard characters in host name Use wildcard characters (*) only at the beginning of the host name
portion of the URL. The Policy Secure gateway does not recognize
wildcards in the URL path.
OAC or Pulse sign in Endpoints that use OAC or Pulse with Layer 3 access the sign-in-page
for the initial login. After clients are assigned a role, and provisioned with
the client, subsequent authentication requests are performed through
the client.
Outer proxy realms If you are configuring an outer proxy realm, you do not have to specify
an authentication protocol set, and not Applicable should be used as
the authentication protocol.
Anonymous authentication servers If you allow a user to select from multiple realms, and one of those
realms uses an anonymous authentication server, the Policy Secure
gateway does not display that realm in the realm list. To effectively
map your sign-in policy to an anonymous realm, add only that realm
to the Authentication realm list.
If you attempt to add more than one realm where one realm uses
anonymous auth, the Policy Secure gateway presents an error message:
"Unable to create new sign-in URL: cannot select both anonymous and
non-anonymous realms."
Username suffixes By default, the User may specify the realm name as a username suffix
check box is not selected. If you choose this option, non-UAC endpoints
access the Policy Secure gateway by entering their credentials in the
format user@realm.
Proxy realm sign-in If you configure a sign-in policy with multiple realms, and one of the
realms is a proxy realm, the user must append a suffix to the username
to access the proxy realm.
Related  Configuring and Managing Sign-In Policies on page 480

Documentation
 Task Summary: Configuring Sign-In Policies on page 472
Configuring and Managing Sign-In Policies
This topic describes how to configure and manage user sign-in policies. It includes the
 Configuring User Sign-In Policies on page 480

 Enabling and Disabling Sign-in Policies on page 481
 Specifying the Order of Evaluation on page 481
Configuring User Sign-In Policies

To create or configure user sign-in policies:
2. To create a new sign-in policy, click New URL. To edit an existing policy, click a URL in
the Administrator URLs or User URLs column.

3. In the Sign-in URL field, enter the URL that you want to associate with the policy. Use
the format <host>/<path>, where <host> is the host name of the Policy Secure
gateway, and <path> is any string users must enter. For example:
users1.yourcompany.com/ic. To specify multiple hosts, use the asterisk (*) wildcard
character. For example, to specify that all end-user URLs must use the sign-in
page, enter */.
4. Under Authentication realm, specify the realms that must be mapped to the sign-in
policy. Under Available realms, select realms from the menu. The Policy Secure
gateway maps the sign-in policy only to the authentication realms that you add.
5. Under Authentication protocol set, select an authentication protocol set that you have
configured previously. If endpoints will connect with a UAC agent, select the default
802.1X protocol set. The protocol set used with a realm must be compatible with the
authentication server that is associated with the realm.
6. Click Add to add the new realm and authentication protocol pair.
7. Select the User may specify the realm name as a username suffix check box to allow
non-UAC endpoints to access the Policy Secure gateway by entering their credentials
(in the format user@realm).
8. Select the Remove realm suffix before passing to authentication server check box for
users to enter their credentials with a suffix to send the username without the suffix.
Most authentication servers are not compatible with a realm suffix or decorated
username.
Enabling and Disabling Sign-in Policies

To enable and disable sign-in policies:
2. To enable or disable:
 An individual policy—Select the check box for the policy that you want to change.
Then click Enable or Disable.
 All user policies—Select or clear the Restrict access to administrators only check
box at the top of the page.
Specifying the Order of Evaluation

The Policy Secure gateway evaluates sign-in policies in the same order that you list
them on the Sign-in Policies page. When it finds a URL that matches exactly, it stops
evaluating and presents the appropriate sign-in page to the administrator or user. For
example, for 2 administrator sign-in policies with different URLs:
 The first policy uses the URL */admin and maps to the default administrator sign-in
page.

 The second policy uses the URL yourcompany.com/admin and maps to a custom
administrator sign-in page.
If you list the policies in this order on the Sign-in Policies page, the Policy Secure
gateway never evaluates or uses the second policy because the first URL encompasses
the second one. Even if an administrator signs in using the yourcompany.com/admin
URL, the Policy Secure gateway displays the default administrator sign-in page. If you
list the second policy first, however, the Policy Secure gateway displays the custom
administrator sign-in page to administrators who access the Policy Secure gateway
using the yourcompany.com/admin URL.
Note that the Policy Secure gateway accepts only wildcard characters in the hostname
section of the URL and matches URLs based on the exact path. For example, two
administrator sign-in policies with two different URL paths:
 The first policy uses the URL */marketing and maps to a custom sign-in page for the
entire Marketing Department.
 The second policy uses the URL */marketing/joe and maps to a custom sign-in page
designed exclusively for Joe in the Marketing Department.
If you list the policies in this order on the Sign-in Policies page, the Policy Secure gateway
displays Joe’s custom sign-in page to him when he uses the
yourcompany.com/marketing/joe URL to access the Policy Secure gateway. He does not
see the Marketing sign-in page, even though it is listed and evaluated first, because the
path portion of his URL does not exactly match the URL defined in the first policy.
To change the order in which administrator sign-in policies are evaluated:
2. Select a sign-in policy in the Administrator URLs or User URLs list.
3. Click the up or down arrow to change the selected policy’s placement in the list.
Related Before Configuring Sign-In Policies on page 479

Documentation

Using Sign-In Notifications
With sign-in notifications, you can create and configure detailed notification messages
that appear for Pulse clients and for agentless access endpoints when the user attempts
to sign in. For example, you could configure a notification message that explains terms
of use, company-specific policies, a welcome page, an end user license agreement
(EULA), or a message of the day (MOTD).
For a browser-based (agentless) login, the notification message appears in a separate

page either before (pre-auth) or after (post-auth) user authentication during the sign-in
process. For a Pulse client login, the notification messages appear in a Pulse message
box. The user is expected to read the content of the sign-in notification message and

acknowledge by clicking a Proceed button. The user may indicate disagreement by clicking
a Decline button, which ends the login attempt.
You can configure a sign-in policy to use a sign-in notification either as pre-auth or
post-auth (or both). In the case of post-auth configuration, you can either use a common
message for all roles or use separate messages for each role.
You can create a multi-language sign-in notification package that relies on the language
setting of the endpoint. You can customize the sign-in notification page appearance for
browser-based logins by modifying the related fields in a sign-in page in the Admin UI or
by using a custom sign-in page.
Notes:
 Sign-in notifications are supported on Windows, Mac, and for browser-based access
on mobile devices. However, sign-in notifications might not work well with all mobile
devices due to device limitations.
 Sign-in notifications (including uploaded packages) are included in XML exports.
 If a Pulse session is resumed or extended, the pre-auth notification message is not

shown again. However, if the user switches roles when resuming a session, and that
role change results in a new notification, Pulse displays the message. You can configure
the post-auth message to be skipped if it has already been seen. If the post-auth
message is not marked to be skipped, then it always appears.
Related Specifying UI Options for Agentless Access on page 271

Documentation

 Configuring and Implementing Sign-In Notifications on page 483
Configuring and Implementing Sign-In Notifications
Sign-in notifications appear for Pulse client and for browser-based logins when the user
attempts to sign in.
To configure and implement sign-in notifications:
1. In the admin console, select Authentication > Signing In > Sign-in Notifications.
2. Click New Notification.
3. Specify a Name for the notification. This name appears in the sign-in policies page,
and in the UI Options page for a selected role.
4. Select Text or Package in the Type box.
 If you select Text, type the desired sign-in notification message, or copy and paste
the relevant text into the Text field.
 If you select Package, click the Browse button and navigate to a previously prepared
.zip file. A package is typically used to provide different language versions of the
notification message.

 The zip file should include a default.txt file and one or more <language>.txt files
(Example: en.txt).
 Language-abbreviations should be strings that can appear in Accept-Language

header of an HTTP request.
 The character encoding supported is UTF-8.
NOTE: When you create a zip file, do not add the folder containing
the files, but add the files directly.
To enable sign-in notifications:
1. In the admin console, click Authentication > Signing In > Sign-in Policies.
2. Under Configure Sign-in Notifications, select the check box for Pre-Auth Sign-in
Notification, Post-Auth Sign-in Notification, or both.
 After Pre-Auth Sign-in Notification, select a previously configured sign-in notification

from the drop-down menu.
 After Post-Auth Sign-in Notification, select the option for Use a common Sign-in
Notification for all roles or Use the Sign-in Notification associated to the assigned
role.
 If you select Use a common Sign-in Notification for all roles, select a previously
configured sign-in notification from the drop-down menu.
 If you select Use the Sign-in Notification associated to the assigned role, the sign-in
notification configured for the assigned role will be used.
 Prevent the Post-Auth sign-in notification from being displayed to users who have
seen it before, by selecting the Skip if already shown check box. (This is only a hint
to the system and might not be honored in all environments.)
4. You can customize the appearance of the sign-in notification message by selecting
Authentication > Signing In > Sign-in Pages and creating a sign-in page or using an
existing page.
5. Under Sign-in Notification appearance, customize UI options for Pre-Auth Notifications

and Post-Auth Notifications by changing the following items:
 For Notification Title enter the text that appears at the top of the sign-in notification
page.
 In the Proceed Button box, enter the text for the button that the user clicks to proceed
with the sign-in.
This text applies to browser-based logins only. A Pulse client login always displays
Proceed.

 Optionally, clear the check box for Display “Decline” Button. If this box is not checked,
the user does not have the option to decline.
 In the Decline Button box, enter the text for the button that the user clicks to decline.
This text applies to browser-based logins only. A Pulse client login always displays
Decline.
 In the Message on Decline box, enter the text that you would like to appear when a
user clicks the Decline button.
NOTE: If you enabled Use the Sign-in Notification associated to the assigned
role you must complete the implementation by selecting the sign-in
notification on the Users > User Roles > Role Name > General > UI Options
page or Administrators > Admin Roles > Role Name > General > UI Options
page, as applicable.
If more than one role is available to a user, the sign-in notification

associated with the first role assigned is displayed.
7. Add the sign-in page in which you have customized the sign-in notification appearance
to the sign-in policy.
Related Specifying UI Options for Agentless Access on page 271

Documentation

Configuring Sign-In Pages
This topic describes how to configure sign-in pages. It includes the following information:
 Sign-In Page Options on page 485

 Configuring Standard Sign-In Pages on page 486
Sign-In Page Options

A sign-in page defines the customized properties in the end-user’s welcome page such
as the welcome text, help text, logo, header, and footer. The Policy Secure gateway
allows you to create two types of sign-in pages to present to users and administrators:
 Standard sign-in pages—Standard sign-in pages are included with all versions of the
Policy Secure gateway. You can modify standard sign-in pages by selecting
Authentication > Signing In > Sign-in Pages in the admin console.
 Customized sign-in pages—Customized sign-in pages are THTML pages that you
produce using the Template Toolkit and upload to the Policy Secure gateway in the
form of

an archived ZIP file. The customized sign-in pages feature enables you to use your own
pages rather than modify the sign-in page included with the Policy Secure gateway.
Configuring Standard Sign-In Pages

You can modify the default sign-in page that the Policy Secure gateway displays at
sign-in. You can also create new standard sign-in pages that contain custom text, logo,
colors, and error message text.
To create or modify a standard sign-in page:
1. In the admin console, select Authentication > Signing In > Sign-in Pages.
2. If you are:
 Creating a new page—Click New Page.
 Modifying an existing page—Select the link for the page you want to modify.
3. Enter a name to identify the page.
4. In the Custom text section, revise the default text used for the various screen labels.
When you add text to the Instructions field, you can format text and add links using
the following HTML tags: , , , , and <ahref>. However, the Policy
Secure gateway does not rewrite links on the sign-in page (because the user has not
yet been authenticated), so point only to external sites. Links to sites behind a
firewall will fail.
might display the end-user’s Policy Secure gateway home page incorrectly.
5. (Optional) In the Header appearance section, specify a custom logo image file for the
header and a different header color.
6. (Optional) In the Custom error messages section, revise the default text that is
displayed to users if they encounter certificate errors.
You can include <<host>>, <<port>>, <<protocol>>, and <<request>> variables and
user attribute variables, such as <<userAttr.cn>> in the custom error messages. These
variables must be in the format <variable> to distinguish them from HTML tags that
have the format <tag>.
7. (Optional) To provide custom help or additional instructions for your users, select
Show Help button, enter a label to display on the button, and specify an HTML file to
upload to the Policy Secure gateway. Note that the Policy Secure gateway does not
display images and other content referenced in this HTML page.
8. Click Save Changes. The changes take effect immediately, but users with active
sessions might need to refresh their Web browser.
Click Restore Factory Defaults to reset the sign-in page, Policy Secure gateway user
home page, and admin console appearance.

Documentation


PART 3
Endpoint Defense
 Host Checker on page 489


CHAPTER 14
Host Checker
 Host Checker and Trusted Network Computing on page 490

 Host Checker Overview on page 492
 Task Summary: Configuring Host Checker on page 494
 Using Host Checker for Machine Account Logins on page 495
 Using the Predefined Enhanced Endpoint Security Option on page 496
 Checking for Third-Party Applications Using Predefined Rules on page 498
 Configuring a Predefined Antivirus Rule with Remediation Options (Windows and
Macintosh) on page 500
 Configuring a Predefined Firewall Rule with Remediation Options (Windows and
 Configuring a Predefined AntiSpyware Rule (Windows and Macintosh) on page 504
 Specifying Customized Requirements Using Custom Rules on page 505
 Using a Wildcard or Environment Variable in a Host Checker Rule on page 511
 Patch Management Info Monitoring and Patch Deployment on page 512
 Configuring Virus Signature Version Monitoring and Patch Assessment Info Monitoring
and Patch Deployment on page 515
 Configuring Patch Remediation Options on page 518
 Configuring Host Checker Patch Assessment Rules on page 518
 Using Third-Party Integrity Measurement Verifiers on page 520
 Configuring a Remote IMV Server on page 521
 Implementing a Third-Party IMV Policy on page 526
 Using Statement of Health Integration Host Checker Policies on page 527
 Configuring a Statement of Health Host Checker Policy on page 529
 Implementing Host Checker Policies on page 531
 Configuring Host Checker Restrictions on page 533
 Understanding Host Checker Policy Remediation on page 535
 Configuring General Host Checker Remediation on page 537
 Upgrading the Endpoint Security Assessment Plug-In on page 538

 Specifying General Host Checker Options on page 540

 Specifying Host Checker Installation Options on page 542
 Installing Host Checker Automatically or Manually on page 543
 Using Host Checker Logs on page 544
Host Checker and Trusted Network Computing
Host Checker is a client-side agent that performs endpoint health and security checks
for hosts that attempt to connect to the Policy Secure gateway. Host Checker is based
on open standards defined by the Trusted Computing Group (TCG).
Trusted Network Connect (TNC) is a subgroup of the TCG that created an architecture
and set of standards for verifying endpoint integrity and policy compliance during or after
a network access request. Many of the TCG members participated in the definition and
specification of the TNC architecture. The TNC defined several standard interfaces that
enable components from different vendors to securely operate together. The TNC
architecture is designed to build on established standards and technologies, such as 802
1X, RADIUS, IPsec, EAP, and TLS/SSL. For more information about TNC, see
www.trustedcomputinggroup.org. Using technology based on the TNC architecture and
standards, the Host Checker component of the Pulse Policy Secure solution provides a
comprehensive approach to assess the trustworthiness of endpoints.
You can use Host Checker to perform health and security evaluations on endpoints before
allowing them to connect to the Policy Secure gateway and to access protected
resources. Host Checker can check for third-party applications, files, process, ports,
registry keys, and custom DLLs on hosts. Based on the results of the checks, Host
Checker can deny or allow access to protected resources. For example, you can check
for virus detection software before allowing a user access to a Policy Secure gateway
realm. You can configure policies that launch the software on the user’s system, map
the user to roles based on individual policies defined in your own DLL, and then further
restrict access to individual resources based on the existence of spyware detection
software. When a user’s computer does not meet the requirements you specify, you can
configure options that display remediation instructions to users so they can bring their
computers into compliance.
NOTE: If you configure a large number of Host Checker policies, and the
Policy Secure gateway is under a heavy load, the server process inside the
device could get overloaded. When this happens, a message appears in the
event log (Log/Monitoring > Events > Log).
The Policy Secure gateway and Host Checker manage the flow of information between
the corresponding pairs of IMCs and IMVs. Each IMV on the Policy Secure gateway
works with the corresponding IMC on the client machine to verify that the client meets
the Host Checker rules.
You can also configure Host Checker to monitor third-party IMCs installed on client
computers by using third-party IMVs that can be installed on a remote IMV server.

Chapter 14: Host Checker
Host Checker supports TNC-based integrity measurement collectors (IMCs) and integrity
measurement verifiers (IMVs). IMCs are software modules that run on the host and collect
information such as antivirus, antispyware, patch management, firewall, and other
configuration and security information about the host. IMVs are software modules that
run on the Policy Secure gateway and verify a particular aspect of a host’s integrity.
Each IMV on the Policy Secure gateway works with the corresponding IMC on the host
to verify that the host meets the requirements of the integrity measurement custom
rules that you configure. IMCs scan the client machine frequently for changes in
security status. For example, if the user turns off virus checking, the IMC can detect
this and then trigger a new check to make sure the modified system complies with the
requirements of the Host Checker policy. You can configure Host Checker to monitor
third-party IMCs installed on client computers by using third-party IMVs that are
installed on a remote IMV server.
You can invoke Host Checker at the role level or the realm level to specify access
requirements for endpoints seeking authentication. Host Checker policies that are
implemented at the realm level occur before the user is authenticated. Host Checker
policies at the role level are implemented after authentication but before the user is
permitted to access protected resources.
The Host Checker component is built into OAC, Pulse, and the Java agent. A client-side
Host Checker application is downloaded for agentless access. Non-UAC agent clients
(the Windows native supplicant) can take advantage of Host Checker’s Statement of
Health (SOH) integration feature. OAC and Pulse are available client options with the
full UAC license. With the EGA (Enterprise Guest Access) license, users connect with
agentless access only.
There is no functional difference between OAC or Pulse TNC Host Checker component
and the Windows agentless Host Checker. OAC and Pulse Host Checker are included
with the installer, and agentless protection is installed through browser access.
Host Checker functionality for Macintosh (with or without OAC), Linux, and Solaris
platforms is limited.
Host Checker Compatibility

The TNC integrity measurement rules apply to Windows and Macintosh client machines
that are running either OAC or Host Checker (agentless), Windows machines with Pulse,
Macintosh with the Safari browser, and Linux and Solaris platforms using Firefox browser
with Java support. Windows and Macintosh Java Host Checker is not supported. .
Host Checker runs on agentless and Java agent endpoints, and OAC and Pulse include
a built-in Host Checker component. In this chapter, the name Host Checker refers to the
software that runs on agentless and Java agent endpoints and the built-in Host Checker
component that runs as part of OAC and Pulse.
You configure agentless Host Checker policies for guest access.
NOTE: To use Host Checker with Linux or Solaris, you must use the Firefox
browser.

You can also configure Statement of Health Host Checker policies to protect Windows
802.1X supplicants (Vista, XP with Service Pack 3, and Windows 7) that are authenticated
through 802.1X.
NOTE: Some Host Checker processes can take a long time. On Windows
endpoints, the user can view Host Checker progress.
You can see the Host Checker status for each active user on the Status > Active Users
page.
Related Host Checker Overview on page 492

Documentation

Host Checker Overview
The Policy Secure gateway can check hosts for endpoint properties using a variety of rule
types, including:
 Predefined rules that check for antivirus software and up-to-date virus signatures,
firewalls, malware, spyware, and specific operating systems from a wide variety of
industry leaders.
 (Windows machines only) Custom rules that use IMCs and IMVs to perform customized
client-side checks.
 (Windows machines only) Custom rules that check for third party DLLs that perform
customized clientside checks.
 (Windows machines only) Custom rules that check for ports, processes, files, registry
key settings, and the NetBIOS name, MAC addresses or certificate of the client machine.
 On Macintosh, Linux, and Solaris systems you can check for ports, processes, and files.
If the user’s computer does not meet Host Checker policy requirements, you can display
a custom remediation page to the user. This page can include specific instructions and
links to resources that can help the user bring the endpoint into compliance with the Host
Checker policy.
Upgrading the Software Version

If you upgraded UAC from a previous version, ensure that existing endpoints are upgraded
to the current version of the UAC agent before you configure Host Checker policies that
implement new features. Because the agent is required to connect and establish a session
with the server to perform an agent-based upgrade, the client must pass any Host Checker
restrictions required for a realm and roles to gain access.

If an endpoint with an older version of the UAC agent attempts to log in to the Policy
Secure gateway with a new Host Checker feature implemented at the realm level, the
user's authentication fails, and the endpoint cannot upgrade to the latest version of the
client.
If you implement new features before endpoints are upgraded, you must create a
remediation role that does not require any of the new features to allow users to
authenticate and download the current version of the client.
To ensure that endpoints are using the latest client, click Maintenance > System > Options
and then select either Enable automatic upgrade of Pulse Secure Clients or Enable automatic
upgrade of Odyssey Access Clients.
Related Creating Global Host Checker Policies on page 493

Documentation

Creating Global Host Checker Policies
To use Host Checker as a policy enforcement tool for managing endpoints, you create
Host Checker policies, and then implement the policies at the realm or role level.
The Policy Secure gateway provides options that you can use to enable, create, and
configure Host Checker policies:
 Pre-defined rules (check for third party applications on Windows machines)—Host

Checker contains a wide array of predefined rules that monitor antivirus software,
firewalls, malware, spyware, and specific operating systems from a variety of industry
leaders. You can enable one or more of these rules within a Host Checker client-side
policy to ensure that the integrated third-party applications that you specify are running
on users’ computers.
 Custom rules (check for additional requirements)—In addition to predefined rules,

you can create custom rules within a Host Checker policy to define requirements that
user endpoints must meet. Using custom rules, you can:
 Configure Host Checker to check for custom third-party DLLs that perform customized
client-side checks.
 Verify that certain ports are open or closed on the user’s computer.
 Confirm that certain processes are or are not running on the user’s computer.
 Verify that certain files are or are not present on the client machine.
 Evaluate the age and content of required files through MD5 checksums.
 Confirm that registry keys are set on the client machine (Windows only).
 (Windows only) Check the NetBIOS name, MAC addresses, or certificate of the client
machine.

 (Windows only) Assess the client operating system and application service packs
to ensure they are up to date.
 (Windows only) Perform application and version checks to ensure that endpoints
are running the correct software.
 Within a single policy, you can create different Host Checker requirements for Windows,
Macintosh, Linux and Solaris, checking for different files, processes, and products on
each operating system. You can combine any number of host check types within a
single policy and check for alternative sets of rules.
Related Task Summary: Configuring Host Checker on page 494

Documentation

Task Summary: Configuring Host Checker
NOTE: Ensure that user endpoints have signed ActiveX components or signed
Java applets enabled within their browsers to permit Host Checker to
download, install, and launch.
To configure a Host Checker policy:
1. In the admin console, select Authentication > Endpoint Security > Host Checker.
a. Under Policies, click New.
b. Enter a name in the Policy Name field. Then click Continue. (Users see this name
on the Host Checker remediation page if you enable custom instructions for this
policy.)
c. Create one or more rules to associate with the policy.
2. Configure additional system-level options:
 To display remediation information to users if users fail to meet the requirements

of a Host Checker policy, select Authentication > Endpoint Security > Host Checker.
 To change default Host Checker settings, select Authentication > Endpoint Security
> Host Checker .
3. Determine the level at which you want to enforce Host Checker policies:
 To enforce Host Checker policies when the user initially accesses the Policy
Secure gateway, implement the policy at the realm level select Users > User
Realms > Select Realm > Authentication Policy > Host Checker.
 To allow or deny users access to specific roles based on compliance with Host
Checker policies, implement the policies at the role level by using the Users > User
Roles > Select Role > General > Restrictions > Host Checker page of the admin
console.

 To map users to roles based on their compliance with Host Checker policies, select
Users > User Realms > Select Realm > Role Mapping and use custom expressions.
4. Specify how users can access the Host Checker client-side agent that enforces the
policies you define:
 Windows—If you enable OAC or Pulse installation, the Policy Secure gateway
automatically downloads the client with built-in Host Checker when the user first
accesses the Policy Secure gateway by means of a web browser. If you evaluate or
enforce a Host Checker policy at the realm level, The client automatically runs the
built-in Host Checker components on the endpoint to determine security
compliance. Host Checker functionality is the same on Pulse and OAC.
 Macintosh with OAC—Users can navigate to the Policy Secure gateway and
manually download and install the agent with the Host Checker component. After
the user installs the agent, Host Checker policies that you configured for the user’s
assigned roles or realms can be implemented.
 Platforms with Java agent or agentless deployments—To enable automatic

installation of the Host Checker component on agentless computers, you must
evaluate or enforce a Host Checker policy. To do so select Administrators > Admin
Realms > Select Realm > Authentication Policy > Host Checker page or the Users >
User Realms > Select Realm > Authentication Policy > Host Checker.
5. Determine whether you want to create client-side logs. If you enable client-side logging,
the Policy Secure gateway creates log files on your users’ systems and writes to the
file whenever OAC, Pulse, or Host Checker runs.
If more than one valid Policy Secure gateway session exists from the same system, and
Host Checker is used in those sessions, all valid sessions are terminated if a user signs
out from any of the sessions. To prevent this, turn off Host Checker for those sessions
that do not need Host Checker.
Related Host Checker and Trusted Network Computing on page 490

Documentation
 Using Host Checker for Machine Account Logins on page 495

Using Host Checker for Machine Account Logins
With OAC or Pulse, you can use a machine account configuration to authenticate a
physical machine, rather than a user. This type of configuration uses either a statically
defined user account or the machine credentials that were created when the machine
account was set up in Active Directory. For more information, see
or the Pulse Secure documentation.

If you use the machine account feature, do not configure restrictive Host Checker policies
that require human interaction for remediation, because these policies will fail. Instead,
configure a separate default role for machine accounts that fail Host Checker policies.
To allow the machine account to log in, you configure a special role for machines. You
can create a role-mapping policy that maps all machine roles to a realm that
automatically accepts your domain with a wildcard as a username (or example, “QA\*$”).

Documentation

Using the Predefined Enhanced Endpoint Security Option
This topic describes when and how to use the Host Checker Enhanced Endpoint Security
(EES) feature. It includes the following information:
 Enhanced Endpoint Security Option Overview on page 496

 Enhanced Endpoint Security User Experience on page 497
 Enabling the Enhanced Endpoint Security Option on page 498
Enhanced Endpoint Security Option Overview

Host Checker includes integrated antispyware functionality that can detect and remediate
Windows endpoints using OAC or Pulse. Enhanced Endpoint Security (EES) ensures that
malware, spyware, viruses, or worms are not present on endpoints that attempt to connect
to the Policy Secure gateway, and that you can restrict or quarantine these endpoints
according to your Host Checker policy configuration.
EES can scan processes that are loaded in memory on endpoints, and can provide
real-time file system write and execution shield to automatically remediate machines
that are not in compliance. As part of the remediation status, EES reports any threats
that are detected but not remediated. In some cases the user might be directed to reboot
the machine to achieve compliance.
EES uses a signature database that is automatically downloaded to endpoints from Web
Root Spy Sweeper servers on the Internet. (The signature database is not hosted on the
Policy Secure gateway.)
Endpoints must have access to the Internet for EES to run successfully, because live
signature updates must be able to download. Additionally, if you configure default
remediation roles ensure that endpoints that are directed to remediation roles can access
*.webroot.com.
You can configure the age of the database on the Policy Secure gateway to determine
the acceptable age of the signature database. The age of the database is the threshold
used to determine whether a user can access resources by passing a Host Checker
policy. For example, if signatures are 5 days old, and you configure the age as s days,
the endpoint is allowed to access resources. If you configure the age as 4 days, the
endpoint fails the

Host Checker policy. If an endpoint passes the initial EES Host Checker policy, signature
updates are performed regularly, so endpoints should generally have the most current
updates.
If Internet connectivity is not available to an endpoint before it connects to the Policy

Secure gateway, and you have chosen to implement the option to check for signature
age, the policy does not pass if the signatures are too old. For example, if a user has not
accessed the endpoint for several days and the signatures are not up to date, the
endpoint cannot access the Policy Secure gateway. In this case, you can create a default
remediation role that allows limited access to the Internet for signature updates at
*.webroot.com.
Any endpoint that is configured for an EES scan at Layer 2 always fails the check. To
permit a network connection, you should configure the realm soendpoint users are
reassigned to a remediation VLAN. This allows endpoint users to connect and download
the required signature updates, or if connecting for the first time, the EES installer package.
EES antispyware functionality is available on Windows platforms (including Vista) with

OAC and Pulse or with the agentless Host Checker component.
You configure EES on the Endpoint Security > Host Checker main page to ensure that
multiple policies are not created, and that the same policy is used across all realms and
roles for which you have enabled it. When you create a realm or a role, you can enable
EES restrictions in addition to any other Host Checker policies.
By default, with base license allows two simultaneous endpoints to use this feature. You
can purchase a separate license to enable additional users.
NOTE: If you configure an EES policy for endpoints, a separate EES installer
(about 5 MB) is downloaded to endpoints on their first attempt to access
resources protected by a Host Checker EES policy. User endpoints are scanned
for offending software, and signatures are automatically installed.
Enhanced Endpoint Security User Experience

For endpoints that do not have OAC or Pulse installed, or for agentless endpoints, the
EES plugin is initialized before the EES policy can be evaluated. An informational page
is displayed on the user’s endpoint to communicate the assessment status.
A significant amount of data is downloaded (approximately 5 MB for the installer and

approximately 12 MB for the signatures), followed by the memory scan.
After installation, signatures are updated and the memory scan is performed to verify
that no spyware is loaded in memory. If it is determined that the endpoint does not have
active spyware in memory, the policy passes.
The initial installation and scan on endpoints takes some time, so be to warn users to
wait for the operation to complete.
Any threat detected is automatically remediated by Host Checker and is not reported. If
threats cannot be remediated, the endpoint reports back to the server. Roles and user

sessions can be adjusted based on endpoint compliance. A number of user strings

automatically notify the user of the compliance status.
NOTE: Do not use machine authentication and GINA with the UAC agent and
EES. If you configure an EES scan to run at machine authentication or GINA
time, in some instances Windows will not display the login dialogue and the
endpoint will be unusable until you disable the EES scan on the Policy
Secure gateway.
Enabling the Enhanced Endpoint Security Option

To enable and use EES antispyware:
1. In the admin console, click Authentication > Endpoint Security > Host Checker.
2. Under Options, select the Advanced Endpoint Protection: Malware Protection tab.
3. Select the Enable Advanced Endpoint Protection: Malware Protection check box.
4. To set the age of the signature definitions database, select the Signature definitions
should not be older than check box. Enter the frequency in days (3 - 30). This function
does not change the frequency of updates. This number determines the maximum
permissible age of signatures.
When you create or configure realm or role Host Checker restrictions, you can select
Enhanced Endpoint Security: Malware Protection to apply to that role or realm.

Documentation

 Configuring Host Checker Restrictions on page 533
Checking for Third-Party Applications Using Predefined Rules
Host Checker comes equipped with a vast array of predefined rules that check for antivirus
software, firewalls, malware, spyware, and specific operating systems from a wide variety
of vendors. You can enable one or more of these rules within a Host Checker client-side
policy to ensure that integrated third-party applications are running on users’ computers
in accordance with your specifications. For firewall and antivirus rules, you can specify
remediation actions to automatically bring the endpoint into compliance.
To view the currently supported applications, select Authentication > Endpoint Security
> Host Checker and create a new policy. You can choose predefined rule types from the

Select Rule Type list to see a list of the supported applications within that category. The
lists of applications can be extensive and are updated at each support release, so check
the list periodically.
The following predefined rule types are available:
 Predefined: AntiVirus—Select this option to create a rule that checks for the antivirus
software that you specify, and to specify remediation options.
 Predefined: Firewall—Select this option to create a rule that checks for the firewall
software that you specify, and to specify remediation options.
 Predefined: Malware—Select this option to create a rule that checks for the malware
protection software that you specify.
 Predefined: AntiSpyware—Select this option to create a rule that checks for the
antispyware protection software that you specify.
 Predefined: OS Checks—Select this option to create a rule that checks for the Windows
operating systems and minimum service pack versions that you specify. (Any service
pack whose version is greater than or equal to the version you specify satisfies the
policy.)
NOTE: If the underlying TNCC service is killed or stopped, the endpoint can
remain on the network, possibly out of compliance, until the next refresh of
the Host Checker policy.
This section details Predefined Malware and Predefined OS check. Predefined Antivirus,
Firewall and Malware checks are defined in sections that follow.
To create a Host Checker rule using Predefined Malware or Predefined OS check rules:
2. Create a new policy, or select an existing policy in the Policies section of the page.
3. Under Rule Settings, choose one of the following options and click Add:
 Predefined Malware
 Predefined OS Checks
The predefined rule page opens.
4. In the Rule Name field, enter an identifier for the rule.
5. Under Criteria, select the specific malware or operating systems check for and click
Add. (When checking for an operating system, you can also specify a service pack
version.)
NOTE: When you select more than one type of software within a
predefined rule, Host Checker considers the rule satisfied if any of the
selected software applications are present on the user’s machine.

6. Under Optional, select Monitor this rule for change in result to continuously monitor
the policy compliance of endpoints. If this check box is selected, and a change in
compliance status on an endpoint that has successfully logged in occurs, the Policy
Secure gateway initiates a new handshake to re-evaluate realm or role assignments.
8. (Optional) Add additional rules to the policy, specify how Host Checker should evaluate
multiple rules within the policy, and define remediation options.

Documentation


Configuring a Predefined Antivirus Rule with Remediation Options (Windows and

Macintosh)
You can configure antivirus remediation actions with Host Checker. You can specify a
requirement for the age in days of the last successful virus scan, and you can specify that
virus signatures installed on client machines not be older than a specified number of
updates or days.
You can also monitor policies to ensure that logged-in endpoints maintain compliance
status, and remediate the endpoint to another role or realm depending on the current
status.
If a client attempts to log in and the client machine does not meet the requirements you
specify, Host Checker can attempt to correct the deficiencies to allow the client to
successfully log in. With Host Checker antivirus remediation, you can prompt the endpoint
to download the latest virus signature files, turn on antivirus protection, and initiate an
antivirus scan.
Not all of the remediation options are supported on products by all antivirus software
vendors. There is an option to display all available vendors and products that are
supported.
Alternately, you can select the Require specific products/vendors option button. Then
select either the Require any supported product from a specific vendor or Require specific
products check boxes. Then add an available type to Selected Types. The remediation
options appear, and you can determine which remediation options are available for
specific products or vendors.

NOTE:
 Remediation is not supported for Macintosh
 Not all products support basic functions. For example if Host Checker can
detect that an Anti-Virus product is installed, but it cannot check for real
time protection, then the host check is not effective. In these cases, the
product is not listed
To configure a predefined antivirus rule:
2. Create a policy or click on existing policy in the Policies section of the page.
3. Select the tab for Windows or Mac, depending on the platform for which this rule is
intended.
4. Under Rule Settings, select Predefined: Antivirus and click Add.
5. Enter the name of r this antivirus rule.
6. To determine if your software vendor’s product is supported for the System Scan
check, click these Antivirus products. A new window opens with a list of the products
that support the feature.
7. Select or clear the check box next to Successful System Scan must have been performed
in the last _ days, and enter the number of days in the box.
If you select this check box, a new option is displayed. If the remediation action to
start an antivirus scan successfully begun, you can override the previous check.
8. Select or clear the Consider this rule as passed if ‘Full System Scan’ was started
successfully as remediation check box.
9. Select or clear the Check for Virus Definition files check box. If you select this check
box, then choose either Virus Definition files should not be older than n Updates (the
default is 10, and the maximum is 20) or Virus Definition files should not be older than
n Days. The range for this value is 1 - 30.
 Require any supported product allows you to check for any product (rather than
requiring you to select every product separately). This option button reveals a list
of products in the remediation section to allow you to enable remediation options
which are product specific.
 Require specific products allows you to select individual products to define

compliance.
NOTE: A limited number of antivirus products are available for Macintosh

with Release 4.2. When new ESAP packages are released, support for new
products may be added. See the applicable release notes when new ESAP
packages are installed.

After you select your vendors and products, remediation options appear on the page.
For each of the following remediation actions:
 Download latest virus definition files—Obtains the latest available file for the
specified vendor from the vendor’s website.
 Turn on Real Time Protection—Launches the virus-scanning mechanism for the

specified vendor.
 Start Antivirus Scan—Performs a real-time virus scan for the specified vendor.
The check box is active if the action is supported for your product.
If your antivirus product is not supported, you can click the remediation column
headers to determine what vendors and products are supported.
11. If your product is supported, select the check box for the remediation action that you
want to apply.
the policy compliance of endpoints. If this check box is selected, the compliance status
of an endpoint that has successfully logged in changes, the Policy Secure gateway
initiates a new handshake to reevaluate realm or role assignments.
13. Click Save Changes to save the antivirus rule and enforce antivirus remediation.
14. (Optional) Add more rules to the policy, specify how Host Checker should evaluate
Related Checking for Third-Party Applications Using Predefined Rules on page 498
Documentation

Configuring a Predefined Firewall Rule with Remediation Options (Windows and

Macintosh)
You can configure firewall remediation actions with Host Checker after you create a Host
Checker firewall rule that requires the endpoint to have a specific firewall installed and
running before it connects to the network.
After you enforce the Host Checker rule with firewall remediation actions, if an endpoint
attempts to log in without the required firewall running, Host Checker can attempt to
enable the firewall on the client machine.
The remediation option is not supported for all firewall products. For a list of all available
products select the Require any supported product or Require specific products/vendors
option button.

To configure a Host Checker predefined firewall rule:
1. In the admin console, choose Authentication > Endpoint Security > Host Checker.
2. Create a policy or click an existing policy in the Policies section of the page.
intended.
4. Under Rule Settings, select Predefined: Firewall and click Add.
5. Enter a name for the firewall rule.
6. Select either the Require any supported product or Require specific products/vendors
option buttons to select firewall vendors and products.
Require any supported product lets you check for any product (rather than requiring
you to select every product separately). This option button reveals a list of products
in the remediation section to allow you to enable product-specific remediation options.
When you add an available product to Selected Products, the remediation option is
displayed, and you can determine if the remediation option is available for your selected
firewall.
Require specific products/vendors allows you to define compliance by allowing any

product by a specific vendor (for example, any Symantec product).
Require specific products provides functionality that allows you to select individual
products to define compliance.
After you select your vendor and product, the remediation options appear on the page.
NOTE: A limited number of firewall products are available for Macintosh

with Release 4.2. When new ESAP packages are released, support for new
products may be added. See the applicable release notes when new ESAP
packages are installed.
7. If your firewall is supported, select the Turn on Firewall check box.
Secure gateway initiates a new handshake to reevaluate realm or role assignments.
9. Click Save Changes to save the firewall rule and enforce firewall remediation.
Documentation


Configuring a Predefined AntiSpyware Rule (Windows and Macintosh)
You can configure Host Checker to check for installed antispyware on endpoints. After
you enforce the Host Checker rule, if an endpoint attempts to log in without the required
spyware, the Host Checker rule fails.
This configuration is not supported for all spyware products. To display all available
products, select Require any supported product or Require specific products/vendorss
option button.
To configure a Host Checker Predefined Spyware rule:
2. Create a new or click an existing policy in the Policies section of the page.
intended.
4. Under Rule Settings, select Predefined: AntiSpyware and click Add.
5. Enter a name for the firewall rule.
 Select the Require any supported product option button to check for any product
(rather than requiring you to select every product separately).
 Select the Require specific products/vendors option button to specify the spyware
that you want to check for.
 Select either the Require any supported product from a specific vendor or Require
specific products option button.
 Add antispyware from Available Products to Selected Products.
NOTE: SecureMac.com and Trend Micro are the only products available
for the Macintosh with Release 4.2. When new ESAP packages are
released, support for new products may be added. See the applicable
release notes when new ESAP packages are installed.
Secure gateway initiates a new handshake to re-evaluate realm or role assignments.

Documentation


Specifying Customized Requirements Using Custom Rules
In addition to the predefined policies and rules that come with the Policy Secure
gateway, you can create custom rules within a Host Checker policy to define
requirements that your users’ computers must meet. Custom rules, allow you to:
 Configure remote integrity measurement verifiers (IMVs) to perform customized

client-side checks.
 Configure Host Checker to check for custom DLLs that perform customized client-side
checks.
 Verify that certain ports are open or closed on the user’s computer.
 Confirm whether certain processes are or are not running on the user’s computer.
 Confirm whether certain files are or are not present on the client machine.
 Evaluate the age and content of required files through MD5 checksums.
 Configure patch assessment rules to determine that users have the latest software
versions installed.
 Confirm that registry keys are set on the client machine, and specify remediation actions.
 Confirm the NetBios name of the client machine.
 Confirm the MAC addresses of the client machine.
 Check the validity of the machine certificate that is installed on the user's computer.
NOTE: You can only check for registry keys, third-party DLLs, NetBios names,
MAC addresses, and machine certificates on Windows computers.
To create a client-side Host Checker policy:
2. Create a new policy or click an existing policy in the Policies section of the page.
3. Click the tab that corresponds to the operating system for which you want to specify
Host Checker options—Windows, Macintosh, Linux, or Solaris. In the same policy, you
can specify different Host Checker requirements on each operating system. For
example, you can create one policy that checks for different files or processes on each
operating system.

NOTE: You must explicitly create policies for each operating system you
want to allow. For example, if you create a Windows Host Checker policy.
But you do not create one for Macintosh or Linux, users who sign into the
Policy Secure gateway from a Macintosh or Linux machine do not
comply with the Host Checker policy and therefore will not be able to
access the realm, role, or resource on which you enforce Host Checker.
4. Under Rule Settings, select the options in the following sections and click Add. The
Add Custom Rule page for the rule type is displayed.
 Custom: Remote IMV—Configures integrity measurement software that a client

must run to verify a particular aspect of the client’s integrity, such as the client’s
operating system, patch level, or virus protection.
 3rd Party NHC Check (Windows only)—Specifies the location of a custom DLL.
Host Checker calls the DLL to perform customized client-side checks. If the DLL
returns a success value to Host Checker, then the is rule met. In the 3rd Party NHC
Check configuration page:
a. Enter a name and vendor for the 3rd Party NHC Check rule.
b. Enter the location of the DLL on client machines (path and file name).
The 3rd Party NHC Check feature is provided primarily for backwards
compatibility. We recommend that you use IMCs and IMVs instead.
 Ports—Controls the network connections that a client can generate during a session.
This rule type ensures that certain ports are open or closed on the client machine
before the user can access the Policy Secure gateway. In the Ports configuration
page:
a. Enter a name for the port rule.
b. Enter a comma -list (without spaces) of ports or port ranges, such as

1234,11000-11999,1235.
c. Select Required to require that these ports are open on the client machine, or
select Deny to require that they are closed.
d. Under Optional, select Monitor this rule for change in result to continuously monitor
the policy compliance of endpoints. If a compliance status changes on an
endpoint that has successfully logged in occurs, the Policy Secure gateway
initiates a new handshake to re-evaluate realm or role assignments.
e. Click Save Changes.
 Process—Controls the software that a client can run during a session. This rule type
ensures that certain processes are running or not running on the client machine
before the user can access resources protected by the Policy Secure gateway. In
the Processes configuration page:

a. Enter a name for the process rule.
b. Enter the name of a process (executable file), such as good-app.exe.
NOTE: For Linux, Macintosh and Solaris systems, the process that
is being detected must be started using an absolute path.
You can use a wildcard character to specify the process name.
For example: good*.exe
c. Select Required to require that this process is running, or select Deny to require
that this process is not running.
d. (Optional) Specify the MD5 checksum value of each executable file to which
you want the policy to apply. For example, an executable can have different MD5
checksum values on a desktop, laptop, or different operating systems. On a
system with OpenSSL installed—many Macintosh, Linux and Solaris systems
have OpenSSL installed by default—you can determine the MD5 checksum by
using this command: openssl md5 <processFilePath>.
 File—Ensures that certain files are present or not present on the client machine
before the user can access the Policy Secure gateway. You can also use file
checks to evaluate the age and content (through MD5 checksums) of required
files and to allow or deny access accordingly. In the Files configuration page:
a. Enter a name for the file rule.
b. Enter the name of a file (any file type), such a: c:\temp\bad-file.txt or

/temp/bad-file.txt.
You can use a wildcard character to specify the file name. For example:
*.txt
You can also use an environment variable to specify the directory path to the
file. (You cannot use a wildcard character in the directory path.) Enclose the
variable between the <%> characters. For example:
<%windir%>\bad-file.txt
c. Select Required to require that this file is present on the client machine, or select
Deny to require that this file is not present.
d. (Optional) Specify the minimum version of the file. For example, if you require
notepad.exe to be present on the client, you can enter 5.0 in the field. Host
Checker accepts version 5.0 and later, of notepad.exe.
e. (Optional) Specify the maximum age (File modified less than n days) (in days)
for a file. If the file is older than the specified number of days, then the client does
not meet the attribute check requirement.

NOTE: You can use the maximum age option to verify the age of
virus signatures. Make sure you specify the path to a file in the File
Name field whose timestamp indicates when virus signatures were
last updated, such as a virus signature database or log file that
updates each time the database updates. For example, if you use
TrendMicro, you can specify:
C:\Program Files\Trend Micro\OfficeScan Client\TmUpdate.ini.
f. (Optional) Specify the MD5 checksum value of each file to which you want the
policy to applyOn Macintosh, Linux, and Solaris, you can determine the MD5
checksum by using this command: openssl md5<filePath>
g. Select Monitor this rule for change in result to continuously monitor the policy
compliance of endpoints. If the compliance status on an endpoint that has
successfully logged in occurs, the Policy Secure gateway initiates a new
handshake to re-evaluate realm or role assignments.
h. Click Save Changes.
 Registry Setting (Windows only)—Controls the corporate PC images, system

configurations, and software settings that a client needs to have to access the
Policy Secure gateway. This rule type ensures that certain registry keys are set on
the client machine before the user can access the Policy Secure gateway. You
may also use registry checks to evaluate the age of required files and to allow or
deny access accordingly. In the Registry Settings configuration page:
a. Enter a name for the registry setting rule.
b. Select a root key from the list.
c. Enter the path to the application folder for the registry subkey.
d. (Optional) Enter the name of the key’s value that you want to require. This name
is displayed in the Name column of the Registry Editor.
e. (Optional) Select the key value’s type (String, Binary, or DWORD) from the list.
This type is displayed in the Type column of the Registry Editor.
f. (Optional) Specify the required registry key value. This information is displayed
in the Data column of the Registry Editor.
If the key value represents an application version, select Minimum version to

allow the specified version or newer versions of the application. For example,
you can use this option to specify version information for an antivirus application
to make sure that the client antivirus software is current. The Policy Secure
gateway uses lexical sorting to determine whether the client contains the
specified version or higher. For example:
3.3.3 is newer than 3.3
4.0 is newer than 3.3

4.1a is newer than 4.0b
4.2 is newer than 3.3.1
NOTE: If you specify only the key and subkey, Host Checker simply
verifies the existence of the subkey folder in the registry.
g. Under Optional, select Monitor this rule for change in result to continuously monitor
the policy compliance of endpoints. If this check box is selected, and a change
in compliance status on an endpoint that has successfully logged in occurs, the
Policy Secure gateway initiates a new handshake to re-evaluate realm or role
assignments.
You can configure registry setting remediation actions with Host Checker. If a
client attempts to login, and the client machine does not meet the requirements
you specify, Host Checker can attempt to correct the discrepancies to allow the
client to login.
h. Select the Set Registry value specified in criteria check box.
i. Click Save Changes.
 NetBIOS (Windows only, does not include Windows Mobile)—Verifies the NetBIOS
name of the client machine before the user can access the Policy Secure
gateway. In the NetBIOS configuration page:
a. Enter a name for the NetBIOS rule.
b. Enter a comma-delimited list (without spaces) of NetBIOS names. The name

can be up to 15 characters in length. You can use wildcard characters in the name
and it is not case sensitive. For example, md*, m*xp, and *xp all match MDXP.
c. Select Required to require that NETBIOS name of the client machine match one
of the names you specify, or Deny to require that the name does not match any
name.
d. Click Save Changes.
 MAC Address (Windows only)—Verifies the MAC addresses of the client machine
before the user can access the Policy Secure gateway. In the MAC Address
configuration page:
a. Enter a name for the MAC address rule.
b. Enter a comma-delimited list (without spaces) of MAC addresses in the form

XX:XX:XX:XX:XX:XX where the X is a hexadecimal number. For example:
00:0e:1b:04:40:29
You can use a wildcard character to represent a 2-character section of the

address. For example, you can use a wildcard to represent the “04”, “40”, and
“29” sections of the previous example address:

00:0e:1b:*:*:*
But you cannot use a wildcard to represent a single character. For example, the
following address is not allowed:
00:0e:1b:04:40:*9
c. Select Required to require that a MAC address of the client machine matches
any of the addresses you specify, or select Deny to require that all of your
addresses do not match. A client machine will have at least one MAC address
for each network connection, such as Ethernet, wireless, and VPN. This rule
requirement is met if any of the addresses you specify match any MAC address
on the client machine.
NOTE: Since the MAC address is changeable on some network cards,

this check does not guarantee that a client machine meets the
requirements of your Host Checker policy.
 Machine Certificate (Windows only)—Verifies that the client machine is permitted

access by validating the machine certificate stored on the client machine. In the
Machine Certificate configuration page:
a. Enter a name for the machine certificate rule.
b. From the Select Issuer Certificate list, select the certificate to retrieve from the
user’s machine and validate. Or, select Any Certificate to skip the issuer check
and only validate the machine certificate based on the optional criteria that you
specify below.
c. In the Optional fields (Certificate field and Expected value), specify any additional
criteria for Host Checker to use to verify the machine certificate.
NOTE:
If more than one certificate is installed on the client machine that
matches the specified criteria, the Host Checker client passes the
first certificate it finds to the Policy Secure gateway for validation.
 Do not apply remediation options for endpoints that are

authenticated using machine certificates.
5. Optionally add additional rules to the policy, specify how Host Checker should evaluate

Documentation
 Checking for Third-Party Applications Using Predefined Rules on page 498


 Using a Wildcard or Environment Variable in a Host Checker Rule on page 511
Using a Wildcard or Environment Variable in a Host Checker Rule
Table 56 on page 511 lists the wildcards you can use to specify a file name in a Custom
File rule or a process name in a Custom Process rule.
Table 56: Wildcard Characters for Specifying a File Name or Process

Name
Wildcard Character Description Example
* Matches any character *.txt
? Matches exactly one character app-?.exe
In a Custom File rule for Windows, you can use the following environment variables to
specify the directory path to a file:
Table 57: Environment Variables for Specifying a Directory Path on

Windows
Environment variable Example Windows Value
<%APPDATA%> C:\Documents and Settings\jdoe\Application Data
<%windir%> C:\WINDOWS
<%ProgramFiles%> C:\Program Files
<%CommonProgramFiles%> C:\Program Files\Common Files
<%USERPROFILE%> C:\Documents and Settings\jdoe
<%HOMEDRIVE%> C:
<%Temp%> C:\Documents and Settings \<username>\Local

Settings\Temp
Table 57 on page 511 lists Custom File rules for Macintosh, Linux and Solaris.

Macintosh, Linux and Solaris
Example Linux and Solaris

Environment variable Example Macintosh Value Values
<%Java.home%> /System/Library/Frameworks/JavaVM.framework/ /local/local/Java/j2sdk1.4.1_02/

Versions/1.4.2/Home jre
<%Java.io.tmpdir%> /tmp /tmp


Macintosh, Linux and Solaris (continued)
Example Linux and Solaris

Environment variable Example Macintosh Value Values
<%user.dir%> /Users/admin /home-shared/cknouse
<%user.home%> /Users/admin /home/cknouse
NOTE: Although environment variables are formatted in the same way as

Toolkit Template directives, they are not interchangeable. Be sure not to
confuse them.
Related Specifying Customized Requirements Using Custom Rules on page 505

Documentation

Patch Management Info Monitoring and Patch Deployment
On Windows systems, you can configure Host Checker policies that verify the endpoint’s
operating system service pack, software version, or desktop application patch version
compliance. Host Checker uses a list of the most current patch versions from the vendor
for predefined rules in the Host Checker policy. Host Checker does not scan for
non-security patches.
You obtain the most current patch version information from a Pulse Secure staging site.
You can manually download and import the list into the Policy Secure gateway, or you
can automatically import the list from the Pulse Secure staging site or your own
staging site at a specified interval.
Monitoring is based on either one or more specified products or on specific patches,

though not in the same policy. For example, you could check for Internet Explorer Version
7 with one policy, and Patch MSOO-039: SSL Certificate Validation Vulnerabilities with
a second policy. Then, apply both policies to endpoints at the role or realm level to ensure
that the user has the latest browser version with a specific patch. In addition, for Microsoft
products, you can specify the severity level of patches that you wish to ignore. For example,
you could ignore low or moderate threats.
The Policy Secure gateway can send remediation instructions (such as. a message
describing what patches or software are non-compliant, and a link to where the
endpoint can obtain the patch). The Policy Secure gateway does not autoremediate in
the event of a non-compliant endpoint. However, you can send the items to the client
for manual remediation of managed machines.
When an endpoint first connects to the Policy Secure gateway, the latest versions of
the data files and libraries of the IMC are downloaded to the host computer. The initial
check takes 10- 20 seconds to run, depending on the link speed. If the files are
outdated, they are automatically updated at subsequent checks. If this is the first time
the endpoint has connected to a Policy Secure gateway with the patch assessment
policy, and the connection

is a Layer 2 connection, the IMC required to run the Patch Assessment check cannot
download. In this case, you should configure a remediation role that displays instructions
to direct the user to retry with a Layer 3 connection or contact the administrator.
Note that in non-English installations, the English version of local patches is displayed.
Additional Functionality with Pulse 2.0

With Pulse 2.0, additional functionality is provided for Patch Info Monitoring and
Deployment.
Endpoints with Pulse 2.0 that are not in compliance with specified patch policies can be
updated with the required patches and brought into compliance automatically. This is
achieved through a new patch deployment engine. The patch deployment engine executes
on endpoints, downloads specified patches, and installs patches that are required through
the Host Checker policy. This feature is not available for OAC, agentless access, or the
Java agent. The patch deployment engine provides a new means of remediating endpoints
that do not meet the patch assessment policies defined on the Policy Secure gateway.
This functionality is available for Windows XP, and Vista and Windows 7 32 bit and 64
bit versions.
The Host Checker IMC on the endpoint interfaces with the patch deployment engine to
download and install missing patches reported by the IMV. When the patch installation
is complete, the IMC signals the TNC client to start a new handshake with the Policy
Secure gateway, and enables IC to make access control decisions based on the result
of the handshake.
Endpoints without Pulse 2.0 can still use the legacy basic patch remediation mechanism,
in which a pre-installed SMS client is triggered to get patches from a preconfigured SMS
server. This mechanism installs only those patches that are published on the SMS server.
If the SMS client is not installed, or the server doesn’t host the patches required by the
policies on Policy Secure gateway, the endpoint cannot be fully remediated.
The patch deployment engine is an executable file that is hosted on the Policy Secure
gateway. The executable can be downloaded to any endpoint that you would like to
remediate. Unlike the SMS client, one can specify what patches need to be applied.
The patch deployment engine directly downloads missing patches from vendor
websites, without going through the Policy Secure gateway. Therefore, Internet
connectivity is needed for Shavlik remediation to work. The patch deployment engine
does not work with Layer 2 without Layer 3 connectivity. You can configure a
remediation VLAN for post authentication. Once Layer 3 connectivity is obtained,
endpoints can remediate successfully. With Layer 3 connectivity, the patch deployment
engine downloads missing patches.
A separate license is required for patch info monitoring and deployment functionality. It
is not available as part of the endpoint solution.
All of the files required for patch deployment are a part of a ESAP packages beginning
with UAC 4.1. The default ESAP package shipped with UAC 4.1 contains the required
patch deployment files. Any older ESAP packages fail to update on these devices.
The IMC and IMV for patch monitoring is backward compatible. Since this feature is
available from Pulse 2.0 onward, a new Pulse communicating with an older IMV (with

Pulse support), or a new IMV communicating to an older IMC exhibit the same behavior
as today. There should be no change in the patch assessment, and Shavlik’s deployment
engine is not invoked for remediation.
User Experience
Patch remediation can take a good deal of time, and policies continue to fail until the
process is completed. When an update is required, the user is given an option to proceed
with patch deployment. If the user decides not to deploy the patch(es) and proceed, the
user may not have connectivity or may have limited connectivity, depending on the
Policy Secure gateway administration configuration. If any patches require a reboot
subsequent to installation, the application informs Host Checker, and Pulse notifies the
user. In this case, until the machine is rebooted, patches continue to be reported as
missing in subsequent patch assessments. If a reboot is required, any further patch
deployment is not carried out until the machine is rebooted. The user is notified if a
reboot is required.
Pulse notifies the user that patches need to be installed, and provides status as the
download is occurring. When the installation is complete, the client presents the login
dialogue.
Using a System Management Server

For OAC, agentless access, and any UAC agent other than Pulse 2.0, you can use a System
Management Server (SMS) to provide a method for automatic updates to non-compliant
software.
Pulse 2.0 can support either the SMS download method or the patch deployment engine
for patch deployment, depending on the configuration on the IC Series. If the IC Series is
configured for the SMS method for patch deployment, the client machine should have
the SMS client already installed in the machine for deployment to begin, otherwise
remediation fails.
Endpoints configured with SMS for software management typically poll the server for
updates every fifteen minutes or longer. In a worst-case scenario, clients that are not in
compliance with existing Host Checker software requirements might have to wait until
the next update interval to login.
Using the SMS download method, you can force the client to initiate the software update
immediately after the patch assessment check.
If a user attempts to log in, and the endpoint does not have a required software version
for compliance with a Host Checker patch assessment policy, Host Checker immediately
notifies the client to poll the server for an immediate update. The client receives
notification that an SMS update has started.
To configure SMS to update the client when notified, set the advertisement time on the
SMS to As soon as possible. The following process then occurs:
 The Policy Secure gateway patch assessment policy specifies the required software.
 When an endpoint attempts to authenticate, Host Checker evaluates the client and
sends the results back to the Policy Secure gateway.

 The Policy Secure gateway evaluates the results and sends reason strings and
remediation information to the client, including a message that directs the client to
poll the server for software advertisements immediately.
 The SMS client queries the SMS server for software advertisements.
 The server identifies what patches should be advertised to the client (this is configured
on the server, Host Checker does not interact with the server).
 The SMS client receives the advertisement and applies the required patch(es).
You assign clients to a particular group or collection on the server. Then the SMS server
can advertise patches for that collection. You can configure roles on the Policy Secure
gateway that correspond to collections, and SMS can send the appropriate patches for a
particular role.
You must have the SMS client installed and configured correctly on endpoints, and the
SMS server must be reachable. In a Layer 2 network, Host Checker is performed before
the endpoint is connected to the network. Host Checker can obtain the IP address of the
SMS server configured for the client. If the endpoint is out of compliance and remediation
is necessary, Host Checker pings the server IP address every 15 seconds until the server
can be notified to update the client.
It is important as an administrator to inform users of the expected behavior if this feature

is enabled, as there is no notification to the user until the SMS sends back the
advertisement.
Pulse Secure recommends only one patch deployment on the endpoint at any point in
time. However, there is no way to determine if an SMS update is in progress, and so it
may be possible that the patch deployment engine is started while a SMS Update is also
occurring (this could happen if Pulse is connected to two Policy Secure or Connect
Secure gateways with one using SMS remediation and the other using the patch
deployment engine).
Given the fact that most patches will not allow two instances to be running, one of the
remediations fail, depending on which began first.
The Admin Console allows you to select only one of the remediation options (either SMS
or patch deployment engine) for all the policies.
If Pulse is connected to more than one IC Series or Connect Secure gateway, and one
requires patch deployment engine remediation and the other requires SMS
remediation, both requests are met. If both require the patch deployment engine
method, the requests are queued.
Related Configuring Patch Remediation Options on page 518

Documentation

Configuring Virus Signature Version Monitoring and Patch Assessment Info Monitoring
and Patch Deployment
You can configure Host Checker to monitor and verify that the virus signatures, operating
systems, software versions, and patches installed on client computers are up to date.

You can also remediate endpoints that do not meet the specified criteria. Host Checker
uses the current virus signatures and patch assessment versions from the vendors you
specify for predefined rules in a Host Checker policy.
You can automatically import the current virus-signature version-monitoring or patch

management info monitoring lists from the Pulse Secure staging site at a specified
interval, or you can download the files from Pulse Secure and use your own staging
server.
You can also configure a proxy server as a staging site between the Policy Secure
gateway and the Pulse Secure site. To use a proxy server, you enter the server network
address, port, and authentication credentials, if applicable.
To access the Pulse Secure staging site for updates, you must enter the credentials for
your Pulse Secure Support account.
For patch assessment remediation with Pulse 2.0 or higher, you can purchase an optional
patch deployment engine license that allows Shavlik (a third-party vendor) to
automatically download patches from trusted sources to the endpoint.
To configure the Policy Secure gateway to automatically import the current virus
signature version-monitoring and patch management version-monitoring lists from
the Pulse Secure staging site:
1. Select Authentication > Endpoint Security > Host Checker.
2. Select Virus signature version monitoring, or Patch Management Info Monitoring.
3. Select Auto-update virus signatures list or Auto-update Patch Management Info

Monitoring and Patch Deployment.
4. For Download path, leave the existing URLs of the staging sites where the current lists
are stored. The default URLs are the paths to the Pulse Secure staging site:
For autoupdate virus signatures list:
https://download.juniper.net/software/av/uac/epupdate_hist.xml
For autoupdate patch management:
https://download.juniper.net/software/hc/patchdata/patchupdate.dat
5. For Download interval, specify how often you want the Policy Secure gateway to
automatically import the current list(s).
6. For Username and Password, enter your Pulse Secure Support credentials.
To manually import the current virus signature version-monitoring and patch management
version monitoring lists:
2. Click Virus signature version monitoring, or Patch Management Info Monitoring.
3. Download the list(s) from the Pulse Secure staging site to a network server or local
drive on your computer by entering the Pulse Secure URLs in a browser window:

4. Under Manually import virus signatures list, click Browse, select the list, and then click
OK.
NOTE: If you use your own staging site for storing the current list(s), you must
upload the trusted root certificate of the CA that signed the staging’s server
certificate to the Policy Secure gateway.
To use a proxy server as the auto-update server:
2. Select Virus signature version monitoring, or Patch Management Info Monitoring.
3. Select Auto-update virus signatures list or Auto-update Patch Management data.
4. For Download path, leave the existing URLs of the staging sites where the current lists
are stored. The default URLs are the paths to the Pulse Secure staging site:
(for autoupdate virus signatures list)
(for autoupdate patch management)
5. For Download interval, specify how often you want the Policy Secure gateway to
automatically import the current lists.
6. For Username and Password, enter your Pulse Secure Support credentials.
7. Select the Use Proxy Server check box.
8. For IP Address, enter the IP address of your proxy server.
9. For Port, enter the port that the Pulse Secure Support site will use to communicate
with your proxy server.
10. If your proxy server is password protected, type the Username and Password of the
proxy server.
Related Patch Management Info Monitoring and Patch Deployment on page 497
Documentation


Configuring Patch Remediation Options
To select a patch assessment method for remediation on endpoints using Pulse 2.0 or
higher (with the appropriate license):
1. Under Patch Remediation Options, select a patch deployment method by selecting

the option button for:
 SMS/SCCM Patch Deployment
In the absence of the appropriate license, there is a check box to Enable SMS patch
update. (For this option, you must configure and deploy a Systems Management
Server (SMS) to remediate endpoints.)
 Shavlik Patch Deployment
(This is a licensed feature. In the absence of the appropriate licenses there is no

configuration option to enable the Shavlik patch deployment engine on the UI.)
2. (Optional) Select the check box Prompt the user for consent before automatic patch
deployment.
a. Select a default action in the absence of a user response (Deploy patches or Do

not deploy patches.
Documentation

Configuring Host Checker Patch Assessment Rules
To configure a patch assessment custom rule:
2. Create a new policy, or click an existing policy in the Policies section of the page.
3. Click the Windows tab.
4. Under Rule Settings, select Custom: Patch assessment.
5. Click Add under Rule Settings. The Add Custom Rule:Patch assessment page is
displayed.
6. Enter a name for the integrity measurement rule.
NOTE: If a selection that is not applicable is included in a policy, i.e. the

endpoint does not have the targeted software, the rule is ignored and the
check for that particular selection passes.
7. Select either Scan for specific products or Scan for specific patches.

If you select Scan for specific products you must further select either All Products or
Specific Products.
If you select All Products, Host Checker checks for all of the exposed patches on the
endpoint.
To configure a policy based on specific products:
a. Select the All Products option button.
b. (Optional) Select specific patches to ignore for all products by clicking the Add
button under Ignore following patches.
d. (Optional) For Microsoft products, clear the check boxes to determine the severity
level of the patches that you wish to ignore. For example, if you wanted to check
for only critical patches for the selections, clear the check boxes for Important,
Moderate, Low, and Unspecified.
If you select Specific Products, two new dialog boxes open. You can select from an
extensive listing of products and versions, and you can ignore specific patches.
For example, if you add Internet Explorer 6 to the Selected Products list, you can ignore
any patches that you do not consider critical for the product. You can fine-tune the
severity level of specific patches to be ignored by clearing the severity check boxes
for Microsoft products.
To configure a policy based on specific products:
a. Select the Specific Products option button.
b. Select software from the Available products window and add to the Selected
products window.
d. (Optional) Select specific patches that you wish to ignore for the chosen products
by clicking the Add button under Ignore following patches. Anew dialog opens,
displaying all of the available patches for the software you have selected.
e. Select specific patches that you wish to ignore from the Available patches window
and add to the Selected patches window.
f. Click the Add button under Add.
When you click the Add button, the Ignore following patches window is populated
with the patches you selected.
g. (Optional) For Microsoft products, clear the check boxes to determine the severity
level of the patches to ignore. For example, to identify only critical patches for the
selections, clear the check boxes for Important, Moderate, Low, and Unspecified.

NOTE: The severity level check boxes apply to Microsoft products only.
For other vendors, such as Adobe, the Unspecified check box determines
whether or not the check will be run.
h. Click Save Changes.
The Scan for specific patches option allows you to choose from a list of all available
patches.
To configure a policy based on patches:
a. Select the Scan for specific patches option button.
When you select the Scan for specific patches option, a new dialog box opens that
allows you to add specific patches.
b. Click the Add button.
c. Select specific patches to check for from the Available patches window and add
them to Selected patches.
d. Click the Add button.
9. With the appropriate license, there is a check box to Enable Automatic Patch
Deployment.
You can display remediation information for users based on which patch/version
needs to be updated. For example, you can configure a reason string to display
information about a patch that is missing and specify a link to take the user to the
web page to get the patch.
11. To display remediation information to users regarding patches and versions that need
updating, select the Send Reason Strings option under Remediation on the main Host
Checker Policy page.
Documentation

Using Third-Party Integrity Measurement Verifiers
The TNC standard enables the enforcement of security requirements for endpoints
connecting to networks. The client-side components of the TNC are the IMCs and the
TNCC. The TNCC compiles the IMC measurements and sends them to the server. At the
server, there is a corresponding set of components: the TNC server (TNCS) and the IMVs.

The TNCS manages the messages between the IMVs and the IMCs and sends the
recommendations, based on the IMVs, to the policy engine. This type of rule is available
for Host Checker policies on all platforms.
The Policy Secure gateway and Host Checker comply with the standards produced by
the TNC. For more information about the TNC, IMVs and IMCs, see
www.trustedcomputinggroup.org.
You can configure Host Checker to monitor third-party TNC-compliant IMCs installed
on client computers. To do so, you must:
1. Run the Third-party Integrity Measurement Verifier (IMV) Server installer on the system
designated as the remote IMV server. Install the third-party IMVs and create the server
certificates.
2. Specify the remote IMV server so that the Policy Secure gateway can communicate
with it.
3. Implement the Host Checker policy.
Related Configuring a Remote IMV Server on page 521

Documentation

Configuring a Remote IMV Server
NOTE:
 In an active/passive cluster, the active/passive nodes' individual IP
addresses must be added to the RIMV as the Policy Secure gateway IP
addresses.
 The successful addition of remote IMV server is not logged in the event log.
 When Host Checker fails, custom instructions are not displayed. There is
no user access log on the Policy Secure gateway about Host Checker
failure.
During this step, you install third-party IMVs. Third-party IMVs are installed on the remote
IMV server, not on the Policy Secure gateway. You also obtain a server certificate for the
remote IMV server. You import the trusted root CA certificate of the CA that generated
the server certificate onto the Policy Secure gateway. The Policy Secure gateway then
authenticates with the remote IMV server through the certificate. If you do not have a CA,
install and use OpenSSL to generate a CA certificate.
To install, configure, and implement the server software:
1. In the admin console of the Policy Secure gateway, select Maintenance > System >
Installers
and download the Third-party Integrity Measurement Verifier (IMV) Server installer.
2. Run the installer on the system designated as the remote IMV server.
3. Install the third-party IMVs on the remote IMV server and the corresponding IMCs on
the client systems.

4. Generate a server certificate from a certificate authority for the remote IMV server.
The server’s certificate Subject CN value must contain the actual host name or IP
address of the remote IMV server.
The server certificate and the private key must be combined into a single PKCS#12
file and must be encrypted with a password.
If you do not have a CA, you can use the following steps to create one, and then create
a server certificate for the remote IMV server.
NOTE: Be sure to install the full version of OpenSSL. The "light" version
of OpenSSL will not work.
To set up OpenSSL:
a. Download and install OpenSSL from this site:
http://www.slproweb.com/products/Win32OpenSSL.html
NOTE: Depending on your operating system, the default installation

directory may be different. You should ensure that OpenSSL is installed
in c:\openssl.
b. At the Windows command prompt, type the following commands:
cd \openssl
md certs
cd certs
md demoCA
md demoCA\newcerts
md demoCA\private
edit demoCA\index.txt
c. Press ALT-F and then S to save the file.
d. Press ALT-F and then X to exit the editor.
e. At the Windows command prompt, type the following command:
edit demoCA\serial
f. In the document window type: 01
g. Press ALT-F and then S to save the file.
h. Press ALT-F and then X to exit the editor.
i. At the Windows command prompt, type the following commands:

set path=c:\openssl\bin;%path%
set OPENSSL_CONF=c:\openssl\bin\openssl.cfg
j. In Wordpad (or an equivalent text editor that correctly handles Unix line breaks),
edit the openssl config file (c:\openssl\bin\openssl.cfg), change the CA policy

match for country and state from “match” to “optional”, and save your changes.
The resulting config stanza should appear as follows:
# For the CA policy

[ policy_match ]
countryName = optional
stateOrProvinceName = optional
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
To create a CA key:
a. Type the following command at the Windows command prompt in the

c:\openssl\certs directory:
openssl genrsa -out ca.key 1024

The following output appears:
Loading 'screen' into random state - done
Generating RSA private key, 1024 bit long modulus
........++++++
.++++++
e is 65537 (0x10001
b. Copy the CA key into the private directory of your CA:
cp ca.key demoCA\private\cakey.pem
To create a CA certificate:
a. Type the following command at the Windows command prompt in the

c:\openssl\certs directory:
openssl req -new -x509 -days 365 -key ca.key -out

demoCA/cacert.pem
b. Enter the appropriate Distinguished Name (DN) information for the CA certificate.
You can leave some fields blank by hitting enter.
For example:
Country Name: US
State or Province Name: CA
Locality Name: Sunnyvale
Org. Unit Name: IT
Common Name: ca.xyz.com
c. Type the following command to generate an RSA private key for the remote IMV
server:
openssl genrsa –out rimvs_key.pem 1024

d. Type the following command to generate a CSR for the remote IMV server:
openssl req –new –key rimvs_key.pem –out rimvs_csr.pem

e. Enter the required information. For example:

Country Name:US
State or Province Name:MA
Locality Name:Boston
Organization Name:XYZ
Organizational Unit Name:IT
Common Name: [IPAddress]:10.0.1.10
e-mail Address:user@xyz.com
A challenge password:
An optional company name:
NOTE: The Common Name field must contain the IP address of the
machine running the remote IMV server. This machine must have a
static IP address. The organization name in the CSR must match the
CA certificate's organization name. If the organization names do not
match, you cannot sign the CSR.
f. Type the following command to generate a certificate for the remote IMV server:
openssl ca –in rimvs_csr.pem –out rimvs_cert.pem

g. Type y twice when prompted to generate the certificate. This certificate is valid
for 365 days by default. If you want a different certificate lifetime, change the
default_days parameter in the openssl.cfg file, or use the –days parameter to the
openssl ca command to specify a different lifetime.
h. Type the following command to place the remote IMV server key and certificate
in a PKCS#12 file (substitute the challenge password you entered previously for
<password> in this command):
openssl pkcs12 –export –in rimvs_cert.pem –inkey rimvs_key.pem –passout

pass:<password> -out rimvs_p12.pem
5. On the remote IMV server, select Programs > Juniper Networks > Remote IMV Server
> Remote IMV Server Configurator from the Start menu.
6. Under Client Info, click Add.
7. Configure the port to service SOAP requests from the Policy Secure gateway.
8. Enter the client’s IP address, the number of addresses to use, and the shared secret
used by both the Policy Secure gateway and the remote IMV server.
9. (Optional) Change logging settings (log is generated in the install directory).
10. Browse and find the PKCS#12 file you generated in the file system.
11. Specify the password associated with the certificate.
12. In the admin console of the Policy Secure gateway, select the System >
Configuration > Certificates > Trusted Server CAs tab to import the trusted root CA
certificate of the CA that issued the certificate for the remote IMV server.
If you used OpenSSL to generate the remote IMV server’s server certificate is:
demoCA\cacert.pem.
If you did not use OpenSSL to generate this certificate, ensure that the file you import
has the CA certificate (not the root certificate).

13. Click Import Trusted Server CA and browse for the server certificate used on the remote
IMV server.
14. Add the new remote IMV server:
To specify the remote IMV server so that the Policy Secure gateway can
communicate with it:
a. In the admin console, select Authentication > Endpoint Security > Host Checker.
b. Under Remote IMV, click New Server.
c. In the New Server page:
i. Create a label for the server using the Name and (optional) Description fields.
ii. In the Hostname field, enter either the IP address or hostname as defined in the
server certificate.
iii. In the Port field, enter the unique port number the Policy Secure gateway
uses to communicate with the remote IMV server. Ensure that no other service
is using this port number.
The default port number is the same as the default HTTPS port number. If you
are running a web server on the same system as the Remote IMV Server, enter
a new port number in the Port field.
iv. In the Shared Secret field, enter the same shared secret used in the client
information entry on the remote IMV server.
v. Click Save Changes.
d. Under Remote IMV, click New IMV to specify the third-party IMV.
e. In the New IMV page:
i. Create a label for the IMV using the Name and (optional) Description fields.
ii. In the IMV Name field, enter the name of the IMV. This name must match the
“human-readable name” in the IMV’s well-known registry key on the remote
IMV server. For more information about human readable names and the
well-known registry key, see www.trustedcomputinggroup.org.
iii. From the Primary Server menu, select the remote IMV server where this IMV is
installed.
iv. (Optional) From the Secondary Server menu, select the secondary remote IMV
server where this IMV is installed. The secondary server acts as a failover in case
the primary server becomes unavailable.

The Policy Secure gateway continues to try to re-establish connection to the

primary remote IMV Server, and uses the primary Remote IMV Server on
subsequent handshakes once it becomes available.
v. Click Save Changes.
f. Click Save Changes.
Related  Using Third-Party Integrity Measurement Verifiers on page 520

Documentation
Implementing a Third-Party IMV Policy
To use Host Checker as a policy enforcement tool for managing endpoints, you must
create global Host Checker policies at the system level and then implement the policies
at the realm and role levels.
NOTE: The Custom: Remote IMV option does not appear until you add the
Remote IMV New Server and New IMV on the main Host Checker page.
To implement the third-party IMV policy:
2. Under Policies, click New.
3. Enter a name in the Policy Name field and click Continue. (Users see this name on the
Host Checker remediation page if you enable custom instructions for this policy.)
4. Under Rule Settings, select Custom: Remote IMV and click Add.
5. In the Add Custom Rule: Remote IMV page:
a. In the Rule Name field, enter an identifier for the rule.
b. Under Criteria, select the third-party IMV to associate with this rule.
6. Specify how Host Checker must evaluate multiple rules within the policy.
7. (Recommended) Specify remediation options for users whose computers do not

meet the requirements specified in the policy.
9. Implement the policy at the realm or role level.
Related Using Third-Party Integrity Measurement Verifiers on page 520

Documentation
 Configuring a Remote IMV Server on page 521


Using Statement of Health Integration Host Checker Policies
You can use Host Checker policies on the Policy Secure gateway with the open
standard Statement of Health (SOH) protocol by leveraging the existing protocols
built into the Policy Secure gateway. To use this functionality, you must obtain SOH
licensing from Pulse Secure.
SOH support is implemented through local Host Checker criteria that you configure on
the Policy Secure gateway, alternatively or you can deploy an external Network Policy
Server (NPS) to use third-party system health agents (SHAs) and system health
validators (SHVs), as shown in Figure 109 on page 528.
The SOH architecture provides a set of components that evaluates an endpoint’s state
of health and makes policy decisions for network access based on the result of the health
check. The Policy Secure gateway supports SOH interoperability for Windows Vista,
Windows XP Service Pack 3, Windows 7, OAC, and Pulse. Windows Security Center
(WSC) functionality is built into the Host Checker component that implements this
feature for local host checking.
You can configure OAC SOH Host Checker policies if you are using Layer 2 and 802.1X or
Layer 3 with the Infranet Enforcer. The Windows supplicant can connect only with 802.1X.
There is no heartbeat between the Policy Secure gateway and the Windows client, and
no other Host Checker policies are supported with the Windows client. If you are using
OAC, you must use the default EAP-JUAC protocol. If you configure a different protocol
set for OAC and do not include EAP-JUAC, the SOH cannot be transmitted. SOH Host
Checker policies are not supported for agentless access.
You can use the SOH health state validation to determine which roles or realms can be
accessed by endpoints. If an endpoint fails the SOH check, or if the SOH cannot be
negotiated successfully, the Host Checker policy fails.
You can use local Host Checker SOH enforcement with either OAC, Pulse, or the Windows
supplicant. With local enforcement, you can specify remediation actions if the endpoint
does not pass the Host Checker policy. Local enforcement supports the WSC SHA, which
includes support for checking the following:
 Antivirus is enabled.
 Antivirus is up to date.
 Antispyware is enabled.
 Antispyware is up to date.
 Firewall is enabled.
 Automatic updating Enabled
To implement additional third-party SHAs, you must use an NPS.
Multiple local evaluations or multiple NPS evaluations are supported, but clients are
limited to one state of health response (SOHR). The client receives the SOHR from the
first failed policy. If the endpoint fails multiple policies, the agent receives SOHRs from

the failed policies in the order in which they are performed. If the endpoint passes multiple
policies, the agent receives the SOHR from the first passed policy.
Figure 109: SOH Integration with a Network Policy Server
The external NPS and the Policy Secure gateway communicate using a RADIUS-based
protocol. The endpoint requests authentication from the Policy Secure gateway using
the EAP-PEAPv0 protocol. The Policy Secure gateway communicates SOH information
between the NPS and the endpoint as request/response messages. The server
connection information that allows the NPS to communicate with the Policy Secure
gateway is configured on the Host Checker SOH interface.
When you use an external NPS, as in all other Host Checker policies, you can restrict users
whose endpoints fail to meet the requirements of the Health Registration Authority (HRA)
on the NPS.
You can use the NPS as both the AAA server and the health policy server. Windows Server
2008 is the only server supported as an NPS. See the applicable Microsoft documentation
for details about setting up the NPS.
If you use an external NPS for evaluation of the SOH, you cannot use local enforcement.
Additionally, avoid putting any other Host Checker rules into a policy that is designed for
SOH enforcement with the Windows client.
An SOH license is required to use this feature.
Related Configuring a Statement of Health Host Checker Policy on page 529

Documentation


Configuring a Statement of Health Host Checker Policy
To configure a SOH policy in Host Checker:
2. Create a new policy or click on an existing policy in the Policies section of the page.
3. Click the Windows tab.
4. Under Rule Settings, select Custom: Statement of Health.
5. Click Add under Rule Settings. The Statement of Health page is displayed.
6. Type a Rule Name for this rule.
To configure a local SOH Host Checker policy:
1. Under Criteria, enter a Label for a SOH parameter.
2. Select an SOH policy option from the Parameter menu then click Add for the following
types:
 Antivirus Enabled
 Antivirus up to date
 Antispyware enabled
 Antispyware up to date
 Firewall Enabled
 Automatic Updating Enabled
3. Select additional options from the Parameterlist to add additional SOH parameters.
4. Select the check box for each item to activate that item for this Host Checker SOH
policy.
NOTE: Each SOH rule receives one SOHR. If a single Host Checker rule
has multiple policy configurations, all of these are remediated by one
SOHR.
5. (Optional) For each rule, select the Enable automatic remediation check box. If you
select this option for a rule, the user will receive a message from the SOH agent, and
appropriate remediation is performed, if possible. If the box is not checked the user
receives a message.

NOTE: For remediation to succeed, you must configure at least one

remediation role for the user. If the user cannot negotiate a realm with at
least one role, the user cannot be authenticated and the SOHR is ignored
by the SOH agent.
To configure a SOH Host Checker policy using a remote NPS:
1. If you have not already done so, configure the Policy Secure gateway for 802.1X
enforcement with the Windows client.
NOTE: You must configure an authentication protocol set that includes

the EAPSOH protocol for negotiation with the Windows supplicant.
2. Ensure that your NPS server is configured in accordance with the applicable server
documentation.
3. Ensure that the non-Pulse Secure supplicants are configured to authenticate

using the appropriate authentication protocols for SOH communication.
4. Under Settings, select the Use NPS Server check box. The Criteria section on the page
disappears. You cannot combine a remote NPS rule with a local rule.
5. Enter the following remote server settings:
 Server IP address
 Shared Secret of the server
 Maximum Retries
NOTE: To use SOH Host Checking on a Windows host machine, you must
configure the client to use EAP. Use the EAP enforcement ID 79623 for both
the Vista and Windows XP SP3 supplicants.
For Windows Vista instructions, see the following Web site:

http://thelazyadmin.com/blogs/thelazyadmin/archive/2008/02/21/configuring-thevista-
nap-client.aspx
For Windows XP SP3 instructions, see the following Web site:

http://thelazyadmin.com/blogs/thelazyadmin/archive/2008/02/11/configuring-thenap-
client-in-xp-sp3.aspx
Related Using Statement of Health Integration Host Checker Policies on page 527
Documentation


Implementing Host Checker Policies
After you create global policies, you can restrict Policy Secure gateway and resource
access by requiring Host Checker in the following ways:
 Realm authentication policy—When administrators or users try to sign in to the

Policy Secure gateway, the Policy Secure gateway evaluates the specified realm’s
authentication policy to determine when the preauthentication requirements include
Host Checker. You can configure a realm authentication policy to download Host
Checker, launch Host Checker and enforce Host Checker policies specified for the
realm, or you can not require Host Checker. The user must sign in using a computer
that adheres to the Host Checker requirements specified for the realm. If the
computer does not meet the requirements, then the Policy Secure gateway denies
user access unless you configure remediation actions to help the user bring his
computer into compliance. You can configure realm-level restrictions from the admin
console. If you have enabled Advanced Endpoint Defense, you can select this feature
from any realm.
 Role—When the Policy Secure gateway determines the list of eligible roles to which it
can map an administrator or user, it evaluates each role’s restrictions to determine
whether the role requires the user’s computer to adhere to certain Host Checker
policies. If it does and the computer does not follow the specified Host Checker
policies, then the Policy Secure gateway does not map the user to that role unless
you configure remediation actions to help the user bring the computer into
compliance. You can configure
role-mapping using settings in the Users > User Realms > SelectRealm > Role Mapping
page. You can configure role-level restrictions from the Host Checker page. If you have
enabled Advanced Endpoint Defense Malware Protection, you can implement this
feature for any role.

Executing Host Checker Policies

When the user tries to access the Policy Secure gateway, Host Checker evaluates policies
in the following order:
1. Initial evaluation—When a user first tries to access the Policy Secure gateway sign-
in page, Host Checker performs an initial evaluation. Using the rules you specify in your
policies, Host Checker verifies that the client meets endpoint requirements and
returns the results to the Policy Secure gateway. Host Checker performs an initial
evaluation regardless of whether you have implemented Host Checker policies at the
realm, role, or resource policy level.
For agentless deployments, if the user navigates away from the Policy Secure gateway
sign-in page after Host Checker starts running but before signing in to the Policy
Secure gateway, Host Checker continues to run on the user’s machine until the
process times out. If the Policy Secure gateway does not receive a result from Host
Checker for any reason (including the user manually terminating Pulse, OAC or Host
Checker), the Policy Secure gateway displays the remediation instructions (if they are
enabled), or displays an error and directs the user back to the sign-in page.
If the Host Checker process returns a result, the Policy Secure gateway then
evaluates the realm-level policies.
2. Realm-level policies—The Policy Secure gateway uses the results from Host
Checker’s initial evaluation to determine which realms the user can access. Then
the Policy Secure gateway displays or hides realms, allowing the user to sign only
into those realms that you enable for the sign-in page, and if the Host Checker
requirements for each realm are met. If the user cannot meet the Host Checker
conditions required by available realms, the Policy Secure gateway does not display
the sign-in page. Instead, it displays an error stating the user has no access unless
you bring the endpoint into compliance.
Note that Host Checker performs realm-level checks when the user first signs in to
the Policy Secure gateway and throughout the user’s session.
3. Role-level policies—After the user signs in to a realm, the Policy Secure gateway
evaluates role-level policies and maps the user to the role or roles if the Host
Checker requirements for those roles are met. Then, the Policy Secure gateway
pushes the role and policy information to the Infranet Enforcer and to Pulse or OAC.
If Host Checker returns a different status during a periodic evaluation, the Policy
Secure gateway dynamically remaps the user to roles based on the new results. If the
user loses rights to all available roles during one of the periodic evaluations, the
Policy Secure gateway disconnects the user session unless you bring the endpoint
into compliance.
4. Infranet Enforcer Resource Access Policies—After the Policy Secure gateway

pushes the role and policy information to the Infranet Enforcer and to Pulse or OAC,
the user can try to access a protected resource that is controlled by an Infranet
Enforcer resource access policy or Host Enforcer policy. The Infranet Enforcer and
Pulse or OAC determine whether to allow or deny the user access to the protected
resource based on the user’s assigned role.
If Host Checker returns a different status during a periodic evaluation, the new status
can change the assigned roles. The Policy Secure gateway then pushes the new role
and

policy information to the Infranet Enforcer and Pulse or OAC, which might prevent the
user from accessing the protected resource.
With either a success or failure, Pulse, OAC, or Host Checker remain on the client. Windows
users can manually uninstall OAC by choosing OAC in the Add or Remove Programs
control panel.
If you enable client-side logging through the, the directory where Pulse or OAC is installed
contains a log file, which the Policy Secure gateway appends each time the client or Host
Checker runs.
You can specify that the Policy Secure gateway evaluate your Host Checker policies
only when the user first tries to access the realm or role that references the Host
Checker policy. Or you can specify that the Policy Secure gateway periodically re-
evaluate the policies throughout the user’s session. If you periodically evaluate Host
Checker policies, the Policy Secure gateway dynamically maps users to roles and
instructs the Infranet Enforcer and Pulse or OAC to allow users access to new resources
based on the most recent evaluation.
Related Configuring Host Checker Restrictions on page 533

Documentation
 Specifying General Host Checker Options on page 540

Configuring Host Checker Restrictions
To specify Host Checker restrictions:
1. Select Authentication > Endpoint Security > Host Checker and specify global options
for Host Checker to apply to any user for whom Host Checker is required in an
authentication policy or a role-mapping rule.
2. To implement Host Checker at the realm level:
a. Select
 Administrators > Admin Realms > Select Realm > General > Restrictions > Host
Checker.
 Users > User Realms > Select Realm > General > Restrictions > Host Checker.
b. Select one of the following options for either all available policies or for individual
policies listed in the Available Policies column:
 Evaluate Policies—Evaluates without enforcing the policy on the client and

allows user access. This option does not require Host Checker to be installed
during the evaluation process; however, Host Checker is installed once the user
signs in to the Policy Secure gateway.
 Require and Enforce—Requires and enforces the policy on the client in order for
the user to log in to the specified realm. Requires that Host Checker is running

the specified Host Checker policies for the user to meet the access requirement.
Requires the Policy Secure gateway to download Host Checker to client
machines that do not support Pulse or OAC. If you choose this option for a realm’s
authentication policy, then the Policy Secure gateway downloads Host
Checker to the client machine after the user is authenticated and before the
user is mapped to any roles in the system. Selecting this option automatically
enables the Evaluate Policies option.
c. Select the Allow access to realm if any ONE of the selected “Require and Enforce”
policies is passed check box if you do not want to require users to meet all of the
requirements in all of the selected policies. Instead, the user can access the realm
by meeting the requirements of any one of the selected Host Checker policies.
d. To enable an Advanced Endpoint Defense Host Checker policy for a realm, move
Enhanced Endpoint Security: Malware Protection from Available Policies to Selected
Policies.
3. To implement Host Checker at the role level:
a. Select
 Administrators > Admin Roles > Select Role > General > Restrictions > Host Checker.
 Users > User Roles > Select Role > General > Restrictions > Host Checker.
b. Select one of the following options:
 Allow all users — Does not require Host Checker to be installed in order for the
user to meet the access requirement.
 Allow only users whose workstations meet the requirements specified by

these Host Checker policies — Requires that Host Checker is running the specified
Host Checker policies in order for the user to meet the access requirement.
 Select the Allow access to role if any ONE of the selected “Require and Enforce”
policies is passed check box if you do not want to require users to meet all of
the requirements in all of the selected policies. Instead, the user can access the
role if he meets the requirements of any one of the selected Host Checker policies.
c. To enable an Advanced Endoint Defense Host Checker policy for a role, move
Advanced Endpoint Defense: Malware Protection from Available Policies to Selected
Policies.
4. To create role-mapping rules based on a user’s Host Checker status:
a. Select Users > User Realms > Select Realm >Role Mapping.
b. Click New Rule, select Custom Expressions from the Rule based on list, and click
Update. Or, to update an existing rule, select it from the When users meet these
conditions list.
c. Click Expressions.
d. Write a custom expression for the role-mapping rule to evaluate Host Checker’s
status using the hostCheckerPolicy variable. For help writing the custom
expressions, use tips in the Expressions Dictionary.

e. In the ...then assign these roles section, select the roles that the Policy Secure
gateway should map users to when they meet the requirements specified in
the custom expression. Click Add.
f. Select the Stop processing rules when this rule matches for the Policy Secure
gateway to stop evaluating role-mapping rules if the user successfully meets the
requirements defined in this rule.
These options allow you to control which version of an application or service runs on
client machines.
Related Specifying General Host Checker Options on page 540

Documentation

Understanding Host Checker Policy Remediation
This topic describes Host Checker policy remediation. It includes the following information:
 Remediation Options on page 535

 Remediation User Experience on page 536
Remediation Options
You can specify general remediation actions for Host Checker to take if an endpoint does
not meet the requirements of a policy. For example, you can display a remediation page
to the user that contains specific instructions and links to resources to help the user bring
their endpoint into compliance with Host Checker policy requirements.
You can also include a message to users (called a reason string) that is returned by Host
Checker or an IMV and that explains why the client machine does not meet the Host
Checker policy requirements.
For example, the user might see a remediation page that contains the following custom
instructions, a link to resources, and reason strings:
Your computer's security is unsatisfactory.
Your computer does not meet the following security requirements. Follow the instructions
below to fix these problems. When you are done click Try Again. If you Continue without
fixing these problems, you may not have access to all of your intranet servers.
1. Symantec
Instructions: You do not have the latest signature files. Click here to download the latest
signature files. Reasons: The AntiVirus Product Version is too low.

The age of the Virus Definitions is not acceptable.
For each Host Checker policy, you can configure two types of remediation actions:
 User-driven—Using custom instructions and reason strings, you can inform the user
about the failed policy and how to make his computer conform. The user must take
action to successfully re-evaluate the failed policy unless you configure an IMV to
automatically remediate his computer. For instance, you can create a custom page
that is linked to a policy server or Web page and enables the user to bring his computer
into compliance.
 Automatic (system-driven)—You can configure Host Checker to automatically

remediate the user’s computer. For example, when the initial policy fails, you can kill
processes, delete files, or allow automatic remediation by an antivirus rule, a firewall
rule, or a registry setting rule. Host Checker does not inform users when performing
automatic actions. (You could, however,include information in your custom instructions
about the automatic actions.)
Remediation User Experience

Users might see a remediation page in the following situations:
 Before the user signs in:
 If you enable custom instructions or reason strings for a policy that fails, the Policy
Secure gateway displays the remediation page. The user has two choices:
 Take the appropriate actions to make the endpoint conform to the policy and then
click Try Again on the remediation page. Host Checker checks the user’s computer
again for compliance with the policy.
 Leave the endpoint in its current state and click Continue to sign in to the Policy
Secure gateway. The user cannot access the realm, role, or resource that requires
compliance with the failed policy.
If you do not configure the Policy Secure gateway with at least one realm that
allows access without enforcing a Host Checker policy, the user must bring the
endpoint into compliance before signing in to the Policy Secure gateway.
 If you do not enable custom instructions or reason strings for a policy that fails, Host
Checker does not display the remediation page. Instead, a message displays telling
the user that no additional information has been provided and to contact the system
administrator. The Policy Secure gateway does not assign the user a role that allows
access to protected resources.
 After the user signs in:
 OAC—During a session, if a user’s computer becomes noncompliant with the

requirements of a Host Checker policy, a pop-up message is displayed briefly in the
system tray that informs the user of the noncompliance. The user can display the
remediation page by right-clicking the OAC icon in the system tray, choosing OAC
Manager from the context menu, and then clicking the How do I resolve this problem
link in the status section of OAC window.

 Pulse—During a session, if a user’s computer becomes noncompliant with the Host

Checker policy, a message is displayed briefly in the system tray that informs the
user of the noncompliance. The remediation page is displayed on the client.
 Agentless—During a session, if a user’s agentless computer becomes noncompliant

with the Host Checker policy, the Policy Secure gateway displays the remediation
page to inform the user of the noncompliance. On Windows agentless computers,
Host Checker displays a bubble and tray icon if the endpoint becomes
noncompliant. The user must click the bubble or tray icon to open a browser
window that contains the remediation instructions. On Macintosh, Linux or Solaris
agentless computers, Host Checker automatically opens a browser window that
contains the remediation instructions as soon as the endpoint is noncompliant.
Related Configuring General Host Checker Remediation on page 537

Documentation


 Specifying Customized Requirements Using Custom Rules on page 505
Configuring General Host Checker Remediation
To specify remediation actions for a Host Checker policy:
2. Create or enable Host Checker policies.
3. Specify the remediation actions for Host Checker to perform if a computer does not
meet the requirements of the current policy:
 Enable Custom Instructions—Enter the instructions to display to the user on the

Host Checker remediation page. You can use the following HTML tags to format
text and to add links to resources such as policy servers or web sites: , , ,
, and <a href>. For example:
You do not have the latest signature files.
<a href=”www.company.com”>Click here to download the latest signature files.</a>
 Kill Processes—On each line, enter the name of one or more processes to kill if the
computer does not meet the policy requirements. You can include an optional MD5
checksum for the process. (You cannot use wildcards in the process name.) For
example:
keylogger.exe
MD5: 6A7DFAF12C3183B56C44E89B12DBEF56
 Delete Files—Enter the names of files to delete if the user’s computer does not
meet the policy requirements. (You cannot use wildcards in the file name.) Enter
one filename per line. For example:

c:\temp\bad-file.txt
/temp/bad-file.txt
 Send reason strings—Select this option to display a message to users (called a

reason string) that is returned by Host Checker or IMV and that explains why the
client machine does not meet the Host Checker policy requirements. This option
applies to predefined rules, to custom rules, and to third-party IMVs that use
extensions in the TNC SDK. For example, an antivirus IMV might display the
following reason string:
The AntiVirus Product Version is too low. The age of the Virus Definitions is not
acceptable.
NOTE: By sending reason strings, you are disclosing to users what the
IMV is checking on the client machine.
Related Understanding Host Checker Policy Remediation on page 535

Documentation

Upgrading the Endpoint Security Assessment Plug-In
The Endpoint Security Assessment Plug-in (ESAP) on the Policy Secure gateway
verifies third-party applications on endpoints for compliance with the pre-defined
rules you configure in a Host Checker policy. This plug-in is included in the
Policy Secure gateway system software package.
Pulse Secure frequently adds enhancements, bug fixes, and support for new
third-party applications to the plug-in. New plug-in releases are available independently
and more frequently than new releases of the Policy Secure gateway system software
package. If necessary, you can upgrade the plug-in on the Policy Secure gateway
independently of a Policy Secure gateway system upgrade.
You can upload up to four versions of the plug-in to the Policy Secure gateway, but the
Policy Secure gateway uses only one version at a time (called the active version). If
necessary, you can rollback to a previously active version of the plug-in.
If the endpoints in your deployment connect to multiple Policy Secure gateways

simultaneously, all of those connected Policy Secure gateways must use the same
version of the ESAP plug-in.

To upgrade the ESAP plug-in:
1. Download the Endpoint Security Assessment Plug-in from the Pulse Secure
Global Support Center to your computer:
a. Open the following page:
https://www.juniper.net/customers/csc/software/ive/releases/enterprise_infranet/index.jsp
b. To access the Customer Support Center, enter a username and password for a
Pulse Secure Global Support Center account.
c. Click the ESAP Download Page link.
d. Navigate to the ESAP release you want.
e. Download the plug-in zip file to your computer.
3. On the Host Checker page, under Manage Endpoint Security Assessment Plug-In
Versions:
a. If you previously uploaded four versions of the component software, you must
delete one of the versions before you can upload another one. Select the version
you want to delete and click Delete.
b. If you want the Policy Secure gateway to actively begin using the new component
software immediately after you upload it, select the Set as active after upload
option.
c. Click Browse, select the plug-in file to upload to the Policy Secure gateway and
click OK.
d. Click Upload. While the Policy Secure gateway uploads and decrypts the plugin
.zip file, the message “Loading...” is displayed in the plug-in list under Manage
Endpoint Security Assessment Plug-In Versions. If the Policy Secure gateway is
a member of a cluster, the Policy Secure gateway displays the message
“Loading...” while the plug-in is transferred to the other cluster nodes. After the
plug-in is installed, the date and time of the plug-in installation is displayed in
the plug-in list.
e. If you did not select the Set as active after upload option, activate the plug-in to
use by selecting the version in the plug-in, list and click Activate.

NOTE:
 If you attempt to activate a version of the plug-in that does not support all
of the predefined rules already configured in all Host Checker policies, the
Policy Secure gateway does not allow activation of that plug-in version.
For example, if a Host Checker policy is configured to use a predefined
rule to check for a version of antivirus software, and you attempt to
activate a plug-in version that does not support that version of the
antivirus software, the Policy Secure gateway does not allow you to
activate that plug-in version. To view the list of supported products for a
particular plug-in version, click the plug-in version number under Manage
Endpoint Security Assessment Plug-In Versions.
 You can rollback to an older plug-in version after you upgrade to a later
version by selecting the older version as the active version. But, if you
modified any Host Checker policies after you upgrade to the later version,
the rollback might not succeed. Rollback is guaranteed to succeed only if
the policies did not change.
 If you upgrade the Policy Secure gateway system software to a newer

version, or if you import a user configuration file, the currently active
plug-in version does not change. If you want to use a different plug-in
version after you upgrade or importing a user configuration file, you must
manually activate that plug-in version.
 If the Policy Secure gateway already has four versions of the plug-in
installed when you upgrade the Policy Secure gateway system software
to a newer version, the Policy Secure gateway automatically deletes the
oldest plug-in version and installs, but does not activate, the plug-in
included with the new Policy Secure gateway system software.

Documentation

Specifying General Host Checker Options
You can specify global options for Host Checker that apply to any user for whom Host
Checker is required in either an authentication policy or a role-mapping rule.
To specify general Host Checker options:
2. Under Options:
 In the Perform check every X minutes field, specify the interval at which you want
Host Checker to perform policy evaluation on a client machine. If the client machine
fails to meet the requirements of the Host Checker policies required by a role, then
the Infranet Enforcer or OAC denies the associated user requests.

For example, you might require that a user runs a specific third-party antivirus
application to map to Role A, which enables the user to access protected resources.
If the user’s client machine is running the required antivirus application when the
user signs in to the Policy Secure gateway, then the user maps to Role A and is
granted access to the protected resources specified for Role A in an Infranet Enforcer
resource access policy. However, if the antivirus application stops running during
the user session, the next time Host Checker runs, the user fails to meet the
security requirements for Role A and, therefore, loses all access privileges for Role
A.
When a user logs in to a Realm, Host Checker performs an initial policy check,
regardless of whether the policy is enforced at the realm, role, or resource level. The
initial policy check establishes a start time. Host Checker evaluates policies at the
frequency set by the Perform check every X minutes option, starting the clock at
the initial policy check. Although the frequency setting is set globally for all Host
Checker policy checking, it is not synchronized for all user clients connected to the
Policy Secure gateway. Each client performs its own initial policy check and starts
its own countdown. If you configure the authentication policy within a realm
where Host Checker enforces policies (versus installing), the enforcement occurs
only during the preauthentication phase. After an end-user signs in and for the
duration of the user’s session, any subsequent Host Checker policy checks have no
impact on realm access, meaning that there is no concept of removing an end-
user session from a realm once a user successfully authenticates into that realm.
If you configure a role restriction where Host Checker enforces policies, the
enforcement occurs just after authentication during role-mapping. Role restrictions
are enforced periodically during the end-user session at an interval specified using
the Host Checker frequency setting. If the user successfully passes the Host Checker
evaluation during role-mapping but later fails X minutes after login, that specific
user loses rights to that role. If the user loses rights to all available roles due to Host
Checker policy evaluation, the user session is disconnected.
NOTE: If you enter a value of zero, Host Checker runs on the client
machine only when the user first signs in to the Policy Secure
gateway.
 (Applies to agentless access deployments only) For the Client-side process, login
inactivity timeout option, specify an interval to control timing out in the following
situations:
 If the user navigates away from the Policy Secure gateway sign-in page after Host
Checker starts running but before signing in to the Policy Secure gateway, Host
Checker continues to run on the user’s machine for the interval you specify.
 If the user is downloading Host Checker over a slow connection, increase the
interval to allow enough time for the download to complete.
4. Implement the policy at the realm or role levels. To verify that the package itself is
installed and running on the client computer (as opposed to a specific policy in the
package passing or failing) you can use the name you specified when you uploaded
the policy package (for example, myPestPatrol). To enforce a particular policy in the

package, use the syntax <PackageName>, <PolicyName>. For example, to enforce

the FileCheck policy in the myPestPatrol package, use myPestPatrol.FileCheck.
Related Configuring Host Checker Restrictions on page 533

Documentation

Specifying Host Checker Installation Options
 Automatic installation:
 OAC on Windows—If you enable OAC installation, the first time the user accesses
the Policy Secure gateway using a Web browser, the Policy Secure gateway
automatically downloads agentless Host Checker to evaluate Host Checker
restrictions for
role-mapping. After the initial check is successfully completed, the Policy Secure
gateway downloads OAC with its built-in Host Checker component to the user’s
computer. If you evaluate or enforce a Host Checker policy at the realm level, OAC
automatically runs its built-in Host Checker on the endpoint to verify security
compliance.
 Pulse on Windows—Pulse installation and functionality is similar to that of OAC.

You must select Minimal components or All components as the component set.
 OAC on Macintosh—On the Macintosh, users must manually install OAC. The Host
Checker component is a part of the installation.
 Agentless and Java agent—For agentless or Java agent deployments, the user signs
into the Policy Secure gateway directly using a Web browser instead of OAC. If you
evaluate or enforce a Host Checker policy at the realm level, the Policy Secure
gateway automatically installs and runs Host Checker on the endpoint to verify
security compliance.
If you evaluate or enforce a Host Checker policy for Windows OAC, the Java agent,
or agentless deployments, the Policy Secure gateway evaluates the realm-level
option when the user connects to the Policy Secure gateway or accesses the sign-in
page and then determines if the current version of OAC or Host Checker is installed
on the user’s machine. If OAC or Host Checker is not installed, the Policy Secure
gateway attempts to install it using either an ActiveX or a Java delivery method.
 When a Windows user first signs in to the Policy Secure gateway, the Policy Secure
gateway attempts to install an ActiveX control on the user’s system. If the Policy
Secure gateway successfully installs the ActiveX control, the control manages the
installation of Host Checker in agentless access deployments. If the Policy Secure
gateway cannot install the ActiveX control because ActiveX is turned off on the
user’s system, the Policy Secure gateway attempts to install Host Checker using
Java.
 For Linux and Solaris hosts, the Policy Secure gateway always uses the Java delivery
method. The Java delivery method requires only user privileges, but Java must be
enabled on the user’s system. For the Firefox browser on Linux, the Java runtime
and plug-in must be installed.
 If the Policy Secure gateway cannot use the Java delivery method because Java is
disabled on the user’s system, the Host Checker policy fails and might cause
restrictions on realms or roles where the policy is evaluated. If no other realms or
roles are available to the user, the Policy Secure gateway displays a no-access error
message.

 The user or administrator manually installs Pulse, OAC or Host Checker—Download

the OAC installer, the Pulse installer, or the Host Checker installer from and use it to
manually install OAC or Host Checker on the user’s system.
NOTE: To install Pulse, OAC, or Host Checker, users must have appropriate
privileges, as described in the Client-side Changes Guide on the Pulse
Secure Support site.
Related Installing Host Checker Automatically or Manually on page 543

Documentation

Installing Host Checker Automatically or Manually
For agentless access deployments only, you can configure the Policy Secure gateway
to automatically install Host Checker on client computers.
To automatically install Host Checker on client computers:
2. Under Options, select Auto-upgrade Host Checker if you want the Policy Secure
gateway to automatically download the Host Checker application to a client
computer when the version of Host Checker on the Policy Secure gateway is newer
than the version installed on the client. If the Auto-upgrade Host Checker option is
selected or not selected, the following events occur:
 If Host Checker is not installed on the client computer, Host Checker is installed
automatically regardless of whether the Auto-upgrade Host Checker option is
selected or not selected.
 If the Auto-upgrade Host Checker option is selected and a previous version of Host
Checker is installed, Host Checker is upgraded on the client automatically.
 If the Auto-upgrade Host Checker option is not selected and a previous version of
Host Checker is installed, Host Checker is not upgraded the client automatically.
If you select the Auto-upgrade Host Checker option, note the following:
 On Windows, the user must have administrator privileges in order for the Policy
Secure gateway to automatically install the Host Checker application on the
client. For more information, see the Client-side Changes Guide on the Pulse
Secure Global Support Center.
 If the user uninstalls Host Checker and then signs in to a Policy Secure gateway
for which the Auto-upgrade Host Checker option is not enabled, the user no
longer has access to Host Checker.
The Maintenance > System > Installers page of the admin console provides OAC and
Host Checker client applications. You can download the applications or service as a
Windows executable file, which enables you to:

 Distribute the file to client machines using software distribution tools. This option
enables you to install an application or service on client machines whose users do not
have Administrator privileges, which are required to install the application or service.
 Post the executable in a secure repository so that users with the proper administrator
right may download and install the appropriate version.
 Download and execute a script that automatically retrieves the proper version of the
installer from an FTP server.
Related Specifying Host Checker Installation Options on page 542

Documentation

Using Host Checker Logs
You can enable client-side logging for the Host Checker and OAC. When you enable this
option, the Policy Secure gateway writes a client-side log to endpoints. The Policy
Secure gateway appends to the log file during user session. This feature is useful when
you work with the support team to debug problems with the respective feature.
Because these settings are global, the Policy Secure gateway writes a log file to all
clients that use the feature for which you enable client-side logging. Also, the Policy
Secure gateway does not remove client-side logs. Users must manually delete log files
from the clients. For information about where the Policy Secure gateway installs log
files, see the Client-Side Changes Guide on the Pulse Secure Global Support Center.
To specify global client-side logging settings:
1. In the admin console, select System > Log/Monitoring > Client Log > Settings.
2. Select the features for which the Policy Secure gateway writes client-side logs.
3. Click Save Changes to save these settings globally.

Documentation


PART 4
System Management
 Network and Host Administration on page 547
 Certificate Security Administration on page 593
 FIPS Level 1 Support (Software FIPS) on page 637
 Configuration File Administration on page 657
 System Maintenance on page 699
 Logging and Monitoring on page 715
 Troubleshooting Tools on page 751
 Clustering on page 773
 Customizable Admin and End-User UIs on page 801
 Delegating Administrator Roles on page 803
 Deployments with IDP on page 813


CHAPTER 15
Network and Host Administration
This chapter describes how to configure network and host settings. It includes the
 Network and Host Administration Overview on page 547

 Configuring the Internal Port on page 548
 Configuring the External Port on page 553
 Using the Management Port on page 557
 Configuring VLAN Ports on page 563
 Using Virtual Ports on page 566
 Configuring the System Date and Time on page 571
 Configuring Network Services on page 574
 Managing the Routes Table on page 577
 Managing the Hosts Table on page 579
 Managing the ARP Table on page 580
 Managing the Neighbor Discovery Table on page 581
 Configuring SSL Options on page 582
 Configuring Miscellaneous Security Options on page 587
 Using the Serial Port on page 589
Network and Host Administration Overview
When you install and initially set up the device, you use the serial port console to set basic
network and host settings. To get started, you must use the serial console to configure
these settings for the internal interface. You have the option to use the serial console to
configure network and host settings for the external interface and the management
interface. The network and host settings you configure with the serial port console include:
 IPv4 address
 Netmask
 Default gateway
 Speed and duplex

 MTU
 DNS
 Default domain
 WINS
Once the internal interface has been configured, you can use the admin console Network
Settings pages to modify settings for the internal interface, to enable and configure the
external interface and the management interface, and to configure or manage advanced
networking features, including:
 Hostname
 IPv6 addresses
 VLAN ports
 Virtual ports
 Route table entries
 Host mapping table entries
 ARP cache entries
 Neighbor discovery cache entries
 System date and time (manual configuration) or NTP
Related Using the Serial Port on page 589

Documentation
 Configuring the Internal Port on page 548

 Using the Management Port on page 557
 Configuring VLAN Ports on page 563
 Using Virtual Ports on page 566
 Configuring Network Services on page 574
 Managing the Routes Table on page 577
 Managing the Hosts Table on page 579
 Managing the ARP Table on page 580
 Managing the Neighbor Discovery Table on page 581
 Configuring the System Date and Time on page 571
Configuring the Internal Port
The internal port connects to the local area network (LAN). The internal port settings
are configured when you run the setup wizard from the serial console as part of the

Chapter 15: Network and Host Administration
installation procedure. You can use the System > Network pages to make changes to
the configuration.
To modify the internal port configuration:
1. Select System > Network > Internal Port > Settings to display the configuration page.
3. Save your changes.

Figure 110: Internal Port Configuration Page

Figure 111: Internal Port SAS Configuration Page
Table 59: Internal Port Configuration Guidelines
Settings Guidelines
IPv4 Settings

Table 59: Internal Port Configuration Guidelines (continued)
Settings Guidelines
IP Address Assign an IP address. You must assign an IPv4 address to the internal interface.
An IP address is an identifier for a computer or device on a TCP/IP network. Networks using the
TCP/IP protocol route messages based on the IP address of the destination.
The format of an IPv4 address is a 32-bit numeric address written as four numbers separated by
periods. Each number can be 0 to 255.
Netmask Assign a netmask. A netmask indicates which part of an IP address indicates network identification
and which part indicates the host identification. For example, the IP address and netmask 10.20.30.1
255.255.255.0 (or 10.20.30.1/24) refer to all the hosts in the 10.20.30.0 subnet. The IP address and
netmask 10.20.30.1 255.255.255.255 (or 10.20.30.1/32) refer to a single host.
Default Gateway Specify the IPv4 address for the default gateway for the routing domain to which the device belongs.
A gateway is the router that resides at the point of entry to the current routing domain, often called
the default gateway.
IPv6 Settings
Enable IPv6 / Disable Disabled by default. Enable to support access from IPv6 endpoints.
IPv6
When you enable IPv6, the system acquires a link local address.
If you switch from enabled to disabled, the system clears the link local address.
Link Local Address Display the autoconfigured link local address (after you have enabled and saved the IPv6
configuration).
IPv6 Address Specify a routable IPv6 address, such as a global unicast address that your network plan has
provisioned for this host and interface. Automatic configuration methods are not supported. You
must specify the appropriate address manually.
Prefix Length Specify how many of the higher order contiguous bits of the IPv6 address comprise the prefix (the
network portion of the IPv6 address). The default is 64.
Gateway Specify the IPv6 address for the default gateway for the routing domain to which the device belongs.
Advanced Settings
MAC Address Display the MAC address for the interface.
Link Speed Specify the speed and duplex combination for the interface.
If you run SNMP_GET and then change the Link Speed value, you must wait at least 5 minutes after
submitting the change before running SNMP_GET again.

Table 59: Internal Port Configuration Guidelines (continued)
Settings Guidelines
ARP Ping Timeout (IPv4 only.) Specify how long the system should wait for responses to Address Resolution Protocol
(ARP) requests before timing out. Cluster nodes send ARP requests to the gateways of other nodes
to determine if they are properly communicating with one another.
If you have not deployed a cluster, the system does not use this setting. If the node belongs to a
cluster, the timeout interval that you specify is synchronized across the cluster. In multisite clusters,
you can override this setting for the individual nodes in the cluster using options in the System >
Clustering page. Use caution when changing this setting in active/passive clusters, however,because
the system also uses the ARP Ping Timeout setting on the Internal tab as a failover timer for the
VIP.
MTU Specify the maximum transmission unit.
If IPv6 is enabled, the valid range is 1280 to 1500. If IPv6 is not enabled, the valid range is 576 to
1500.
We recommend you retain the default MTU setting (1500) unless you must change the setting for
troubleshooting purposes.
Related Network and Host Administration Overview on page 547

Documentation

Configuring the External Port
The external port connects to the Internet. You can use the System > Network pages to
configure the external port.
To configure the external port:
1. Select System > Network > External Port > Settings to display the configuration page.

Figure 112: External Port Configuration Page

Figure 113: External Port SAS Configuration Page
Table 60: External Port Configuration Guidelines

Settings Guidelines
Use Port?
Use Port? Select Enabled to use the port; otherwise, select Disabled.

Table 60: External Port Configuration Guidelines (continued)
Settings Guidelines
IPv4 Settings
IP Address Specify an IP address. An IP address is an identifier for a computer or device on a TCP/IP network.
Networks using the TCP/IP protocol route messages based on the IP address of the destination.
Netmask Specify a netmaks. A netmask indicates which part of an IP address indicates network identification
IPv6 Settings
Enable IPv6 / Disable Disabled by default. Enable to support access from IPv6 endpoints.
IPv6
configuration).
Prefix Length Specify how many of the higher order contiguous bits of the IPv6 address comprise the prefix (the
Advanced Settings

Table 60: External Port Configuration Guidelines (continued)
Settings Guidelines
VIP.
1500.

Documentation

Using the Management Port
This topic describes how to configure the management port. It includes the following
information:
 Management Port Overview on page 557

 Supported Platforms on page 558
 Configuring the Management Port on page 558
 Using the Serial Console to Configure the Management Port on page 562
 Importing Configurations that Include a Management Port Configuration on page 562
 Configuring Administrator Access on page 563
Management Port Overview

You connect the management port to an Ethernet switch or router that is part of your
internal local area network (LAN) and that can connect to your network management
infrastructure. When the management port is enabled, the following traffic is directed
out the management port: archiving (FTP/SCP), NSM, NTP, push config, SNMP, syslog.
When the management port is not enabled, that traffic uses the internal port.
NOTE: On Pulse Policy Secure systems, you cannot configure the user
realm configuration, the RADIUS client configuration, or the Infranet Enforcer
configuration to use the management port.

Supported Platforms
The following hardware platforms are equipped with a management port:
 IC6500
SA6000, SA6500
 MAG4610
 MAG Series SM160, SM360, SM860
Configuring the Management Port

To configure the management port:
1. Select System > Network > Management Port > Settings to display the configuration
page.

Figure 114: Management Port Configuration Page – Pulse Policy Secure

Figure 115: Management Port Configuration Page – Pulse Connect Secure
Table 61: Management Port Configuration Guidelines
Settings Guidelines
Use Port?

Table 61: Management Port Configuration Guidelines (continued)
Settings Guidelines
IPv4 Settings
IP Address Specify an IP address. An IP address is an identifier for a computer or device on a TCP/IP network.
Networks using the TCP/IP protocol route messages based on the IP address of the destination.
Netmask A netmask indicates which part of an IP address indicates network identification and which part
indicates the host identification. For example, the IP address and netmask 10.20.30.1 255.255.255.0
(or 10.20.30.1/24) refer to all the hosts in the 10.20.30.0 subnet. The IP address and netmask
10.20.30.1 255.255.255.255 (or 10.20.30.1/32) refer to a single host.
IPv6 Settings
Enable IPv6 / Disable Disabled by default. Enable to support network management traffic over IPv6 networks.
IPv6
configuration).
Prefix Length Specify how many of the higher-order contiguous bits of the IPv6 address comprise the prefix (the
Advanced Settings

Table 61: Management Port Configuration Guidelines (continued)
Settings Guidelines
VIP.
1500.
Using the Serial Console to Configure the Management Port

To configure management port network settings from the serial console:
1. Start a serial console session.
2. Select item 1, System Settings and Tools.
3. Select item 10, Configure Management port. The text indicates if the option is enabled
or disabled.
4. Enter the network settings for the Management Port, as prompted.
NOTE: If you enable the Management Port but neglect to configure the
IP address and netmask, the port reverts to a disabled state. Also, you
cannot clear Management Port settings from the serial console when the
port is disabled, though you can clear them from within the admin console.
5. When prompted to accept the changes, if they are correct, enter y. Otherwise, repeat
the process to correct the settings.
6. Close the serial console.
Importing Configurations that Include a Management Port Configuration

If you import a configuration from a system that does not support a management port
into a system that has an enabled management port and you import everything, including
licenses, the management port on the target system will appear to be removed. The
management port actually continues to be operational and will reappear along with its
original configuration when you reapply the management port license for the target
system. If you import to the target but specify the Import everything except network

settings and licenses option, the management port and its configuration persist on the
target system and the port is operational.
Configuring Administrator Access

You can configure the Administrators > Admin Realm > Authentication Policy > Source
IP restrictions configuration to enable administrator sign-in through the management
port.
You can use Administrator realms to control administrator access to system ports,
including the management port.
To control administrator access to the management port:
1. Enable the management port.
2. Perform one of the following steps:
 Choose Administrators > Admin Realms > Admin Users to modify the default admin
users realm.
 Choose Administrators > Admin Realms, then click New, to create a new administrator
realm.
3. Click the Authentication Policy tab.
4. Scroll to the bottom of the Source IP tab. You should see a message stating that the
Management Port is enabled, along with a link to the Network Settings page.
5. Select the available options to allow administrators to sign in to all available ports,
to the management port or the internal port only, or to restrict them from signing in
to any of the ports. In some cases you may inadvertently limit administrative access
completely. If this occurs, you can reconfigure the ports by way of the serial console.

Documentation

Configuring VLAN Ports
Your network design might include VLANs to provide network segmentation. When
connected to a trunk port on a VLAN-enabled switch, the system encounters traffic from
all VLANs. This is useful for network designs with separate VLANs for separate classes
of users or endpoints, and for making the system accessible from all VLANs. You can use
RADIUS attributes to place different users in different network segments.
The system supports IEEE 802.1Q VLAN tagging. You must define a VLAN port for each
VLAN. The internal port must be assigned to the root system and must be marked as the
default VLAN. Routes to servers reachable from the VLAN interfaces must have the
next-hop gateway set to the configured gateway for the VLAN interface, and must have
the output port defined as the VLAN port.

When you save the configuration for a new VLAN port, the system creates two static
routes by default:
 The default route for the VLAN pointing to the default gateway.
 The interface route to the directly connected network.
To configure a VLAN port:
1. Select System > Network > VLANs.
2. Click New Port to display the configuration page.
Figure 116: VLAN Port Configuration Page

Figure 117: VLAN Port SAS Configuration Page
Table 62: VLAN Port Configuration Guidelines
Settings Guidelines
Use Port?
VLAN Settings
Port Name Specify a name that is unique across all VLAN ports that you define on the system or cluster. Only
alphanumeric characters, "-", or "_" are allowed.
VLAN ID Specify a number between 1 and 4094. The VLAN ID assignment must be unique on the system.
IPv4 Settings
IP Address Specify an IP address and netmask combination that is from the same network as the VLAN. VLAN
IP addresses must be unique. You cannot configure a VLAN to have the same network as the internal
port. For example, if the internal port is 10.64.4.30/16 and you configure a VLAN as 10.64.3.30/16,
you might get unpredictable results and errors.

Table 62: VLAN Port Configuration Guidelines (continued)
Settings Guidelines
Netmask Specify a netmask. A netmask indicates which part of an IP address indicates network identification
NOTE: Link speed, ARP ping timeout, and MTU settings are inherited from
the internal port configuration.
Related Configuring the Internal Port on page 548

Documentation

Using Virtual Ports
This topic describes virtual ports. It includes the following information:
 Configuring Virtual Ports on page 566

 Using Device Certificates with Virtual Ports on page 568
Configuring Virtual Ports

You can use virtual ports to provide different groups of users access to the same system
using different IP aliases and domains.
Virtual ports are associated with the physical internal port and physical external port.
The virtual port shares all of the network settings with the associated physical port,
except for the IP address.
When you configure virtual ports, you in essence are creating name-IP address pairs. The
names and IP addresses must be unique in your network. An alias can include IPv4
addresses, IPv6 addresses, or both. However, the corresponding IP protocol must be
enabled on the physical port for the address(es) to take effect.
To configure a virtual port:
1. Select System > Network > PortName> Virtual Ports. PortName is Internal Port or
External Port.
2. Click New Port to display the configuration page.

Figure 118: Virtual Port Configuration Page
Figure 119: Virtual Port SAS Configuration Page
Table 63: Virtual Port Configuration Guidelines
Settings Guidelines
Name Specify a name for the virtual port. The names and IP addresses in the virtual port configuration
must be unique in your network.
Physical Port Display the name of the physical port associated with the virtual port. The virtual port inherits link
speed, ARP ping timeout, and MTU settings from the physical port configuration.

Table 63: Virtual Port Configuration Guidelines (continued)
Settings Guidelines
IPv4 Address Specify an IPv4 address. An alias can include IPv4 addresses, IPv6 addresses, or both. However,
the corresponding IP protocol must be enabled on the physical port for the address(es) to take
effect.
IPv6 Address Specify an IPv6 address. An alias can include IPv4 addresses, IPv6 addresses, or both. However,
the corresponding IP protocol must be enabled on the physical port for the address(es) to take
effect.
Using Device Certificates with Virtual Ports

Virtual ports can be used to create multiple fully qualified domain names for user sign-in.
When a user tries to sign in using the IP address defined in a virtual port, the system
presents the certificate associated with the virtual port to initiate the SSL transaction.
You can approach the digital certificate security and virtual ports implementation in
either of the following ways:
 Associate all hostnames with a single certificate—With this approach, you use a single
wildcard certificate to validate the identity of all system hostnames, regardless of
which hostname is used to sign in. A wildcard certificate includes a variable element
in the domain name, making it possible for users who sign in from multiple hosts to
map to the “same” domain. For example, if you create a wildcard certificate for
*.yourcompany.com, the system uses the same certificate to validate its identity to
users who sign in to employees.yourcompany.com as it does to users who sign into
partners.yourcompany.com.
 Associate each hostname with its own certificate—With this approach, you associate
different hostnames with different certificates. Create a virtual port for each hostname.
A virtual port activates an IP alias on a physical port. For example, you can create two
virtual ports on a single appliance, mapping the first virtual port to the IP address
10.10.10.1 (sales.yourcompany.com) and the second virtual port to the IP address
10.10.10.2 (partners.yourcompany.com). Then you can associate each of these virtual
ports with its own certificate, ensuring that users authenticate through different
certificates.
To associate certificates with virtual ports:
1. Create virtual ports.
2. Import the device certificates.

3. Associate the device certificates with the virtual ports:
a. Select System > Configuration > Certificates > Device Certificates.
b. Click the link of the device certificate you want to configure to display the
configuration page.
Figure 120 on page 569 shows the configuration page for Pulse Policy Secure. The
configuration page for Pulse Connect Secure is similar.
c. Use the controls in the “Present certificate on these ports” section to associate
ports with the certificate.
Figure 120: Certificate Details Page

Related Configuring the Internal Port on page 548

Documentation

 Using Device Certificates on page 595

Configuring the System Date and Time
You can use the admin console to set the system date and time manually or by configuring
a network time protocol (NTP) server. The system supports NTPv4, which is backwards
compatible with NTPv3 and NTPv2.
BEST PRACTICE: We recommend you use NTP to synchronize the date and
time clocks on all network systems. Using NTP obviates issues that might
occur with cluster synchronization, network communication that uses
time-sensitive protocols, such as SAML, and implementation of time-based
policies, such as local authentication server account expiration. In addition,
using NTP as a standard in your network rationalizes timestamps in logs,
which facilitates reporting and troubleshooting.
To set the system date and time:
1. Select System > Status to display the System Status dashboard.
2. Click the System Date and Time Edit link to display the configuration page.

Figure 121: Date and Time Configuration Page – Pulse Policy Secure

Figure 122: Date and Time Configuration Page – Pulse Connect Secure
Table 64: Date and Time Configuration Guidelines
Settings Guidelines
Time Zone Select your time zone. Selecting the appropriate time zone enables the system to automatically adjust
the time for Daylight Saving Time changes.
Use NTP Server

NTP Server Specify the fully qualified domain name or IP address for the NTP server.
Key If you are using NTPv4, specify the symmetric key.
The key must be pre-synchronized with the NTP server. For example, if you want to configure NIST’s
clock as the NTP server, you must request a key beforehand and have NIST send that key to you.
The key for MD5 is in the following format:
KeyNumber M KeyValue
The key for SHA1 is in the following format:
KeyNumber SHA1KeyValue
Secondary NTP Specify the fully qualified domain name or IP address for a secondary NTP server.
Server
If the system fails three times to reach the primary server or if the authentication fails three times, the
system attempts to contact the secondary NTP server.

Table 64: Date and Time Configuration Guidelines (continued)
Settings Guidelines
Key If you are using NTPv4, specify the symmetric key.
Update Interval Specify an update interval. The maximum interval is 999999 (enforced by the user interface).
Set Time Manually

Date Specify the date. You can click Get from Browser to automatically populate the Date and Time fields.
Time Specify the time and select AM or PM.
Related Displaying System Status on page 731

Documentation

Configuring Network Services
You configure DNS and WINS services when you initially configure the system with the
serial console. If necessary, you can use the System > Network > Overview page to modify
the configuration. You can also use this page to configure a hostname.
The network services overview page also displays the node name (if the node belongs
to a cluster), and the status and interface statistics for the internal port, external port,
and management port.
To configure network services:
1. Select System > Network > Overview to display the configuration page.

Figure 123: Network Services Configuration Page

Figure 124: Network Services SAS Configuration Page
Table 65: Network Services Configuration Guidelines
Settings Guidelines
Status
Status Display interface statistics for the internal port, external port, and management port.
Network Identity

Table 65: Network Services Configuration Guidelines (continued)
Settings Guidelines
Hostname Specify a fully qualified hostname. For example, domain.company.com. The hostname cannot
exceed 30 characters
DNS Name Resolution

Primary DNS Specify the IP address for the primary DNS server.
Secondary DNS Specify the IP address for the secondary DNS server.
DNS Domain(s) Specify a comma-separated list of default domains. The system searches the domains in the order
they are listed.
Windows Networking
WINS Specify the hostname or IP address of a local or remote Windows Internet Naming Service (WINS)
server that you use to associate workstation names and locations with IP addresses.
Bandwidth This feature is available only on Pulse Connect Secure.

Management
Total Maximum Specify the maximum bandwidth for all traffic.
Bandwidth
VPN Tunnels Maximum Specify the maximum bandwidth for VPN tunnel traffic.
Bandwidth
NOTE: The value of total maximum bandwidth must be greater than the value of VPN tunnels
maximum bandwidth.
Related  Network and Host Administration Overview on page 547

Documentation
Managing the Routes Table
The system populates the routes table with dynamic, autodiscovered routes. Many
networks will not require changes to this routing table. If necessary, you can delete routes
or add static routes.
To manage the routes table:
1. Select System > Network > Routes to display the routes table.
Figure 125 on page 578 shows the routes for Pulse Policy Secure.
Figure 126 on page 578 shows the routes for Pulse Connect Secure.
2. Use the controls described in Table 66 on page 578 to manage the routes table.

Figure 125: Routes Table
Figure 126: Routes Table for SAS
Table 66: Routes Table Controls
Controls Description
View route table for Use the controls to change the display to show the route table for internal, external, or management
interfaces; and for IPv4 or IPv6 routes.
Delete Select a row in the table and click Delete to delete a route.
New Route Click New Route and complete the configuration to add a route to the table.
You must specify a valid IP address, gateway, DNS address, and metric. The metric is a way of
comparing multiple routes to establish precedence. Generally, the lower the number (from 1 to 15),
the higher the precedence. Thus, a route with a metric of 2 is chosen over a route with a metric of
14. The metric value of zero (0) identifies the route as one that should not be used.

Documentation

Managing the Hosts Table
In general, the system uses the configured DNS servers to resolve hostnames, but it also
maintains a local hosts table that can be used for name resolution. The system populates
some entries from host-IP address pair settings in your configuration. You can add host-IP
address mappings for other hosts that might not be known to the DNS servers used by
the system, or in cases where DNS is not reachable.
To manage the hosts table:
1. Select System > Network > Hosts to display the hosts table.
Figure 127 on page 579 shows the hosts table for Pulse Policy Secure.
Figure 128 on page 579 shows the hosts table for Pulse Connect Secure.
2. Use the controls described in Table 67 on page 579 to manage the hosts table.
Figure 127: Hosts Table – Pulse Policy Secure
Figure 128: Hosts Table – Pulse Connect Secure
Table 67: Hosts Table Controls
Add Specify an IP address, hostname, and comment (a description for the benefit of system
administrators), and click Add.
Delete Click the delete icon in the last column to delete the row from the table.


Documentation

Managing the ARP Table
ARP stands for Address Resolution Protocol. In IPv4 networking, network nodes use ARP
to maintain information about peer network nodes. ARP is used to associate the Layer
3 IP address with a Layer 2 MAC address of neighboring peer nodes. The system maintains
an ARP table with dynamic, cached entries, and you can add static entries if necessary.
The system caches dynamic entries for up to 20 minutes. Dynamic entries are deleted
during a reboot. Static entries are restored after a reboot.
To manage the ARP table:
1. Select System > Network > Port > ARP Cache. Port is the Internal Port, External Port,
or Management Port tab.
Figure 129 on page 580 shows the ARP table for the internal port for Pulse Policy
Secure.
Figure 130 on page 581 shows the ARP table for the internal Port for Pulse Connect
Secure.
2. Use the controls described in Table 68 on page 581 to manage the ARP table.
Figure 129: ARP Table

Figure 130: ARP Cache Table
Table 68: ARP Table Controls
Delete Select a row in the table and click Delete to delete the entry.
Delete Dynamic Entries Delete all dynamically discovered entries.
Add Specify an IP address, a MAC address, and click Add to add an entry. If you add an entry that has
the same IP address as an existing entry, the system overwrites the existing entry with your new
entry. Also note that the system does not verify the validity of MAC addresses.

Documentation

Managing the Neighbor Discovery Table
In IPv6 networking, network nodes use the Neighbor Discovery Protocol (NDP) to determine
the Layer 2 MAC addresses for neighboring hosts and routers. The system uses NDP to
maintain a cache of neighboring routers that are reachable and can forward packets on
its behalf.
NOTE: In the current release, you can view discovered neighbors or clear the
entire cache, but you cannot add neighbors or delete individual entries.
To manage the neighbor discovery table:
1. Select System > Network > Port > ND Cache. Port is the Internal Port, External Port, or
Management Port tab.
Figure 131 on page 582 shows the neighbor discovery table for the internal port for
Pulse Policy Secure.
Figure 132 on page 582 shows the neighbor discovery table for the internal port for
Pulse Connect Secure.

2. Use the controls described in Table 69 on page 582 to manage the neighbor discovery
table.
Figure 131: Neighbor Discovery Table
Figure 132: Neighbor Discovery Table for SAS
Table 69: Neighbor Discovery Table Controls
Flush NDP Entries Delete all dynamically discovered entries.

Documentation
Configuring SSL Options
Use the System > Configuration > Security > SSL Options page to change the default
security settings. We recommend that you use the default security settings, which provide
maximum security, but you may need to modify these settings if your users cannot use
certain browsers or access certain Web pages.
To configure SSL options:
1. Select System > Configuration > Security > SSL Options to display the configuration
page.


Figure 133: SSL Options Configuration Page

Allowed SSL and TLS Version

The older SSL V2 protocol has know n secur ty issues addressed by SSL V3 and TLS.Older brow sers may only su
TLS stands for TLS 1.0,1.1and 1.2.
e;> Accept on y TLS (maximize secur ty with reduced compatibility)

@Accept only SSL V3 and TLS (maximize security}
eJ Accept SSL V2 and V3 and TLS (maximize brov.ser compat b lity)

Allowed Encryption Strength
Strong ciphers (rated by the number of bits inthe cipher)improve the secur ty of SSL encrypt on,but some brow:
support 40-b
it ciphers.When there is more than one acceptable cipher,the Junos Pu lse Access ControlService v-
to the cipher with thefastest data transfer rate regardless of its relative encryption strength. Changing the eno
cause the w eb service to restart.P
lease see the Setting Security Opt ons sectionin the Admin gu
ide for more de
Accept on y 168-bit and greater (max m

ize security}
!(}Accept on y 128-bit and greater (security and brov.ser compat b lity)
(E) Accept 40-bit and greater (maximize brov.ser compatbity)

[ ]custom SSL Cipher Se ect on
Note:Custom cipher selection disables the Encrypt on Strength option.
Clpher Suites (>= g

Hedoum
8 b1
t) (>=·
Low
b t (> =
aO
I
d b1t
I Descr ption
I
IAES/ 3DES
I < 168-bit) < 128-bit)
r-,phe
_c_su ote
_
s_u_
so
_
n g_
tco ple_D
_E
_
S_
nd
a_A
_E
_S_(M
ax
__om_
ozes_e,u,ty)
1
IAES C.I cipher su tes using AES (Maximizes performance)
IDES cipher su tes using DES {not triple DES)
I RC4 I cipher su tes using RC4
•Recommended for F PS deployment
Encryption Strength option

Normally, the allow ed encryption strengthis enforced after an SSL sessionis estabilshed,so that a user that car
disallow ed encryption strength wli receive a w eb page describingthe prob le m.The option below w ill prevent a t
cipher from establishing a connection.Changing this opt on w illcause the w eb serv
ice to restart.
[2JDo not allow connect ons from brov.sers that only accept weaker c phers
SSL Handshake Timeout option
By default,the SSL handshake has a timeout of 60 seconds. Use the text box be
low to set ad
ifferent value.
T
imeout: 60 seconds 10-600 seconds
SSL Legacy Renegotiation Support option

When this optionis enabled,renegot ation w ith cl ents and servers,wh
ich dont support the new TLS Renegotiat
(defined in RFC 5746),will be allow ed. When disabled,renegot ation with such cl ents and servers w ill not be allc
opt on w illcause the w eb serv ice to restart.
rt]Enab e support for SSL legacy renegot at on

ActiveSync Client Certificate Configuration
Enforce client cert ficate requirement on ports used for access.Client certificate can be enabled on the external i::
virtualports.
0 Enable client cert f cate on the exte.rnalport

ExternalVirtualPorts: Selected Virtual Ports :
Internal Virtual Ports: Se

lected VirtualPorts:
TechConference
I Remove I
D
* Virtval Pert is cvffently provisicned tc a Virtval System
Note that changing any of the above sett ngsm

ight re.start some serv ce
in the Pu se Policy Secure.
.s
[ Save Changes I

Table 70: SSL Options Configuration Guidelines
Settings Guidelines
Allowed SSL and TLS Specify encryption requirements for clients. By default, the system requires SSL version 3 and
Version TLS. The system honors this setting for all Web server traffic and all types of clients. You can
require users who have older browsers that use SSL version 2 to update their browsers, or you
can change this setting to allow SSL version 2, SSL version 3, and TLS.
Allowed Encryption  Accept only 168-bit and greater—The system gives preference to 256-bit AES over 3DES.
Strength  Accept only 128-bit and greater—The default. The system gives preference to RC4 ciphers. You
can require users to have this level of encryption strength or change this default to an option
compatible with the user base.
 Accept 40-bit and greater—The system gives preference to RC4 ciphers. Older browsers that
predate the change in the U.S. export law in year 2000 that required 40-bit cipher encryption
for international export, can still use 40-bit encryption.
 Custom SSL Cipher Selection—Specify a combination of cipher suites for the incoming connection
from the user’s browser. If you select the AES/3DES option, the system gives preference to
256-bit AES over 3DES.
NOTE: When using 168-bit encryption, some Web browsers may still show 128-bit encryption
(the gold lock on the browser status bar) even though the connection is 168-bit. This is typically
a limitation of the browser’s capability.
NOTE: If you are using the IC6500 FIPS version, you can choose High, Medium, or Low security
cipher suites. AES/3DES High and AES Medium are recommended for FIPS deployment.
Encryption Strength option Normally, the allowed encryption strength is enforced after an SSL session is established, so that
a user connecting with a disallowed encryption strength receives a Web page describing the
problem. Enable this option to prevent a browser with a weak cipher from establishing a
connection.
SSL Handshake Timeout Determines how many seconds elapse before the SSL handshake times out. The default is 60
option seconds.
SSL Legacy Renegotiation SSL and Transport Layer Security (TLS) renegotiations can be subjected to man-in-the-middle
Support option (MITM) attacks that can lead to abuse. A new TLS extension (defined in RFC 5746) ties
renegotiations to the TLS connections they are being performed over to prevent these kinds of
attacks. The SSL Legacy Renegotiation Support option is enabled by default and allows
renegotiation between clients and servers even if they do not support the new TLS extension.
Disable this option to not allow renegotiations between clients and servers that do not support
the new TLS extension. A web server restart is required when you change the value of this option.
ActiveSync Client Enforce a client certificate requirement on ports used for access. A client certificate requirement
Certificate Configuration can be enabled on the external port and the virtual ports.
Related  FIPS Level 1 Feature Guide

Documentation

Configuring Miscellaneous Security Options
You can use the System > Configuration > Security > Miscellaneous page to configure
the following security options:
 Persistent cookie options—Choose whether to preserve or delete persistent cookies

when a session is terminated.
 Lockout options—You can configure lockout options to protect the system from denial
of service (DoS), distributed denial of service (DDoS), and password-guessing attacks.
To configure cookie and lockout options:
1. Select System > Configuration > Security > Miscellaneous to display the configuration
page.
Figure 134: Miscellaneous Security Options Configuration Page
Table 71: Miscellaneous Security Options Configuration Guidelines
Settings Guidelines
Delete all cookies at For convenience, the system sets persistent cookies on the user’s machine to support functions
session termination such as multiple sign-in, last associated realm, and the last sign-in URL. For additional security
or privacy, you can choose not to set them.
Lockout options

Table 71: Miscellaneous Security Options Configuration Guidelines (continued)
Settings Guidelines
Rate Specify the number of failed sign-in attempts to allow per minute.
Attempts Specify the maximum number of failed sign-in attempts to allow before triggering the initial
lockout. The system determines the maximum initial period of time (in minutes) to allow the
failed sign-in attempts to occur by dividing the specified number of attempts by the rate. For
example, 180 attempts divided by a rate of 3 results in a initial period of 60 minutes. If 180 or more
failed sign-in attempts occur within 60 minutes or less, the system locks out the IP address being
used for the failed sign-in attempt.
Lockout period Specify the length of time (in minutes) the system must lock out the IP address.
The following scenario illustrates how lockout settings work. For example, assume the
following settings:
 Rate = 3 failed sign-in attempts per minute
 Attempts = 180 maximum allowed in initial period of 60 minutes (180/3)
 Lockout period = 2 minutes
The following sequence illustrates the effect of these settings:
1. During a period of 3 minutes, 180 failed sign-in attempts occur from the same IP
address. Because the specified value for Attempts occurs in less than the allowed
initial period of 60 minutes (180/3), the system locks out the IP address for 2 minutes
(fourth and fifth minutes).
2. In the sixth minute, the system removes the lock on the IP address and begins
maintaining the rate of 3 failed sign-in attempts/minute. In the sixth and seventh
minutes, the number of failed sign-in attempts is 2 per minute, so the system does
not lock the IP address. However, when the number of failed sign-in attempts
increases to 5 in the eighth minute, which is a total of 9 failed sign-in attempts
within 3 minutes, the system locks out the IP address for 2 minutes again (ninth
and tenth minutes).
3. In the eleventh minute, the system removes the lock on the IP address and begins
maintaining the rate of 3 failed sign-in attempts per minute again. When the rate
remains below an average of 3 per minute for 60 minutes, the system returns to its
initial monitoring state.

Documentation


Using the Serial Port
This topic describes use of the serial port and serial port console. It includes the following
information:
 Connecting to the Serial Port Console on page 589

 Using the Serial Console to Roll Back to a Previous OS Version on page 590
 Using the Serial Console to Reset the System to the Factory Image on page 591
Connecting to the Serial Port Console

In cases where the admin console is unavailable, you can perform network and host
configuration tasks and troubleshooting using the serial port console.
To connect to the serial console:
1. Plug a null modem crossover cable from a console terminal or laptop into the device
serial port. This cable is provided in the product box. Do not use a straight serial cable.
2. Configure a terminal emulation utility, such as HyperTerminal, with the following serial
connection parameters:
 9600 bits per second
 8-bit No Parity (8N1)
 1 Stop Bit
 No flow control
3. Press Enter until the serial console is displayed.
Figure 135 on page 589 shows the serial console menu.
Table 72 on page 590 describes the serial console menu options.
Figure 135: Serial Console Menu

Table 72: Serial Console Menu Options
Options Description
1. Network Settings Enables you to change standard network settings; print a routing table; print or clear an ARP cache;
and Tools run the ping and traceroute commands, remove static routes, and add an ARP entry.
2. Create admin Enables you to create a new super administrator account.

username and
password
3. Display log Enables you to display system configuration, user access logs, or administrator access logs through
the serial console. Note that must enter q to return to serial console options after viewing the logs.
4. System Operations Enables you to reboot, shut down, restart, roll back, or factory reset the system without using the admin
console.
5. Toggle password Enables you to password protect the serial console. When you toggle this option to “on,” only super
protection for the administrators are allowed access.
console
6. Create a Super Enables you to create a recovery session to the admin console, even if you have configured the system
Admin session to block access to all administrators. When you select this option, the system generates a temporary
token that is valid for 3 minutes. Enter the following URL into a browser window:
https://<fully-qualified-domain-name>/dana-na/auth/recover.cgi
Then, enter the temporary token when prompted to sign in to the admin console.
When you select this option, the system blocks any additional administrators from signing in to the
admin console until you sign in to the specified URL and initiate a session using your token. The appliance
blocks additional sign-in attempts so that you can fix any configuration problems that the system may
have encountered without conflicting with another session.
7. System Snapshot Enables you to take a system snapshot without using the admin console. When you select this option,
the system takes the snapshot immediately. You can then send the snapshot file, by way of SCP, to a
remote system. The system prompts you for the destination server port, user ID, password, and the
destination path to the remote directory.
If you choose not to send the snapshot file to a remote system, the system saves the file locally. The
next time you log in to the admin console, the System Snapshot tab contains a link to the snapshot
file.
Using the Serial Console to Roll Back to a Previous OS Version

You can use the admin console to roll back the configuration to a previous state. If the
rollback option is not available in the admin console, you can use the procedure described
in this section to perform the system rollback.
If you have not yet performed an OS service package upgrade, there is no previous state
to roll back to, and the rollback option is not available. If you have performed an OS
service package upgrade, any system and user configuration data created after the
upgrade is lost unless you export the most current configuration files before rolling back
the system and then import them afterwards.

To roll back to the previous OS service package:
1. Connect to the serial console.
2. In a browser window, sign in to the admin console.
3. Select Maintenance > System > Platform.
4. Click Reboot Now and then return to the console utility window. The window displays
a message that the system is restarting.
5. After several moments, you are prompted to use the Tab key to select options. Press
Tab, and when prompted for the configuration to load, type rollback and then press
Enter.
After you click Reboot Now, the rollback status is output to the screen, and when complete,
you are prompted to press Return (Enter) to modify system settings, which returns you
to the initial setup options. When you are finished entering data, simply close the serial
console window.
If you wait more than 5 seconds to enter your choice, the current system configuration
is automatically loaded and you must go back to the admin console and click Reboot
Now to start the process again. If you have already performed a system rollback, the
rollback option is not available again until you upgrade the OS service package again.
Using the Serial Console to Reset the System to the Factory Image
In rare cases, you might need to reset the system to its original factory settings. Before
performing this advanced system recovery option, contact PSGSC
(http://www.juniper.net/support/). If possible, export the most current system and user
configuration data before performing a factory reset.
To perform a factory reset:
1. Connect to the serial console.
2. In a browser window, sign in to the admin console.
3. Select Maintenance > System > Platform.
4. Click Reboot and then go back to the console utility window. The window displays a
message that the system is restarting.
5. After several moments, you are prompted to use the Tab key to select options. Press
Tab , and when prompted for the configuration to load, type factory-reset and then
press Enter.
If you wait more than 5 seconds to enter your choice, the current system configuration
is automatically loaded, and you must go back to the admin console and click Reboot
Now to start the process again.
6. When you are prompted to confirm performing a factory reset, type proceed and then
press Enter.

The system begins the process of resetting the machine to its original settings and
outputs several screens of data. After several minutes, you are prompted to use the
Tab key to select configuration choices.
7. When prompted to press the Tab key, do one of the following:
 Wait for the default selection (current) to start automatically.
 Press Tab, type current, and then press Enter.
You are then prompted to enter the initial configuration settings. For details on how
to proceed, see the Installation Guide provided in the product packaging or on the
Pulse Secure Support site.
After you complete the initialization process, you can upgrade to the latest OS service
package and import saved system and user configuration files to return to the last
good working state of your system.
You might receive errors from the system during the initial setup or on a factory reset.
Before the system starts services, it monitors the network port for a maximum of 120
seconds. The system checks the link status and sends ARP requests to the default
gateway. If there is a problem, after 5 seconds, the system displays a message on the
serial console that starts with NIC:...... If the link recovers within 120 seconds, the startup
process continues. If the link does not recover, the following message is displayed:
Internal NIC: ................[Down code=0x1]
Two codes can appear:
 0x1 means that the interface link status reported by the NIC remains off (for example,
a disconnected cable or a cable is in the wrong port).
 0x2 means that the gateway is unreachable. The system boots but is not reachable
from IP addresses bound to that network port.

Documentation  Using the Admin Console Troubleshooting Tools on page 751


CHAPTER 16
Certificate Security Administration
This chapter describes how to use certificates. It includes the following information:
 Understanding Digital Certificate Security on page 593

 Using Trusted Client CAs on page 608
 Using Trusted Server CAs on page 622
 Understanding ECC Certificates on page 626
 Example: Assigning an ECC P-256 Certificate to an External Virtual Port and Giving
Preference to Suite B Ciphers on page 628
Understanding Digital Certificate Security
The Pulse Policy Secure and Pulse Connect Secure use Public Key Infrastructure (PKI) to
secure the data sent to clients over the Internet. PKI is a security method that uses
public and private keys to encrypt and decrypt information. These keys are enabled and
stored through digital certificates. A digital certificate is an encrypted electronic file
issued by a certificate authority (CA) that establishes credentials for client/server
transactions.
In public key cryptography, a public/private key pair is used to encrypt and decrypt data.
Data encrypted with a public key, which the owner makes available to the public, can be
decrypted with the corresponding private key only, which the owner keeps secret and
protected.
For example, if User1 wants to send User2 an encrypted message, User1 can encrypt it
with User2’s public key and send it. User2 then decrypts the message with the private
key. The reverse process is also useful: encrypting data with a private key and decrypting
it with the corresponding public key. This process is known as creating a digital signature.
For example, if User1 wants to present their identity as the sender of a message, they can
encrypt the message with her private key and send the message to User2. User2 then
decrypts the message with User1’s public key, thus verifying that User1 is indeed the
sender.
The system uses the following types of digital certificates to establish credentials and
secure session transactions:

 Device certificates—A device certificate helps to secure network traffic to and from
the Pulse Secure service using elements such as company name, a copy of your
company’s public key, the digital signature of the CA that issued the certificate, a serial
number, and expiration date. In addition, the Pulse Policy Secure uses a device
certificate for communications with the ScreenOS Enforcer and the Junos Enforcer.
 Trusted client CAs—A trusted client CA is a client-side certificate issued by a CA. You
can use trusted client CAs in the access management framework realm and role
configurations to require certificates or certificates with specific attributes. For example,
you may specify that users must present a valid client-side certificate with the OU
attribute set to “yourcompany.com” to sign into the Users authentication realm.
 Trusted server CAs—A trusted server CA is the certificate of a Web server that you trust.
You can install a trusted server CA to validate the credentials of the websites that
users access through the Pulse Secure service.
 Code-signing certificates—A code-signing certificate (also called an applet certificate)

is a type of server-side certificate that re-signs Java applets intermediated by Pulse
Connect Secure. You may use the self-signed code-signing certificate that comes
pre-loaded on Pulse Connect Secure, or you may install your own code-signing
certificate.
In a basic setup, the only required certificates are a device certificate and a code-signing
certificate. Pulse Connect Secure can use a single code-signing certificate to resign
all Java applets and a single device certificate to intermediate all other PKI-based
interactions. If the basic certificates do not meet your needs, however, you may install
multiple device and applet certificates on Pulse Connect Secure or use trusted CA
certificates to validate users.
NOTE:
 The system can verify certificates that use SHA2 as the message digest.
 DSA certificates are not supported.
Certificate management features are an integral part of the Pulse Connect Secure
management framework—All Pulse Connect Secure products include some certificate
management features. If you are an SA700 Series administrator, however, note that
trusted server CA and code-signing certificate administration features are only available
if you have a Core Clientless Access upgrade license.
Related Using Device Certificates on page 595

Documentation
 Using Trusted Client CAs on page 608

 Using Trusted Server CAs on page 622

Chapter 16: Certificate Security Administration
Using Device Certificates
This topic describes how to use device certificates. It includes the following information:
 Understanding Device Certificates on page 595

 Understanding Self-Signed Certificates on page 595
 Importing a Device Certificate and Private Key on page 596
 Creating a Certificate Signing Request on page 599
 Importing a Signed Certificate Created from a CSR on page 600
 Understanding Intermediate Certificates on page 601
 Importing Intermediate CA Certificates on page 602
 Importing a Renewed Certificate That Uses the Existing Private Key on page 603
 Downloading a Device Certificate on page 604
 Using Device Certificates With Virtual Ports on page 604
Understanding Device Certificates

A device certificate helps to secure network traffic to and from the Pulse Secure service
using elements such as your company name, a copy of your company’s public key, the
digital signature of the Certificate Authority (CA) that issued the certificate, a serial
number, and an expiration date. The system also uses device certificates for secure
communications with the Infranet Enforcer.
When receiving encrypted data from the system, the client’s browser first verifies whether
the device certificate is valid and whether the user trusts the CA that issued the certificate.
If the user has not already indicated that they trust the certificate issuer, the Web browser
prompts the user to accept or install the certificate.
The system supports X.509 device certificates in DER and PEM encode formats (file
extensions include .cer, .crt, .der, and .pem) as well as PKCS #12 (file extensions include
.pfx and .p12). The system also supports the following features:
 Intermediate device CA certificates—Within a certificate hierarchy, one or more

intermediate certificates are branched off a single root certificate.
 Multiple device certificates—When using multiple device certificates, each certificate

handles validation for a separate hostname or fully qualified domain name (FQDN)
and can be issued by a different CA.
NOTE: Beginning with Pulse Connect Secure Release 7.2, you can assign
device certificates to the Pulse Connect Secure VLAN interfaces.
Understanding Self-Signed Certificates

When you initialize the system with the serial console, the system creates a self-signed
certificate that enables you to immediately begin setting up the system. Users are

prompted with a security alert each time they sign in because the certificate is not issued
by a trusted CA. Figure 136 on page 596 shows the security alert.
Figure 136: Security Alert When the Device Certificate Is Not Issued by a
Trusted CA
Before promoting the system to production use, we recommend you replace the
self-signed certificate with a certificate issued by a trusted CA.
NOTE: In Pulse Policy Secure deployments with ScreenOS Enforcers, you

must use a CA-signed device certificate. If you use a self-signed certificate,
the ScreenOS Enforcer does not allow a connection. Import a CA-signed
device certificate into the Pulse Policy Secure, and then import the
certificate of the CA that signed the device certificate into the ScreenOS
Enforcer.
Importing a Device Certificate and Private Key

The system uses certificates to verify itself to other network devices. A digital certificate
is an electronic means of verifying your identity through a trusted third party, known as
a Certificate Authority (CA). Your company might use its own enterprise CA server, or it
might use a reputable third-party CA.

To import an enterprise root server certificate and private key:
1. Select System > Configuration > Certificates > Device Certificates.
Figure 137: Device Certificates Management Page – Pulse Policy Secure
Figure 138: Device Certificates Management Page – Pulse Connect Secure
2. Click Import Certificate & Key to display the configuration page.

Figure 139: Import Certificate and Key Page
3. Use one of the following options to complete the import procedure:
 If certificate file includes private key—When the certificate and key are contained in
one file.
 If certificate and private key are separate files—When the certificate and key are in
separate files.
 Import via System Configuration file—When the certificate and key are contained in
a system configuration file. With this option, the system imports all of the certificates
specified (including private keys and pending CSRs, but not the corresponding port
mappings).
In the appropriate form, browse to the certificate and key files. If the file is encrypted,
enter the password key.
4. Click Import.
NOTE: The Import Certificate and Key button is disabled on FIPS hardware
platforms because importing private keys is not allowed. On a FIPS hardware
platform, you must create a CSR and then import a signed certificate from
the CA.

Creating a Certificate Signing Request

If your company does not own a digital certificate for its Web servers, you can create a
certificate signing request (CSR) and then send the request to a CA for processing. When
you create a CSR, a private key is created locally that corresponds to the CSR. If you
delete the CSR at any point, this file is also deleted, prohibiting you from installing a
signed certificate generated from the CSR.
To create a certificate signing request:
2. Click New CSR to display the configuration page.
3. Complete the required information and click Create CSR.
4. Follow the onscreen instructions, which explain what information to send to the CA
and how to send it.
When you submit a CSR to a CA authority, you might be asked to specify either the
type of Web server on which the certificate was created or the type of Web server the
certificate is for. Select apache (if more than one option with apache is available,
select any). If you are prompted for the certificate format to download, select the
standard format.
Do not send more than one CSR to a CA at one time. Doing so can result in duplicate
charges.

Figure 140: New Certificate Signing Request
NOTE: To view details of any pending requests that you previously submitted,
click the Certificate Signing Request Details link.
Importing a Signed Certificate Created from a CSR

When you receive the signed certificate from the CA, import it.
To import a signed device certificate created from a CSR:
2. Under Certificate Signing Requests, click the Pending CSR link that corresponds to
the signed certificate.
Figure 141 on page 601 shows the Pending Certificate Signing Request page for Pulse
Policy Secure. The configuration page for Pulse Connect Secure is similar.
3. Under Import signed certificate, browse and select the certificate file you received
from the CA, and then click Import.

Figure 141: Pending Certificate Signing Request
Understanding Intermediate Certificates

Within a certificate hierarchy, one or more intermediate certificates are branched off a
single root certificate. The root certificate is issued by a root CA and is self-signed. Each
intermediate certificate is issued by the certificate preceding it in the chain.
To use chained certificates in your deployment, you must ensure that the server (Pulse
Policy Secure or Pulse Connect Secure) and client (Web browser) together contain the
entire certificate chain. For example, you can secure traffic using a chain that stems
from a VeriSign root certificate. If your users’ browsers come preloaded with VeriSign
root certificates, you need to install only the lower-level certificates in the chain. When
your users sign in, the system presents any required certificates within the chain to the
browser to secure the transaction. The system creates the proper links in the chain using
the root certificate’s IssuerDN. If the system and browser together do not contain the
entire chain, the user’s browser does not recognize or trust the device certificate because
it is issued by another certificate instead of by a trusted CA.
You can upload one or more intermediate CAs in a PEM file. The entire chain must be
sent to the client in descending order, starting with the root certificate.

Within a certificate hierarchy, one or more intermediate certificates are branched off a
single root certificate. The root certificate is issued by a root CA and is self-signed. Each
intermediate certificate is issued by the certificate preceding it in the chain.
To use chained certificates in your deployment, you must install the appropriate client-side
certificates in each user’s Web browser and then upload the corresponding CA certificates
to Pulse Secure service Intermediate CA store. Use one of the following methods to upload
the certificate chain:
 Import the entire certificate chain in one file. The file must contain the root certificate
and any subcertificates whose parents are in the file or already imported. You can
include certificates in any order in the import file.
 Import the certificates one at a time in descending order. You must install the root
certificate first, and then install the remaining chained certificates in descending order.
If you follow one of these methods, the system automatically chains the certificates
together in the correct order and displays them hierarchically in the admin console.
NOTE: If you install multiple certificates in a user’s Web browser, the browser
prompts the user to choose which certificate to use when signing in.
Importing Intermediate CA Certificates

To import an intermediate CA certificate:
2. Click the Intermediate Device CAs link to display the management page.
Figure 142 on page 602 shows the management page for Pulse Policy Secure. The
management page for Pulse Connect Secure is similar.
3. Click Import CA certificate.
4. Browse to the certificate file, select it, and click Import Certificate to complete the
import operation.
Figure 142: Intermediate CAs Management Page

Importing a Renewed Certificate That Uses the Existing Private Key

You can renew a device certificate in two ways:
 Submit a new CSR to a CA—This process is more secure because the CA generates a
new certificate and private key and retires the older private key. To use this renewal
method, you must first create a CSR through the admin console.
 Request renewal based on the CSR previously submitted to the CA—This process is
less secure, because the CA generates a certificate that uses the existing private key.
When you order a renewed certificate, you must either resubmit your original CSR or
ensure that the CA has a record of the CSR that you submitted for your current certificate.
To import a renewed device certificate that uses the existing private key:
1. Follow your CA’s instructions for renewing a certificate that you previously purchased
through them. Be sure to specify the same information you used in the original CSR.
Your CA uses this information to create a new certificate that corresponds to the
existing key.
NOTE: Even though you specify the same information used in the original
CSR, your root CA might have different serial numbers and keys from the
original. You might need to support both new client and old client
certificates during the transition period, which also requires that you
maintain two root CA certificates (your existing certificate and the renewed
certificate), at least temporarily
3. Click the link that corresponds to the certificate you want to renew.
4. Click Renew Certificate to display the page.
5. In the Renew the Certificate form, browse to the renewed certificate file, enter the
password for the certificate key, and click Import.

Figure 143: Renew Certificate Page
Downloading a Device Certificate

You download the device certificate to your local host so that you can import it into other
network devices as needed.
To download a device certificate:
2. Click the link of the device certificate you want to download to display the configuration
page.
3. Click the Download link.
4. Save the file to the desired location.
Using Device Certificates With Virtual Ports

Virtual ports can be used to create multiple fully qualified domain names for user sign-in.
When a user tries to sign in using the IP address defined in a virtual port, the system uses
the certificate associated with the virtual port to initiate the SSL transaction and for
NetScreen Address Change Notification (NACN) communications with the Infranet
Enforcer.
You must associate the signed certificate with the port that is connected to the Infranet
Enforcer. You can use the same port and certificate for OAC or Pulse. Or, you can import
other signed certificates and associate them with ports connected to OAC.
You can implement digital certificate security with virtual ports in either of the following
ways:
 Associate all hostnames with a single certificate—With this method, you use a single
wildcard certificate to validate the identity of all system hostnames, regardless of
which hostname is used to sign into. A wildcard certificate includes a variable element

in the domain name, making it possible for users who sign in from multiple hosts to
map to the “same” domain. For example, if you create a wildcard certificate for
*.yourcompany.com, the system uses the same certificate to validate its identity to
users who sign in to employees.yourcompany.com as it does to users who sign into
partners.yourcompany.com.
 Associate each hostname with its own certificate—With this method, you associate
different hostnames with different certificates. Create a virtual port for each hostname.
A virtual port activates an IP alias on a physical port. For example, you can create two
virtual ports on a single appliance, mapping the first virtual port to the IP address
10.10.10.1 (sales.yourcompany.com) and the second virtual port to the IP address
10.10.10.2 (partners.yourcompany.com). Then you can associate each of these virtual
ports with its own certificate, ensuring that users authenticate through different
certificates.
To associate certificates with virtual ports:
1. Create the virtual ports.
2. Import the device certificates.

3. Associate the device certificates with the virtual ports:
a. Select System > Configuration > Certificates > Device Certificates.
b. Click the link of the device certificate you want to configure to display the
configuration page.
c. Use the controls in the “Present certificate on these ports” section to associate
ports with the certificate.
Figure 144: Certificate Details Page

NOTE: You can assign only one device certificate to the Management Port.
If you assign a certificate other than the default device certificate to the
Management Port, the default device certificate is automatically deselected
as the default. If you do not select a device certificate for the Management
Port, the system uses the default device certificate that is presented on the
Internal port. You cannot assign certificates to Management Port VIPs.

Related Understanding Digital Certificate Security on page 593

Documentation

Using Trusted Client CAs
This topic describes how to use trusted client Certificate Authorities (CAs). It includes
 Understanding Trusted Client CAs on page 608

 Trusted Client CA Implementation Notes on page 609
 Understanding CRLs on page 609
 Understanding OCSP on page 611
 Importing a Trusted Client CA Certificate on page 611
 Renewing a Certificate on page 613
 Configuring Auto-Importing of Client Certificates on page 613
 Configuring Options for Trusted Client CA Certificates on page 615
 Configuring a Proxy Server for CRL Downloads and OCSP Status Checks on page 621
Understanding Trusted Client CAs

A trusted client CA is a CA that you deem trusted by adding it the trusted client CA store.
The system trusts any certificate issued by that CA. To use client CA certificates, you
must install and enable the proper certificates. Additionally, you must install the
corresponding client-side certificates in your users’ Web browsers, or you must use the
MMC snap-in in your users’ computer accounts (machine certificate). When validating
a client-side CA certificate, the system verifies that the certificate is not expired or corrupt
and that the certificate is signed by a CA that the system has been configured to recognize.
If the CA certificate is chained, the system also follows the chain of issuers until it reaches
the root CA, validating each issuer in turn. The system supports X.509 CA certificates in
DER and PEM encode formats.
When you install a client-side certificate, you must determine whether to use the
certificate to identify individual users or individual machines. To use the certificate to
identify individual users, you must install the certificate in each user’s individual certificate
store. Then you must enable authentication using a certificate server, or you must enable
authorization using realm, role, and/or resource policy settings. To use the certificate to
identify individual machines, you must install the certificate in each computer’s certificate
store. Then you must configure a Host Checker policy that checks for the machine
certificate and authorizes access to realms, roles, or resource policies based on the
certificate's validity.

The system supports using the following additional features with CA certificates:
 Certificate servers—A certificate server is a type of local authentication server that

allows you to authenticate users based solely on their certificate attributes rather than
authenticating them against a standard authentication server (such as LDAP or
RADIUS), and it requires specific certificates or certificate attributes.
 Certificate hierarchies—Within a certificate hierarchy, one or more subordinate

certificates (called intermediate certificates) are branched off a root certificate to
create a certificate chain. Each intermediate certificate (also called a chained
certificate) handles requests for a part of the root CA domain. For example, you can
create a root certificate that handles all requests to the yourcompany.com domain
and then branch off intermediate certificates that handle requests to
partners.yourcompany.com and employees.yourcompany.com. When you install a
chained certificate, the system confirms that the chain is valid and allows users to
authenticate using the leaf certificate (that is, the lowest certificate in the chain).
 Certificate revocation lists—Certificate revocation is a mechanism by which a CA

invalidates a certificate before its expiration date. The CA publishes a certificate
revocation list (CRL) which is a list of revoked certificates. Within CRLs, each entry
contains the serial number of the revoked certificate, the date that the certificate was
revoked, and the reason the certificate was revoked. The CA can invalidate a certificate
for various reasons such as when the employee to whom the certificate is issued leaves
the company, the certificate’s private key is compromised, or the client-side certificate
is lost or stolen. When the CA revokes a certificate, the system can appropriately deny
access to users who present a revoked certificate.
Trusted Client CA Implementation Notes

Uploading a trusted client CA certificate does not enable client-side SSL authentication
or authorization. To do so, you must use a certificate server, or enable certificate
restrictions at the realm, role, or resource policy level, or create a Host Checker policy
that verifies a machine certificate.
With client-side certificates, we strongly recommend that you advise users to close their
Web browsers after signing out. If they do not, other users might be able to use their open
browser sessions to access certificate-protected resources without reauthentication.
After loading a client-side certificate, Internet Explorer caches the certificate’s credentials
and private key. The browser keeps this information cached until the user closes the
browser (or, in some cases, until the user reboots the workstation). For details, see
http://support.microsoft.com/?kbid=290345.) To remind users to close their browsers,
you can modify the sign out message on the Sign-in Pages tab.
Understanding CRLs
A certificate revocation list (CRL) is a mechanism for canceling a client-side certificate.
As the name implies, a CRL is a list of revoked certificates published by a CA or a delegated
CRL issuer. The system supports base CRLs, which include all of the company’s revoked
certificates in a single, unified list.

The system determines the correct CRL to use by checking the client’s certificate. (When
it issues a certificate, the CA includes CRL information for the certificate in the certificate
itself.) To ensure that it receives the most up-to-date CRL information, the system
periodically contacts a CRL distribution point to get an updated list of CRLs. A CRL
distribution point (CDP) is a location on an LDAP directory server or Web server where a
CA publishes CRLs. The system downloads CRL information from the CDP at the interval
specified in the CRL, at the interval that you specify during CRL configuration, and when
you manually download the CRL. The system also supports CRL partitioning. CRL
partitioning enables you to verify portions of very large CRLs without spending the time
and bandwidth necessary to access and validate a very large CRL or collection of large
CRLs. CRL partitioning is only enabled when you employ the Specify the CDP(s) in the
client certificates method (described below). In this case, the system validates the user
by verifying only the CRL specified in the client certificate.
Although CAs include CRL information in client-side certificates, they do not always
include CDP information as well. A CA can use any of the following methods to notify
the system of a certificate’s CDP location:
 Specify the CDP(s) in the CA certificate—When the CA issues a CA certificate, it might

include an attribute specifying the location of the CDPs that the system should contact.
If more than one CDP is specified, the system chooses the first one listed in the
certificate and then fails over to subsequent CDPs, if necessary.
 Specify the CDP(s) in the client certificates—When the CA issues a client-side certificate,
it might include an attribute specifying the location of the CDPs that the system must
contact. If more than one CDP is specified, it chooses the first one listed in the certificate
and then fails over to subsequent CDPs, if necessary. When the system employs CRL
partitioning and the client certificate specifies only one CRL, it performs verification
using only that CRL.
NOTE: If you choose this method, the user receives an error on the first
sign-in attempt because no CRL information is available. Once the system
recognizes the client’s certificate and extracts the CRL location, it can start
downloading the CRL and subsequently validate the user’s certificate. In
order to successfully sign in, the user must try to reconnect after a few
seconds.
 Require the administrator to manually enter the CDP location—If the CA does not
include the CDP location in the client or CA certificates, you must manually specify
how to download the entire CRL object. You can specify a primary and backup CDP.
(Manually entering the CDP location provides the greatest flexibility because you do
not need to reissue certificates if you change the CDP location.)
The system compares the user’s certificate against the appropriate CRL during
authentication. If it determines that the user’s certificate is valid, the system caches the
certificate attributes and applies them, if necessary, during role and resource policy
checks. If it determines that the user’s certificate is invalid, if it cannot contact the
appropriate CRL, or if the CRL is expired, it denies the user access.

NOTE:
 The system supports only CRLs that are in a PEM or DER format and that
are signed by the CA for which the revocations apply.
 The system only saves the first CRL in a PEM file.
 The system does not support the Issuing Distribution Point (IDP) CRL
extension.
Understanding OCSP
The Online Certification Status Protocol (OCSP) is a service that enables you to verify
client certificates. When OCSP is enabled, the system becomes a client of an OCSP
responder and forwards validation requests for users based on client certificates. The
OCSP responder maintains a store of CA-published certificate revocation lists (CRLs)
and maintains an up-to-date list of valid and invalid client certificates. After the OCSP
responder receives a validation request, it validates the status of the certificate using its
own authentication database, or it calls upon the OCSP responder that originally issued
the certificate to validate the request. After formulating a response, the OCSP responder
returns the signed response, and the original certificate is either approved or rejected.
Importing a Trusted Client CA Certificate

If you require users to provide a client-side certificate to sign in, you must upload the
corresponding CA certificate. You can upload CA certificates manually, or you can
configure the system to upload CA certificates automatically. The system uses the
uploaded certificate to verify that the browser-submitted certificate is valid. In addition,
you can specify whether or not to automatically import CA certificates for validation, and
you can specify a CRL or OCSP retrieval method to use to automatically import CA
certificates.
To import a trusted client CA certificate:
1. Select System > Configuration > Certificates > Trusted Client CAs to display the
configuration page.

Figure 145: Trusted Client CA Management Page– Pulse Policy Secure
Figure 146: Trusted Client CA Management Page – Pulse Connect Secure
2. Click Import CA Certificate to display the configuration page.
Figure 147: Import Trusted Client CA Page
import operation.

Renewing a Certificate
To renew a certificate:
1. Select System > Configuration > Certificates > Trusted Client CAs.
2. Click the link for the certificate you want to renew.
Figure 148 on page 613 shows the certificate page for Pulse Policy Secure. The
certificate page for Pulse Connect Secure is similar.
3. Click Renew Certificate to display the import certificate page.
import operation.
Figure 148: Trusted Client CA Details Page
Configuring Auto-Importing of Client Certificates

To enable auto-importing:
2. Click the Auto-Import Options button to display the options.

3. Complete the configuration described in Table 73 on page 614.
Figure 149: Auto-Import Options Page
Table 73: Auto-Import Options Settings
Settings Guidelines
Auto-import trusted CAs Select this option to enable auto-import and display its configuration settings.
Client Certificate Status Select a method to validate the trusted client certificate:
Checking
 None—Do not validate.
 Use OCSP—Use the OCSP method, validating the client certificate in real-time, as needed. After
you select this option, you can specify options for OCSP.
 Use CRLs—Use CRLs to validate the client certificate. After you select this option, you can specify
options for OCSP.
 Use OCSP with CRL fallback—Use the OCSP validation method when possible, but attempt to
validate client certificates using CRLs if the OCSP method fails (for example, if the link to the
OCSP responder fails). After you select this option, you can specify options for OCSP.
 Inherit from root CA—Use the method configured for the device certificate.
CDP(s)/OCSP Select the location of the responder value:

responder
 None—Do not use the responder.
 From client certificate—Use the responder value configured in the client certificate.
 From trusted CA certificate—Use the responder value configured in the trusted CA certificate that
has been uploaded to the system.

Table 73: Auto-Import Options Settings (continued)
Settings Guidelines
Verify imported CA Select this option to verify that this trusted client CA is valid. Enabling this will check the CRL of this
certificates certificate's issuer, and repeat up the chain until reaching the root trusted client CA.
Configuring Options for Trusted Client CA Certificates

To configure options for the trusted client CA certificate:
2. Click the certificate you want to configure.

Figure 150: Trusted Client CA Details Page

Table 74: Trusted Client CA Settings
Settings Guidelines
Certificate Use the expander buttons to display the following details:
 Issued To—Name and attributes of the entity to whom the certificate is issued.
 Issued By—Name and attributes of the entity that issued the certificate. Note that the value of
this field must match either the Issued To field (for root certificates) or the Issued To field of the
next highest certificate in the chain (for intermediate certificates).
 Valid Dates—Time range for which the certificate is valid.
 Details—Various certificate details, including its version, serial number, signature algorithm, CRL
distribution points, public key algorithm type, and public key.
Client Certificate Status Select a method to validate the trusted client certificate:
Checking
 None—Do not validate.
 Use OCSP—Use the OCSP method, validating the client certificate in real-time, as needed. After
you have selected this option and saved the configuration, you can specify options for OCSP.
 Use CRLs—Use CRLs to validate the client certificate. After you have selected this option and
saved the configuration, you can specify options for CRL.
 Use OCSP with CRL fallback—Use the OCSP validation method when possible, but attempt to
validate client certificates using CRLs if the OCSP method fails (for example, if the link to the
OCSP responder fails). After you have selected this option and saved the configuration, can specify
options for OCSP and CRL.
Verify Trusted Client CA Select this option to verify that this trusted client CA is valid. Enabling this will check the CRL of this
certificate's issuer, and repeat up the chain until reaching the root trusted client CA.
Trusted for Client Clear this check box to exclude the CA from being trusted for client certificate authentication. You
Authentication might want to do this if this CA was added for another trusting purpose, such as SAML signature
verification or machine certificate validation.
Participate in Client This option is available only on Pulse Connect Secure.

Certificate Negotiation
Select this option to include the CA participation in client certificate selection for authentication.
NOTE: In client certificate authentication or restriction, the device sends a list of all trusted client
CAs configured in the trusted client CA store with this flag enabled to the user’s browser for user
certificate selection. The browser prompts the client certificates whose issuer CA and/or root CA is
in that list. This option allows you to control which client certificate(s) are prompted for selection.
Clearing this option for all certificates in a CA chain results in those certificates not being prompted.
5. If you have enabled CRL Checking, click CRL Checking Options.

Figure 151: CRL Checking Options
6. If you have enabled OCSP options:

a. Click OCSP Options.
Figure 152: OCSP Options Page
b. Complete the configuration described in Table 75 on page 619.
Table 75: OCSP Options Settings
Settings Guidelines
Use Select the type of OCSP responder to validate trusted client CAs:
 None—The system does not use OCSP to verify the status of certificates issued by this CA.
 Responder(s) specified in the CA certificate—The system uses OCSP responders specified in
the imported client CA to perform verification. When you select this option, the system
displays a list of OCSP responders specified in the imported CA (if any) and the last time
they were used.
 Responder(s) specified in the client certificates—The system uses responders specified during
client authentication to perform verification. When you select this option, the system displays
a list of known OCSP responders (if any) and the last time they were used.
 Manually configured responders—The system uses primary and secondary OCSP responders
at the addresses you specify.
Device Certificate to sign the Select the appropriate device certificate or leave the default (unsigned).
request

Table 75: OCSP Options Settings (continued)
Settings Guidelines
Signature Hash Algorithm Select SHA-1 or SHA-2.
Use Nonce A nonce is random data the system includes in an OCSP request and the OCSP responder
returns in the OCSP response. The system compares the nonce in the request and response to
ensure that the response is generated by the OCSP responder. If the two do not match, the
system disregards the response and sends a new request. Nonces are a common way of
preventing replay attacks.
d. After you have added an OCSP responder to the list, you can click its link to display
the page.
Figure 153: Responder Signer Certificate Page
e. Complete the configuration described in Table 76 on page 620.
Table 76: Responder Signer Certificate Settings
Settings Guidelines
Responder Signer Certificate Browse to the network path or local directory location of a Responder Signer Certificate.
This is the certificate the OCSP responder uses to sign the response. You must specify
the Responder Signer Certificate if the signer certificate is not included in the response.

Table 76: Responder Signer Certificate Settings (continued)
Settings Guidelines
Trust Responder Certificate Select this option to allow an OCSP responder certificate that matches the responder
signer certificate.
Revocation Checking Select this option to ensure that the certificate has not recently been revoked. This option
has implications only if you specified the Use OCSP with CRL fallback option.
Allow clock discrepancy Use this option to account for possible mismatches in timestamps between the system
clock and the OCSP responder clock. If the mismatch is significant, the system disregards
the response from the OCSP responder as out of date or expired.
f. Save the configuration.
Configuring a Proxy Server for CRL Downloads and OCSP Status Checks
You can configure the system to send CRL download requests and OCSP status checks
to the proxy server and collect the response. You might want to do this if you deploy
proxy server to control access to the Internet.
The following types of CRL downloads can use the proxy server:
 CRL distribution points (CDPs) specified in the trusted client CAs
 CDPs specified in client certificates
 Manually configured CDPs
Similarly, the system can send OCSP requests to the OCSP responder through the proxy
server. The OCSP responses are also received through the proxy server. This feature is
useful when you deploy a large number of Pulse access systems and the OCSP responders
are located outside the network.
To configure a proxy server:
2. Click Proxy Settings to display the page.

Figure 154: Proxy Settings Page
Table 77: Proxy Settings
Settings Guidelines
Use Proxy Server for Select to enable the CRL operations to use a proxy server.
HTTP-based CRL
download NOTE: You can configure a proxy server for web-based URLs, not LDAP URLs.
Use Proxy Server for Select to enable the OCSP operations to use a proxy server.
HTTP-based OCSP
status checking
Host Address Specify either an IP address or a fully qualified domain name.
Port Enter the proxy server port number if it is different from the default value of 80.
Username/password If your proxy server required authentication, enter a username and password to log in to the proxy
server.
Related  Understanding Digital Certificate Security on page 593

Documentation
Using Trusted Server CAs
This topic describes trusted server certificate authorities (CAs). It includes the following
information:
 Understanding Trusted Server CAs on page 623

 Uploading Trusted Server CA Certificates on page 623
 Restoring the Prepopulated Group of Trusted Server CA Certificates on page 625

 Renewing a Trusted Server CA Certificate on page 625

 Deleting a Trusted Server CA Certificate on page 626
Understanding Trusted Server CAs

All of the trusted root CAs for the Web certificates installed in Internet Explorer 7.0 and
Windows XP service pack 2 are preinstalled. You might need to install a trusted server
CA for additional Web servers in the following situations:
 If you are using third-party integrity measurement verifiers (IMVs) that are installed on
a remote server, you must upload the trusted root certificate of the CA that signed the
remote server’s server certificate.
 If you are using virus signature version monitoring with your own staging site for storing
the current virus signatures list, you must upload the trusted root certificate of the CA
that signed the staging server certificate.
You can install the trusted root CA certificate on the endpoint in any of the following
ways:
 Use a CA certificate that is chained to a root certificate that is already installed on the
endpoint, such as VeriSign.
 Upload the CA certificate and any intermediate CA certificates to the Pulse Secure
system. During client installation, the system automatically installs the trusted root
device CA certificates on the endpoint. When prompted during installation, the user
must allow the installation of the CA certificate(s).
 Prompt users to import the CA certificates on the endpoint using Internet Explorer or
other Microsoft Windows tools. In other words, you can use common methods
organizations use to distribute root certificates.
NOTE: You cannot use CRL revocation checks for trusted server CA
certificates.
Uploading Trusted Server CA Certificates

You can use the Trusted Server CAs page to upload the trusted root certificate of the CA
that signed the Pulse Secure service device certificate. If you upload a certificate chain,
you must install the certificates one at a time in descending order starting with the root
certificate (DER or PEM files), or you must upload a single file that contains the entire
certificate chain (PEM files only). The system supports X.509 CA certificates in PEM
(Base 64) and DER (binary) encode formats.
To upload CA certificates:
1. Select System > Configuration > Certificates > Trusted Server CAs to display the page.

Figure 155: Trusted Server CA Management Page – Pulse Policy Secure
Figure 156: Trusted Server CA Management Page – Pulse Connect Secure
2. Click Import Trusted Server CA to display the page.
Figure 157: Import Trusted Server CA Page
import operation.

Restoring the Prepopulated Group of Trusted Server CA Certificates

The System > Configuration > Certificates > Trusted Server CAs page is prepopulated
with all of the trusted root CAs for the Web certificates installed in Internet Explorer 7.0
and Windows XP service pack 2. You can use the delete functionality on this page to
delete CAs and the reset functionality to restore the list to the set that was installed
during the upgrade. The reset operation clears all manually imported certificates.
To restore the prepopulated group of trusted CA certificates:
1. Select System > Configuration > Certificates > Trusted Server CAs.
2. Click Reset Trusted Server CAs.
3. Confirm that you want to restore the set of trusted server CAs that was installed when
you upgraded.
The Pulse Connect Secure restores the group of prepopulated trusted server CAs
that were installed upon upgrade. This operation clears all manually imported
certificates.
Renewing a Trusted Server CA Certificate

If a trusted CA renews its certificate, you must upload the renewed CA certificate.
To import a renewed CA certificate:
2. Click the link that corresponds to the certificate that you want to renew to display the
page.
3. Click Renew Certificate.
import operation.

Figure 158: Trusted Server CA Details Page
Deleting a Trusted Server CA Certificate

You can delete any trusted server CA certificate, including preinstalled certificates.
To delete a trusted server CA certificate:
2. Select the check box for the certificate you want to delete.
3. Click Delete, and then confirm that you want to delete the certificate.
Related Understanding Digital Certificate Security on page 593

Documentation

Understanding ECC Certificates
Public-key cryptography is a cryptographic system that requires a secret key and a public
key that are mathematically linked with each other. One key encrypts the plain text while
the other decrypts the cipher text. RSA is the most widely used public-key algorithm.
Elliptic Curve Cryptography (ECC) were introduced as an alternative to RSA in public key
cryptography. One advantage of ECC over RSA is key size versus strength. For example,
a security strength of 80 bits can be achieved through an ECC key size of 160 bits, whereas
RSA requires a key size of 1024. With a 112-bit strength, the ECC key size is 224 bits and
the RSA key size is 2048 bits.
The most popular signature scheme that uses elliptic curves is called the Elliptic Curve
Digital Signature Algorithm (ECDSA). The most popular key agreement scheme is called
Elliptic Curve Diffie-Hellman (ECDH). An ECDH exchange is a variant of the Diffie-Hellman
(DH) protocol and is an integral part of the Suite B cryptography standards proposed by

the National Security Agency (NSA) for protecting both classified and unclassified
information.
About Suite B
The Advanced Encryption Standard (AES) is a specification for the encryption of electronic
data established by the U.S. National Institute of Standards and Technology (NIST) in
2001. Because a single encryption algorithm cannot satisfy all of the needs of the national
security community, NSA created a larger set of cryptographic algorithms, called Suite
B, which can be used along with AES in systems used by national security users. In addition
to AES, Suite B includes cryptographic algorithms for hashing, digital signatures, and key
exchanges.
Per RFC 6460, to be Suite B TLS 1.2 compliant the server and client should negotiate
with the following ciphers:
 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
RFC 6460 also lists a transitional Suite B profile for TLS 1.0 and TLS 1.1. Clients and servers
that do not yet support Suite B TLS 1.2 should negotiate with the following ciphers:
 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
There is no special configuration to ensure that Pulse Policy Secure and Pulse Connect
Secure negotiate Suite B ciphers. However, the following general steps should be
performed to enable Suite B compliance:
 An ECC certificate signed by an ECC Root CA is associated with a network port.
 A P-256 CSR is signed by either a P-256 or P-384 Root CA.
 A P-384 CSR is be signed by a P-384 Root CA.
 Manually enable only AES128 and/or AES256 custom ciphers.
NOTE: Pulse Policy Secure and Pulse Connect Secure cannot be

configured to allow only Suite B ciphers.
Using ECC Certificates with Pulse Connect Secure and Pulse Policy Secure
ECC certificates are currently supported only on the MAG and virtual appliance platforms.
As with RSA certificates, ECC certificates are associated with a network port. You can
create multiple virtual ports on the server with each port supporting a specific certificate.
For example, external virtual port 1 can use a 1024-bit RSA while external virtual port 2
uses ECC P-256 and external virtual port 3 uses ECC P-384. Only clients that support
ECC cipher suites can connect to the web server on that network port.

When an Elliptic Curve Cryptography (ECC) certificate is associated with a network port,
only clients that support ECC cipher suites can connect to the Web server on that network
port.
Except for the key and certificate generation process, the use of ECC certificates is
basically the same as using RSA certificates.
Related Example: Assigning an ECC P-256 Certificate to an External Virtual Port and Giving
Documentation Preference to Suite B Ciphers on page 628
Example: Assigning an ECC P-256 Certificate to an External Virtual Port and Giving
Preference to Suite B Ciphers
This example outlines the general steps for creating an external port and assigning an
ECC P-256 certificate. The steps are generally the same as assigning an RSA certificate
to a port.

 (optional) Configuring the Virtual Ports on page 629
 Creating the Certificate Signing Request for a New Certificate on page 630
 Importing the Signed Certificate Created from a CSR on page 632
 Presenting the Certificate on the Network on page 632
 Setting the Security Options on page 633
Configuring the External Port

The external port handles all requests from users signed into the server from outside the
customer LAN, for example, from the Internet.
To configure the external port:
1. In the admin GUI, choose System > Network > External Port > Settings.
2. Modify the settings as needed. In this example, only IPv4 is enabled. See

Figure 159: Configuring the External Port for IPv4
(optional) Configuring the Virtual Ports

A virtual port is an IP alias bound to a physical port. It shares all of the network settings,
except IP address, with the associated physical port. You can use virtual ports for different
purposes, depending on the physical port or the VLAN on which you base the virtual port.
In this example, we are configuring the virtual port on the external port to support external
sign-ins. This is an optional step that shows one way of allowing multiple certificates on
the device.
To configure the external virtual port:
1. In the admin GUI, choose System > Network > External Port > Virtual Ports.
2. Click New Port.
In this example, the port is named p_ecdsa256 and accepts only IPv4 addresses. See

Figure 160: Creating the Virtual Port on the External Port
Creating the Certificate Signing Request for a New Certificate

A certificate signing request (CSR) is a message sent from an applicant to a certificate
authority (CA) to apply for a digital identity certificate. You create a CSR through the
admin console. When you create a CSR, a private key is created locally that corresponds
to the CSR. If you delete the CSR at any point, the private key is deleted too, prohibiting
you from installing a signed certificate generated from the CSR.
In this example, a CSR for an ECC P-256 certificate is requested.
To create a CSR for a new certificate:
1. In the admin console, choose System > Configuration > Certificates > Device Certificates.
2. Click New CSR.
3. Enter the required requestor information. In this example, the common name is
ecc-p256.juniper.net.
4. Click ECC and select P-256 from the ECC Curve menu. See Figure 161 on page 631.

Figure 161: Creating an ECC P-256 Certificate Signing Request
5. Click Create CSR. A CSR is successfully created, as shown in Figure 162 on page 631.
Figure 162: CSR Successfully Created
6. The CSR is encoded and can be copied or saved to a file. The ECC certificate should
be signed by an ECC CA for Suite B compliance. Follow your CA’s process for sending
a CSR.
7. Click the Back to Device Certificates link. Until you import the signed certificate from
your CA, your CSR is listed as Pending. See Figure 163 on page 632.

Figure 163: Pending CSR
Importing the Signed Certificate Created from a CSR

Once your CA has sent your signed certificate, you must import that into the pending
CSR.
To import a signed device certificate created from a CSR:
1. In the admin console, choose System > Configuration > Certificates > Device Certificates.
2. Under Certificate Signing Requests, click the Pending CSR link that corresponds to
the signed certificate. See Figure 163 on page 632.
3. Under Import signed certificate, browse to the certificate file you received from the
CA and then click Import. See Figure 162 on page 631.
Presenting the Certificate on the Network

You can present a certificate many ways, depending on your configuration. For example,
you can present the certificate to one or more virtual ports or on an internal or external
port. In this example, the ECC P-256 certificate is presented on the external virtual port
p1.
To present a certificate on an external virtual port:
1. In the admin console, select System > Configuration > Certificates > Device Certificates.
2. Click the certificate name you want to assign to a port. In this example, click
ecc-p256.juniper.net.
3. Under External Ports, select p_ecdsa256 and click Add. See Figure 164 on page 633.

Figure 164: Associating the ECC P-256 With The External Virtual Port
p_ecdsa256
Setting the Security Options

To specify the cipher suites for the incoming connection to the web server , use the SSL
Options page and select the Custom SSL Cipher Selection option. This step is required in
our example to give Suite B cipher suites preference. If you do not want to give Suite B
cipher suites preference, you do not have to perform this step.
To set the security options:
1. In the admin console, select System > Configuration > Security > SSL Options.
2. Under Allowed Encryption Strength choose Custom SSL Cipher Selection. See

Figure 165: Setting Custom SSL Cipher Selections
3. Choose the recommended options (in green) if they are not already selected.
4. If you are using client certificate authentication (Pulse Connect Secure only):
 Select Enable client certificate on the external port under ActiveSync Client Certificate
Configuration.
 Move p_ecdsa256 to the Selected Virtual Ports column.
A list of the custom ciphers to be used on the device’s port is displayed in the order
the web server will select them. Note that Suite B ciphers are listed on top. See
Figure 166 on page 635. End users who now log in to external virtual port p_ecdsa256
must have at least one of the listed ciphers installed on their browser or else they
cannot log in to the server.

Figure 166: Confirming Custom Ciphers
6. Click Change Allowed Encryption Strength.

Documentation  Verifying the Certificate on the Client on page 642



CHAPTER 17
FIPS Level 1 Support (Software FIPS)
 Understanding Pulse Secure FIPS Level 1 Support on page 637

 FIPS Supported Platforms on page 638
 Enabling FIPS Level 1 Support on page 638
 Verifying the Certificate on the Client on page 642
 Using TCP Dump to View Cipher Information on page 644
 Turning Off FIPS Level 1 Support from the Serial Console on page 647
 Installing a Self-Signed Certificate From the Serial Console on page 647
 Supported Cipher Suites when FIPS Level 1 Support is Enabled and Disabled on page 648
Understanding Pulse Secure FIPS Level 1 Support
 What Is FIPS? on page 637

 What Is FIPS Level 1 Support? on page 638
What Is FIPS?
Federal Information Processing Standard (FIPS) are a set of standards that define security
requirementsfor products that implement cryptographic modulesused to secure sensitive
but unclassified information. The most recent standards are defined in the FIPS
Publication 140-2.
The FIPS documents define, among other things, security levels for computer and
networking equipment. U.S. Federal Government departments, and other organizations,
use FIPS to evaluate the cryptographic capabilities of the equipment they consider for
purchase. Cryptographic modules are validated against separate areas of the FIPS
specification. An overall certification level is assigned based on the minimum level
achieved in any area. Although primarily aimed at environments requiring strict security,
FIPS levels are increasingly enforced as qualifying criteria for all U.S. Federal Government
contracts. Security-conscious private enterprises might also use FIPS levels as an
equipment evaluation benchmark. FIPS levels also serve as a customer-neutral description
of vendor requirements. Vendors can engineer security products to FIPS levels and extend
the applicability and eligibility of these products across a broad customer base, thereby
eliminating exhaustive and time-consuming customer-by-customer product qualification
procedures.

What Is FIPS Level 1 Support?

Pulse Secure offers FIPS level 1 support starting with Pulse Connect Secure release
7.4 and Pulse Policy Secure release 4.4. Both services use a 140-2 level 1 certified
cryptographic module to comply with FIPS. When FIPS level 1 support is enabled
applications, such as browsers, accessing the web server must support Transport Layer
Security (TLS), the latest version of Secure Socket Layer (SSL). If the platform features
hardware acceleration, then for SSL processing SSL hardware acceleration is disabled
as hardware acceleration does not comply with FIPS validation. Only FIPS approved
algorithms are used when in FIPS level 1 support is enabled.
NOTE: You cannot run FIPS level 1 support on a hardware FIPS platform such
as the SA6500 FIPS SSL VPN Appliance. For more information on the
hardware FIPS platform, see the Pulse Connect Secure Administration Guide
and the Pulse Policy Secure Administration Guide.
Related FIPS Supported Platforms on page 638

Documentation

 Pulse FIPS Mode Overview for Pulse Policy Secure
 Pulse FIPS Mode for Pulse Connect Secure Overview
FIPS Supported Platforms
The following platforms support FIPS level 1:
 Pulse Secure Gateway MAG2600
 Pulse Secure Gateway MAG-SM160
 Pulse Secure Gateway MAG-SM360
 Pulse Connect Secure and Pulse Policy Secure virtual appliances
Related Understanding Pulse Secure FIPS Level 1 Support on page 637

Documentation

Enabling FIPS Level 1 Support
Once you enable FIPS level 1 support, your browser is restricted to specific custom cipher
strengths. A list of supported ciphers is shown during the enabling process.

Chapter 17: FIPS Level 1 Support (Software FIPS)
When you enable FIPS level 1 support, the following events occur on the system:
 The Web server restarts and turns on FIPS level 1 support. The Web server now allows
only TLSv1.0, TLSv1.1 and TLSv1.2 protocols that include FIPS approved cryptographic
algorithms which include Suite B cipher suites.
NOTE: Once FIPS level 1 support is enabled, new client sessions will use
FIPS if the client supports FIPS. Existing client sessions may not be using
FIPS. To ensure FIPS capable clients are in FIPS level 1 support, all client
sessions should be terminated after the FIPS level 1 support is enabled.
Administrators can use the System > Status > Active Users page to terminate
client sessions.
 If the platform features hardware acceleration, when FIPS level 1 support is enabled
SSL processing does not utilize the hardware acceleration. IPSec hardware acceleration
is not affected.
NOTE: You cannot enable FIPS level 1 support on a Pulse Secure FIPS
platform, such as the SA6500 FIPS SSL VPN Appliance.
The following event logs are generated for FIPS level 1 support:
 SYS30966 when the web server turns FIPS level 1 support on.
 ADM30965 when the administrator turns FIPS level 1 support on or off.
 ERR30967 when the web server fails to turn on FIPS level 1 support.
To enable FIPS level 1 support:
1. Select System > Configuration > Security > SSL Options.
2. Under SSL FIPS Mode option, select Turn on FIPS mode. See Figure 167 on page 640.

Figure 167: Enabling FIPS Level 1 Support
Once you turn on FIPS level 1 support, the following changes are made:
 Under Allowed SSL and TLS Version, the Accept only TLS option is selected. .
 Under Allowed Encryption Strength, the Custom SSL Cipher Selection is set. See
Figure 167 on page 640. Only FIPS approved algorithms are selected. All other options
under this section are disabled. See “Supported Cipher Suites when FIPS Level 1
Support is Enabled and Disabled” on page 648
 Under Encryption Strength, the Do not allow connections from browsers that only
accept weaker ciphers option is selected. You cannot disable this selection.
A window shows the supported custom ciphers. See Figure 168 on page 641 for an
example. Your output may be different.

Figure 168: Example of Allowed Encryption Strengths
4. Click Change Allowed Encryption Strength.
FIPS Level 1 support is now enabled on the device. If your browser does not support
any of the listed ciphers, you will not be able to log in to the device.
Entries are made in the Events logs (see Figure 169 on page 642) and Admin Access logs
(see Figure 170 on page 642) to show that FIPS level 1 support is enabled.

Figure 169: Events Log Entries for FIPS Level 1
Figure 170: Admin Access Logs for FIPS Level 1 Encryption Strength
Changes
Related Understanding Pulse Secure FIPS Level 1 Support on page 637

Documentation
 FIPS Supported Platforms on page 638

 Supported Cipher Suites when FIPS Level 1 Support is Enabled and Disabled on page 648
Verifying the Certificate on the Client
End users can check which certificate their browser is using to connect to the server. In
the following example, the end user connects to server port p3, which uses an ECC curve
P-256 certificate. See Figure 171 on page 642.
Figure 171: Connecting to a Port Using an ECC Curve P-256 Certificate

To view the certificate from an Internet Explorer 8 browser:
1. Open an Internet Explorer 8 browser and point to the server to which you want to
connect.
2. Click the lock icon located at the end of the address bar and then click the View
Certificate link. See Figure 172 on page 643.
Figure 172: Viewing the Connection Certificate Information
3. Click the Details tab and scroll down until you see the Public key field. In this example,
the public key value is ECC (256 Bits) which matches the server port p3 certificate
shown in Figure 171 on page 642. See Figure 173 on page 643.
Figure 173: Certificate Public Key
Related Understanding ECC Certificates on page 626

Documentation
 Using TCP Dump to View Cipher Information on page 644


Using TCP Dump to View Cipher Information
You can use the TCP Dump tool to view which cipher each client uses to connect to the
server. TCP Dump is a packet analyzer that intercepts (sniffs) and displays TCP/IP and
other packets transmitted or received between the server and clients.
NOTE: To permit debugging, it is recommended that the ECC certificate be

replaced by an RSA certificate so that an RSA cipher suite gets selected and
then the application data can be decoded.
To capture packet headers:
1. Select Maintenance > Troubleshooting > Tools > TCP Dump.
2. Select the interface, internal or external or both, you wish to sniff and then the VLAN
port.
3. Click Start Sniffing.
The next time a user points a browser window to the server or logs in to the server,
handshake information is obtained.
4. Click Stop Sniffing when done.
To view the packet headers:
1. Select Maintenance > Troubleshooting > Tools > TCP Dump.
2. Under Dump file, select SSLDump from the file menu and the certificate to use. See
Figure 174: Viewing the TCP Dump Output
The certificate names in the TCP Dump window are the same as the “Certificate issued
to” names in the Device Certificates window. Select the certificate corresponding to
the port you wish to view packet information. See Figure 175 on page 644.
Figure 175: Issued to Certificate on the Device Certificates Pages
3. Click Get.

Portions of a TCP dump output follow.
The client starts a handshake with the server:
1 1 0.0007 (0.0007) C>S Handshake
The client then lists its supported cipher suites:
cipher suites
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_SHA
TLS_ECDH_ECDSA_WITH_DES_CBC3_SHA
...
The server acknowledges the handshake:
1 2 0.0010 (0.0003) S>C Handshake
The server compares the cipher suites on the client with the ones on the server and picks
the cipher suite that is preferred by the server based on SSL options:
cipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384

Example TCP Dump New TCP connection #1: 10.64.8.3(46200) <-> 10.64.90.21(443)
Output 1 1 0.0007 (0.0007) C>S Handshake
ClientHello
Version 3.3
cipher suites
TLS_ECDH_ECDSA_WITH_DES_CBC3_SHA
TLS_ECDH_ECDSA_WITH_RC4_SHA
Unknown value 0xc001
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
compression methods
NULL
ClientHello Extensions [113]=
00 6f 00 0b 00 04 03 00 01 02 00 0a 00 34 00 32
00 0e 00 0d 00 19 00 0b 00 0c 00 18 00 09 00 0a
00 16 00 17 00 08 00 06 00 07 00 14 00 15 00 04
00 05 00 12 00 13 00 01 00 02 00 03 00 0f 00 10
00 11 00 23 00 00 00 0d 00 22 00 20 06 01 06 02
06 03 05 01 05 02 05 03 04 01 04 02 04 03 03 01
03 02 03 03 02 01 02 02 02 03 01 01 00 0f 00 01
01
1 2 0.0010 (0.0003) S>C Handshake
ServerHello
Version 3.3
session_id[32]=
a3 07 40 6e 73 12 c2 4d f3 7d b9 77 f8 97 e1 94
fc 1b 51 6a 66 3c 99 d6 c7 7d 0e fa 29 2e d0 c4
cipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
compressionMethod NULL
ServerHello Extensions [20]=
00 12 ff 01 00 01 00 00 0b 00 04 03 00 01 02 00
0f 00 01 01
1 3 0.0010 (0.0000) S>C Handshake
Certificate
1 4 0.0010 (0.0000) S>C Handshake
ServerHelloDone
1 5 0.1413 (0.1403) C>S Handshake
ClientKeyExchange
1 6 0.1413 (0.0000) C>S ChangeCipherSpec
1 7 0.1413 (0.0000) C>S Handshake
1 8 0.1464 (0.0051) S>C ChangeCipherSpec
1 9 0.1464 (0.0000) S>C Handshake
1 10 9.2389 (9.0924) C>S application_data
1 11 9.5828 (0.3438) C>S application_data
1 12 9.5833 (0.0004) S>C application_data
1 9.5833 (0.0000) S>C TCP FIN
1 13 9.5999 (0.0166) C>S Alert
1 9.5999 (0.0000) C>S TCP FIN
Related Understanding ECC Certificates on page 626

Documentation


Turning Off FIPS Level 1 Support from the Serial Console

Problem If you have FIPS level 1 support enabled and your browser does not support the required
cipher suites, you cannot access the device. If this happens to an administrator account,
you can no longer administer or configure the system.
Solution You can turn off FIPS level 1 support and reset the encryption strength from the device’s
serial console. After choosing that option, SSL options are reset to Accept only SSL V3
and TLS and to Accept only 128-bit and greater encryption strength.
Open a serial console to your device and select option 8. Turn off FIPS Mode and reset
allowed encryption strength for SSL.
Turning Off FIPS Level Please choose the operation to perform:

1 and Resetting 1. Network Settings and Tools
Encryption Strength 2. Create admin username and password
From the Serial 3. Display log/status
Console 4. System Operations
5. Toggle password protection for the console (Off)
6. Create a Super Admin session.
7. System Maintenance
8. Turn off FIPS Mode and reset allowed encryption strength for SSL
Choice: 8
NOTE: Once you turn off FIPS level 1 support, option 8 is relabeled “Reset
allowed encryption strength for SSL.”
Related Enabling FIPS Level 1 Support on page 638

Documentation
 Installing a Self-Signed Certificate From the Serial Console on page 647

Installing a Self-Signed Certificate From the Serial Console

Problem An administrator can be locked out of the system if their browser does not support the
certificate assigned to the network port. For example, if your system has an ECC certificate
assigned to the internal port and your browser does not support ECC certificates you
cannot log in to the device using the internal port.
Solution You can use the serial console to create and install a self-signed RSA certificate onto
the internal port to allow access. Once you connect to the serial console, select option
4. System Operations followed by Option 7. Install self-signed certificate. It may take a
few minutes for the 2048-bit key size self-signed certificate to be created and installed
on your device. Once the certificate is installed, you can now log in to the device.
Creating and Installing Please choose the operation to perform:

an RSA Certificate 1. Network Settings and Tools
2. Create admin username and password

From the Serial 3. Display log/status

Console 4. System Operations
5. Toggle password protection for the console (Off)
6. Create a Super Admin session.
7. System Maintenance
8. Turn off FIPS Mode and reset allowed encryption strength for SSL
Choice: 4
Please choose the operation to perform:

1. Reboot this Pulse Connect Secure
2. Shutdown this Pulse Connect Secure
3. Restart services at this Pulse Connect Secure
4. Rollback this Pulse Connect Secure
5. Factory reset this Pulse Connect Secure
6. Clear all configuration data at this Pulse Connect Secure
7. Install self-signed certificate
Choice: 7
Are you sure you want to install a newly-created RSA self-signed certificate on
the internal port? (y/n) y
Please provide information to create a self-signed Web server

digital certificate.
Common name (example: secure.company.com): myname.mycompany.com
Organization name (example: Company Inc.): MyCompany Inc.
Please enter some random characters to augment the system's

random key generator. We recommend that you enter approximately
thirty characters.
Random text (hit enter when done):abcdef1234567
Creating self-signed digital certificate - this may take several minutes...

The self-signed digital certificate was successfully created.

Documentation

Supported Cipher Suites when FIPS Level 1 Support is Enabled and Disabled
The tables in this topic list the cipher suites that are supported by the web server when
the FIPS level 1 support is disabled and enabled.
Supported Cipher Suites When FIPS Level 1 Support is Disabled

When the FIPS level 1 support is disabled and when SSL hardware acceleration is not
present or is disabled, the web server gives preference to cipher suites that use RC4 for
bulk encryption. When SSL hardware acceleration is present and enabled, the web server
gives preference to AES128, AES256 and 3DES over RC4, in that order.
Table 78: Supported Cipher Suites With FIPS Level 1 Support Off, Hardware Acceleration
Enabled and RSA Server Certificates In Use
Cipher Suite Protocol

Enabled and RSA Server Certificates In Use (continued)
TLS_RSA_WITH_AES_128_CBC_SHA256 TLSv1.2
TLS_RSA_WITH_AES_128_CBC_SHA SSLv3 and above
TLS_RSA_WITH_3DES_EDE_CBC_SHA SSLv3 and above
TLS_RSA_WITH_RC4_128_SHA SSLv3 and above
TLS_RSA_WITH_AES_128_GCM_SHA256 TLSv1.2
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLSv1.2
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA SSLv3 and above
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA SSLv3 and above
TLS_ECDHE_RSA_WITH_RC4_128_SHA SSLv3 and above
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLSv1.2
TLS_RSA_WITH_RC4_128_MD5 SSLv3 and above
Enabled and ECC Server Certificates In Use
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLSv1.2
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLSv1.2
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA SSLv3 and above
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 TLSv1.2

Enabled and ECC Server Certificates In Use (continued)
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLSv1.2
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 TLSv1.2
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 TLSv1.2
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA SSLv3 and above
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA SSLv3 and above
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA SSLv3 and above
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA SSLv3 and above
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA SSLv3 and above
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA SSLv3 and above
TLS_ECDH_RSA_WITH_RC4_128_SHA SSLv3 and above
TLS_ECDH_ECDSA_WITH_RC4_128_SHA SSLv3 and above
Enabled and RSA Server Certificates In Use

Enabled and RSA Server Certificates In Use (continued)
TLS_RSA_WITH_RC4_128_SHA SSLv3 and above
TLS_RSA_WITH_3DES_EDE_CBC_SHA SSLv3 and above
TLS_ECDHE_RSA_WITH_RC4_128_SHA SSLv3 and above
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA SSLv3 and above
TLS_RSA_WITH_RC4_128_MD5 SSLv3 and above
Table 81: Supported Cipher Suites With FIPS Level 1 Support Off, Hardware Acceleration Disabled
and ECC Server Certificates In Use
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA SSLv3 and above
TLS_ECDH_RSA_WITH_RC4_128_SHA SSLv3 and above
TLS_ECDH_ECDSA_WITH_RC4_128_SHA SSLv3 and above

Table 81: Supported Cipher Suites With FIPS Level 1 Support Off, Hardware Acceleration Disabled
and ECC Server Certificates In Use (continued)
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA SSLv3 and above
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA SSLv3 and above
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA SSLv3 and above
Supported Cipher Suites When FIPS Level 1 Support is Enabled

When FIPS level 1 support is enabled, only TLSv1.0, v1.1, v1.2 and AES256, 3DES and
AES128 are allowed. The order of the cipher suites is not dependent on the SSL hardware
acceleration module since hardware acceleration is not used when FIPS level 1 support
is enabled.

When FIPS level 1 support is enabled, the following settings are automatically configured:
 In the SSL Options window:
 Under Allowed SSL and TLS Version, the Accept only TLS option is selected. All other
options under this section are disabled.
 Under Allowed Encryption Strength, the Custom SSL CIpher Selection option is
selected. Only FIPS approved algorithms are selected. All other options under this
section are disabled.
 Under Encryption Strength Option, the Do not allow connections from browsers that
only accept weaker ciphers option is selected.
 SSL hardware acceleration is disabled. IPsec hardware acceleration is not affected by

the FIPS level 1 support being enabled.
In Table 82 on page 653, the first four cipher suites are given preference due to the
requirements in RFC 6460. The first two cipher suites meeting the requirement for Suite
B Profile for TLS 1.2. The next two meeting the requirement for Suite B Transitional Profile
for TLS 1.0 and 1.1.
Table 82: Supported Cipher Suites With FIPS Level 1 Support On and ECC Server Certificates
In Use
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLSv1.0 and above
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLSv1.0 and above
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA TLSv1.0 and above
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA TLSv1.0 and above
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA TLSv1.0 and above
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA TLSv1.0 and above

Table 82: Supported Cipher Suites With FIPS Level 1 Support On and ECC Server Certificates
In Use (continued)
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA TLSv1.0 and above
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA TLSv1.0 and above
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA TLSv1.0 and above
Table 83: Supported Cipher Suites With FIPS Level 1 Support On and RSA Server Certificates
In Use
TLS_RSA_WITH_AES_256_CBC_SHA TLSv1.0 and above
TLS_RSA_WITH_3DES_EDE_CBC_SHA TLSv1.0 and above
TLS_RSA_WITH_AES_128_CBC_SHA TLSv1.0 and above
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLSv1.0 and above
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLSv1.0 and above
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLSv1.0 and above

Table 83: Supported Cipher Suites With FIPS Level 1 Support On and RSA Server Certificates
In Use (continued)

Documentation  Example: Assigning an ECC P-256 Certificate to an External Virtual Port and Giving
 Preference to Suite B Ciphers on page 628


CHAPTER 18
Configuration File Administration
This chapter describes features for managing configuration files. It includes the following
information:
 Configuration File Administration Overview on page 657

 Configuring Archiving for System Logs, Configuration Files, and Snapshots on page 658
 Using the Configuration Backup and Restore Feature on page 664
 Using the Import/Export Feature for Binary System Configuration Files on page 665
 Using the Import/Export Feature for Binary User Configuration Files on page 670
 Using the Import/Export Feature for XML Configuration Files on page 674
 Guidelines for Modifying Configuration XML Files on page 680
 Example: Using the Configuration XML File Import/Export Feature to Add Multiple
Users on page 688
 Using the Push Configuration Feature on page 690
Configuration File Administration Overview
The system supports multiple administrator utilities related to configuration file

management. Table 84 on page 657 describes the purpose of the different utilities.
Table 84: Utilities for Configuration File Administration
Utility Recommended Usage
Archiving Schedule periodic backups to a remote backup server. You should schedule archiving for both the system
configuration binary file (system.cfg) and the user configuration binary file (user.cfg). If necessary, you can
import an archived configuration using the configuration binary file import/export feature.
Local backup Create backups on the local system as a precaution when making significant configuration changes. With
and restore this utility, you can quickly restore to a previous configuration.

Table 84: Utilities for Configuration File Administration (continued)
Utility Recommended Usage
Binary Export binary configuration files to a local host (an alternative to the remote archiving server and archiving
configuration file process that runs as a scheduled job). You might do this if you do not use or do not have access to an
import/export archiving server, or if you want to make use of a configuration that has not yet been archived. You can export
the binary system configuration file (system.cfg) and the binary user configuration file (user.cfg).
You can use the binary file import/export feature to clone a configuration that you want to deploy more
broadly, such as deploying a backup device or to a group of devices. You can use “selective import” options
to exclude unique network identifiers (such as IP address) that would cause problems if the configuration
were to be wholly imported and activated.
XML Import or export the configuration for only the features and settings you select. This enables you to take a
configuration file more granular approach to mass configuration management than the binary file import/export feature.
import/export For example, you might want to populate an authentication server configuration across a large number of
nodes. You can export just that configuration element, and when you import it in the other nodes, you do
not overwrite the large number of configuration elements that you would if you had imported the user.cfg
file.
You might also find the XML file import/export feature useful when managing a single node. For example,
you might want to add many new users to the local authentication server, which can be faster editing the
XML than using the user interface. Or you might want to make global changes to the configuration object
naming conventions or descriptions as part of a “housekeeping” initiative. This, too, might be accomplished
faster editing the XML than clicking through the user interface.
Push Push a partial configuration from the running configuration on the source system to the running configuration
configuration on one or more target systems. This is the best option to instill common configuration elements if the
devices that already deployed and currently online.
Related Configuring Archiving for System Logs, Configuration Files, and Snapshots on page 658
Documentation
 Using the Configuration Backup and Restore Feature on page 664

 Using the Import/Export Feature for Binary System Configuration Files on page 665
 Using the Import/Export Feature for Binary User Configuration Files on page 670
 Using the Import/Export Feature for XML Configuration Files on page 674
 Using the Push Configuration Feature on page 690
Configuring Archiving for System Logs, Configuration Files, and Snapshots
You can schedule periodic archiving for system logs, system configuration files, and
system snapshots. Periodic archiving occurs only at the scheduled time. “Unscheduled”
archiving does not occur automatically. For example, if a log file exceeds the maximum
file size, the archiving process does not automatically back up the file prior to the
scheduled time to prevent data loss.
If the archive process fails, archiving restarts at the next scheduled time. The system
does not continue to retry the process if it fails, and log files are not deleted.
We recommend that you schedule an archive operation during hours when traffic is light
to minimize its impact on users. The automatic archiving process compresses files and,

Chapter 18: Configuration File Administration
if the system is busy, can degrade performance for users. Also, a cluster node might
appear unresponsive if the system is busy with traffic and performing archiving
simultaneously.
NOTE: If you schedule an archive operation to occur during the hour that your
system switches to daylight savings time (DST), the operation might not
occur as scheduled. For example, if your system is set to change to DST at
1:00 AM, and you scheduled an archive job to occur at anytime between 1:01
AM and 1:59 AM, then the operation does not take place because at 1:00 AM
the system clock is moved forward to 2:00 AM, and the system never reaches
the archive time for that date.
To configure log archiving:
1. Select Maintenance > Archiving > Archiving Servers to display the configuration page.
Figure 176 on page 660 shows the archiving configuration page for Pulse Policy
Secure.

Figure 176: Archiving Configuration Page – Pulse Policy Secure

Figure 177: Archiving Configuration Page – Pulse Connect Secure

Table 85: Archiving Configuration Guidelines
Settings Guidellines
Archive Settings
Archive Server Specify the fully qualified domain name or IP address of the server to which to send the archive
files.
Destination Directory Specify the destination directory. Follow these recommendations:
 For UNIX systems, you can specify an absolute or relative path. We recommend you specify
a full path.
 For Windows systems, specify a path that is relative to the ftproot directory. We recommend
you specify a full path.
Do not include a drive specification for the destination directory, such as: juniper/log.
Username Specify a username that has privileges to log into the server and write to the destination directory.
Password Specify the corresponding password.
Method Select SCP or FTP.
SCP is the default method. SCP is a file transfer utility similar to FTP. SCP encrypts all data
during transfer. When the data reaches its destination, it is rendered in its original format. SCP
is included in most SSH distributions and is available on all major operating system platforms.
Archive Schedule
Archive events log Schedule archiving for the Events log. The archive file has the following format:
JuniperEventsLog-[clustername|standalone]-[nodename|hostname]-
[IVSname|root]-[date]-[time]
For example, an archive file for a cluster named Gen has a filename similar to the following:
JuniperEventsLog-Gen-node1-Root-20090109-1545.gz.
The archiving schedule configuration includes the following options:
 Use this filter—Select a log format filter.

 Day of week—Select the days of the week on which to run the archiving job.
 Every hour or a Specified Time. The Every hour option runs a job every hour on the hour for the
selected days. The specified time option runs a job once on the selected days.
 Clear log after archiving. Select this option to clear the local log file after the archiving job is
successfully completed. If an archive job fails, the log files are not deleted.
 Password—(Optional) Specify a password to secure and encrypt system configuration or user
account archives.
Archive user access log Schedule archiving for the User Access log. The archive file has the following format:
JuniperAccessLog-[clustername|standalone]-
[nodename|hostname]-[IVSname|root]-[date]-[time]
The archiving schedule configuration includes the same options as those described for the Events
log.

Table 85: Archiving Configuration Guidelines (continued)
Settings Guidellines
Archive admin access log Schedule archiving for the Admin Access log. The archive file has the following format:
JuniperAdminLog-[clustername|standalone]-
log.
Archive sensors log Schedule archiving for the Sensors log. The archive file has the following format:
JuniperSensorsLog-[clustername|standalone]-
log.
Archive client-side log Schedule archiving for client-side log uploads. This option is available only on Secure Access
uploads Service.
log, except for log filter format, which is not applicable to the client-side logs.
Archive system Schedule archiving for the system configuration binary file (system.cfg). The archive file has the
configuration following format:
JuniperConf-[clustername|standalone]-
The archiving schedule configuration includes the same day, time, and password-protection
options as those described for the Events log.
Archive user accounts Schedule archiving for user account configuration binary file (user.cfg). The archive file has the
following format:
JuniperUserAccounts-[clustername|standalone]-
The archiving schedule configuration includes the same day, time, and password-protection
options as those described for the Events log.
Archive XML configuration Schedule archiving for the XML configuration files.
The archiving schedule configuration includes the same day and time options as those described
for the Events log.
Archive debug log Enable archiving for collected debug logs.
You cannot specify a day and time for archiving debug logs. If you select this option, debug logs
are archived periodically and cleared if the Clear log after archiving option is selected.
Archive periodic snapshots Enable archiving for snapshots.
You cannot specify a day and time for archiving periodic snapshots. If you select this option,
snapshots are archived periodically.

Related Logging Overview on page 715

Documentation
 Logging Overview

Using the Configuration Backup and Restore Feature
You can save up to five system configuration backups and five user account backups on
the local server. If you exceed this limit, the system overwrites the oldest backup with
the new backup. If you do not want to overwrite the oldest backup, select and delete
another backup instead, before you save the most current one.
To manage configuration file backups:
1. Select Maintenance > Archiving > Local Backups to display the configuration page.
Figure 178 on page 664 shows the archiving configuration page for Pulse Policy
Secure.
Figure 179 on page 665 shows the archiving configuration page for Pulse Connect
Secure.
2. Use the controls to backup or restore the configuration as described in

Figure 178: Local Backups Management Page – Pulse Policy Secure

Figure 179: Local Backups Management Page – Pulse Connect Secure
Table 86: Local Backups Management Guidelines
Controls Guidelines
System Configuration
Save Create a backup of the running configuration.
Configuration
Delete Select a row in the table and click Delete to delete the backup.
Restore Select a row in the table and components in the “Include when restoring” column and click Restore to
replace the running configuration with the archived configuration.
User Configuration
Save Create a backup of the running configuration.
Configuration
Delete Select a row in the table and click Delete to delete the backup.
Restore Select a row in the table and click Restore to replace the running configuration with the archived configuration.
Related Configuration File Administration Overview on page 657

Documentation

Using the Import/Export Feature for Binary System Configuration Files
This topic describes the import/export feature for binary system configuration files. It
 Binary System Configuration File Overview on page 666

 Exporting a Binary System Configuration File on page 667
 Importing a Binary System Configuration File on page 668

Binary System Configuration File Overview

The Pulse Policy Secure access management framework enables you to import and
export the system and network settings using binary system configuration files. When
importing a system configuration file, you can exclude the device certificate and the
server’s IP address or network settings from the imported information. For example, to
set up multiple Pulse Policy Secure or Pulse Connect Secure systems behind a load
balancer, import everything except for the IP address. To set up the system as a backup
server, import everything except for the digital certificate and the network settings.
The binary system configuration file includes the following settings:
 Network settings
 Certificates. The system imports only device certificates, not the chains that correspond
to the device certificates or trusted client CAs.
 Cluster configuration
 Licenses. When you import a configuration file that contains licenses, the system gives
precedence to any existing licenses. Licenses are imported only if no licenses are
currently installed.
 SNMP settings
 Sensor configuration. Sensor configurations are included in the system configuration

file while sensor event policies are included in the user configuration file. To import or
export all sensor-related settings, import or export both the system and user
configuration files. The user configuration file, not the system configuration file, includes
resource profiles, resource policies, and the local user database. To perform a complete
backup, export both the system and user configuration files.
 Client-side logs. To import or export client-side logs, import or export both the system
and user configuration files.
 Mail proxy. Pulse Connect Secure only.
 Web proxy servers. Pulse Connect Secure only. To export all web proxy related
information, both the system and user configuration files are needed.
 Web caching options. Pulse Connect Secure only.
 Rewriter filters. Pulse Connect Secure only.
NOTE:
 Import of system and user configuration across different hardware
platforms is not supported. For example, exporting a system configuration
from an SA6000 device and importing it to an SA4500 device is not
supported and may result in unexpected behavior.
 You can import an SA Series FIPS configuration file into a non-SA Series
FIPS machine and vice versa provided that you do not include the certificate
and security world in the import process.

Exporting a Binary System Configuration File

To export a binary system configuration file:
1. Select Maintenance > Import/Export > Import/Export Configuration to display the

configuration page.
2. Complete the configuration and export operation as described in Table 87 on page 668.
Figure 180: Export Binary System Configuration File Configuration Page

– Pulse Policy Secure

Figure 181: Export Binary System Configuration File Configuration Page

– Pulse Connect Secure
Table 87: Export Binary System Configuration File Configuration and Action Guidelines
Settings Guidelines
Password for Specify a password to encrypt and secure the configuration file.
configuration file
Confirm password Specify the password.
Save Config As Display a dialog box to save the file to your local host.
Importing a Binary System Configuration File

To import a binary system configuration file:
1. Select Maintenance > Import/Export > Import/Export Configuration to display the

configuration page.
2. Complete the configuration and import operation as described in Table 88 on page 669.

Figure 182: Import Binary System Configuration File Configuration Page
Table 88: Import Binary System Configuration File Configuration and Action Guidelines
Settings Guidelines
Options
Import Device Overwrite the existing device certificate(s) with the ones in the imported configuration file.
Certificate(s)?
NOTE: When importing a device certificate in to an SA Series FIPS Appliance, note that you must
choose a certificate that uses a FIPS-compliant private key. To ensure FIPS-compliance, select a
certificate and corresponding security world private keys were generated on an SA Series FIPS
Appliance.
Other Import Options

Table 88: Import Binary System Configuration File Configuration and Action
Guidelines (continued)
Settings Guidelines
Import everything Import all settings except the device certificate.

(except Device
Certificate(s))
Import everything but the Do not overwrite the existing configuration for network interface IP addresses, netmask, default
IP address gateway, virtual interfaces, ARP tables, and route tables. Use this option only if the exported
configuration file is from a standalone node.
TIP: To set up multiple nodes in a cluster behind a load balancer, import everything except the IP
address.
Import everything except Do not allow the imported configuration to change the existing configuration for settings found in
network settings and the Network Settings and Licensing sections. With this option, network configurations, licenses,
licenses cluster configurations, certificates, defined SNMP settings and syslog configurations are not imported.
Always use this option if configuration file was exported from a node that is part of a cluster.
TIP: To set up a backup node, import everything except network settings and digital certificates.
Import only Device Import the device certificate(s) only. You also must select the Import Device Certificate(s) check
Certificate(s) box.
Config file Use the browse button to locate and select the file from your local host.
Password Specify the password (if applicable).
Import Config Import the configuration file.
Using the Import/Export Feature for Binary User Configuration Files
This topic describes the import/export feature for user configuration binary files. It includes
 Binary User Configuration File Overview on page 670

 Exporting a Binary User Configuration File on page 671
 Importing a Binary User Configuration File on page 673
Binary User Configuration File Overview
In general, if a menu item falls under the Authentication, Administration, Users, or the
UAC menu, the item is included in the user configuration file (user.cfg). The exception is
Sensors event policies, which are under System, but which are exported in the user
configuration file. In particular, the user configuration file includes the following settings:
 Sign-in settings (includes sign-in policies, sign-in pages, all authentication servers,
authentication protocol sets, Pulse, and OAC settings)
 Authentication realms (including admin realms, user realms, and MAC authentication
realms)

 Roles
 Network access. Pulse Policy Secure only.
 Infranet Enforcers. Pulse Policy Secure only.
 Host Enforcer. Pulse Policy Secure only.
 Resource profiles. Pulse Connect Secure only.
 Resource policies
 Sensor event policies
 User accounts
 Client-side logs. To export or import client-side logs, export or import both the system
and user configuration files.
Exporting a Binary User Configuration File

To export a binary user configuration file:
1. Select Maintenance > Import/Export > Import/Export Users to display the configuration
page.

Figure 183: Binary Export User Configuration File Configuration Page –

Pulse Policy Secure
Figure 184: Binary Export User Configuration File Configuration Page –

Pulse Connect Secure

Table 89: Binary Export User Configuration File Configuration and Action Guidelines
Settings Guidelines
Password for (Optional) Specify a password to encrypt and secure the configuration file.
configuration file
Confirm password Specify the password.
Save Config As Display a dialog box to save the file to your local host.
Importing a Binary User Configuration File

To import a binary user configuration file:
1. Select Maintenance > Import/Export > Import/Export Users to display the configuration
page.
Figure 185: Import User Configuration Binary File Configuration Page
Table 90: Import Binary User Configuration File Configuration and Action Guidelines
Settings Guidelines
Browse Locate and select the file from your local host.

Table 90: Import Binary User Configuration File Configuration and Action Guidelines (continued)
Settings Guidelines
Password Specify the password (if applicable).
Import Config Import the configuration file.
Using the Import/Export Feature for XML Configuration Files
This topic describes the import/export feature for XML configuration files. It includes the
 XML Configuration File Overview on page 674

 Guidelines and Limitations on page 674
 Exporting an XML Configuration File on page 675
 Importing an XML Configuration File on page 679
XML Configuration File Overview

The system maintains its configuration in a structured XML file. This enables the system
to support an alternative to the complete configurations that are exported and imported
with the configuration binary files. You can use the export/import configuration XML
pages to export and import selected configuration elements.
You might find the feature useful when performing the following tasks:
 Adding to the configurations of peer nodes, for example, adding a large number of
users.
 Modifying multiple instances of a single setting, for example, an authentication server

name.
 Deleting settings, for example, deleting authentication servers that are no longer used.
 Creating a configuration template to use for setting up new nodes.
 Tracking configuration changes by comparing differences on periodic exports.
Guidelines and Limitations

Table 91 on page 675 summarizes the guidelines and limitations for using the XML
import/export feature.

Table 91: XML Import/Export Guidelines and Limitations
Category Guidelines and Limitations
General The following guidelines and limitations apply:
 You can import and export configuration files only between systems running the same software version.
 You might find it useful to use a text editor to modify configuration elements that ought to be
distinguished, such as configuration object names and descriptions. Never modify the names of the NIC
identifiers. The system relies on knowing that each appliance has two interface cards, known as NIC0
and NIC1.
 Immediately after importing an Active Directory authentication server configuration, you must edit the
configuration to change the Computer Object name. Unexpected problems might arise if two systems
join an Active Directory domain using the same Computer Object name.
Licenses The following rules apply to exported and imported licenses:
 You cannot edit the license data that is exported. It is encrypted.

 An XML import of licenses is valid only if the system does not currently have a license installed. If a license
is installed already, any imported licenses are dropped. If you still intend to import a license, you must
perform a factory reset before you perform the import operation.
 If you import a license after deleting a temporary license, the imported license is dropped because you
might still be able to reactivate the deleted license. The import operation preserves any licensing data.
Clusters The following guidelines apply to importing a configuration file for nodes that belong to a cluster:
 When you perform an import operation on a cluster, all of the cluster nodes must be enabled and running.
If you attempt to import a configuration into a cluster in which a node is not running, the import operation
might hang or your import results might be unpredictable.
 The XML configuration that you import must contain the same set of nodes as the original cluster. The
signature used to synchronize the cluster when the nodes are reenabled is derived from the IP addresses
of the cluster nodes. Therefore, the remaining nodes cannot rejoin the cluster if the imported configuration
yields a different signature.
 When import occurs, the imported configuration file overwrites the node-specific cluster configuration
network settings of the remaining nodes. If you change the node-specific network settings, make sure
you do not make the remaining nodes unreachable.
 After you have exported the file, do not modify settings that could render the primary node unreachable,
such as changes to network settings.
 After you have exported the file, do not modify the XML to change the node name, IP address, or IP
netmask.
 After you have exported the file, do not modify virtual port settings or add new virtual port settings.
Exporting an XML Configuration File

To export an XML configuration file:
1. Select Maintenance > Import/Export > Export XML to display the configuration page.

Figure 186: Export XML File Configuration Page – Pulse Policy Secure

Figure 187: Export XML File Configuration Page – Pulse Connect Secure

Table 92: Export XML File Configuration and Action Guidelines
Settings Guidelines
Schema Files
Schema files Download the XML schema definition (.xsd) files that describe the XML.
Select Settings and Export

Expand All Expand the display of all settings groups.
Select All Select all settings for all groups.
Export Export the selected configuration data to an XML file.
Settings
System Expand this group and select settings found under the System menu.
NOTE: Do not select the DMI Agent unless Juniper Networks Technical Support instructs you to do
so.
Sign-in Expand this group and select settings found under the Sign-in menu.
Endpoint Security Expand this group and select settings found under the Endpoint Security menu.
NOTE: ESAP and JEDI packages are encrypted when exported.
Authentication Realms Expand this group and select authentication realm settings, including user realms and MAC address
authentication realms.
Roles Expand this group and select settings found under the Roles menu.
Resource Profiles Pulse Connect Secure only.
Expand this group and select settings found under the Resource Profiles menu.
Resource Policies Expand this group and select settings resource policies settings.
Junos Pulse Expand this group and select settings found under the Junos Pulse menu.
Local User Accounts Expand this group and select local authentication server settings.
Infranet Enforcer Pulse Policy Secure only.
Expand this group and select settings found under the Infranet Enforcer menu.
Network Access This option is available only on Pulse Policy Secure.
Pulse Policy Secure only.
Maintenance Expand this group and select settings found under the Maintenance menu.
Export Settings?

Table 92: Export XML File Configuration and Action Guidelines (continued)
Settings Guidelines
Export Export the selected configuration data to an XML file.
Importing an XML Configuration File

To import an XML configuration file:
1. Select Maintenance > Import/Export > Import XML to display the configuration page.
Figure 188: Import XML File Configuration Page
Table 93: Import XML File Configuration and Action Guidelines
Settings Guidelines
Schema Files
Schema files Download the XML schema definition (.xsd) files that describe the XML.
Import
XML data file Locate and select the XML file.
Import Import the file. The Import XML Results page is displayed. This page contains information about
the imported network settings, roles, resource policies, and other settings. If there are errors in the
XML, the import operation stops and rolls back the configuration to the previous state. Error messages
are displayed on the Import XML Results page.

Related Example: Using the Configuration XML File Import/Export Feature to Add Multiple
Documentation Users on page 688
  Guidelines for Modifying Configuration XML Files on page 680
Guidelines for Modifying Configuration XML Files
This topic provides guidelines for modifying an exported configuration file. It includes the
 Preparing to Modify a Configuration XML File on page 680

 Understanding the XML Export File on page 681
 Comparing Configuration Settings and Values Shown in the User Interface with the
Ones in the XML File on page 684
 Understanding Referential Integrity Constraints on page 684
 Using Operation Attributes on page 686
Preparing to Modify a Configuration XML File

The following practices might be useful when you export and import XML configuration
elements:
 Define your goals for a particular task:
 What object or objects do you need to add, update, or delete?
 Do you need to complete all modifications in one operation, or can you modify the
configuration in separate operations?
 Is your process a one-time operation, or do you need to perform the same operation
multiple times?
 Are you updating an active system or are you using one configuration as a template
for configuring systems that have not yet been brought online?
 Document the intended changes to the configuration objects:
 Make a list of objects to be added, updated, or deleted.
 For objects to add or update, list specific attribute data.
 List pages or tabs from the admin console that correspond to the objects and
attributes you intend to change.
 Make a binary system snapshot or a binary configuration backup immediately before

you perform the import.
 Make a plan to verify that the completed configuration meets your goals.
 View the Admin Access log to make sure the export and import operations succeeded.
 Perform a random check of the modified items. Make sure items were added, updated,
or deleted as you expected.

 Make sure you are able to view configuration details in both the admin console and
XML file while you work on the modifications, typically in the following sequence.
1. Use the admin console to correlate the configuration data with the data in the XML
file.
2. Use the XML file to locate and modify the configuration data.
3. Use the admin console to verify the successful import.
 Use an XML editor. The exported XML files have a standard structure. Once you become
familiar with the structure, you can navigate the files easily. The files can become large,
so you might find it more efficient to use a commercial or open source XML editor. XML
editors often separate the editable data from the structural display. This separation
reduces or eliminates the risk of accidentally modifying an XML element rather than
its data.
Understanding the XML Export File

When you export a configuration file, the system saves the configuration as an XML file.
The data in the exported file is based on the selections you make when you configure
the export operation. The file contains all of the required XML processing instructions
and namespace declarations, which must be included exactly as defined.
Table 94 on page 681 provides some basic information and guidelines to help you
understand the structured XML used in the export file.
Table 94: Structured XML Files: Basic Information and Guidelines
Topic Guideline
XML schema The export is based on an XML schema. The schema is a separate file that defines the metadata, and that
definition (.xsd) serves as a model or a template for the exported file. Use the XML schema file to:
file
 Identify the structure and sequence of configuration objects.
 Identify optional and required elements, allowable values, default values, and other attributes of the
configuration objects.
You can download the XML schema definition (.xsd) file in either of the following ways:
 From the XML Import/Export pages by clicking a link.

 From the URL where the files are stored on the system (you do not need to sign in).
To access the .xsd file, access the following URL:
https://<IP-or-hostname>/dana-na/xml/config.xsd
Elements An element is a discrete XML unit that defines an object or part of an object. The element typically consists
of a pair of tags that may or may not surround string data. Tags are surrounded by angle brackets (< >).

Table 94: Structured XML Files: Basic Information and Guidelines (continued)
Topic Guideline
Namespaces Namespaces allow you to use the same words or labels in your code from different contexts or XML
vocabularies. Prefixing elements with namespace qualifiers allows the XML file to include references to
different objects that originate in different XML vocabularies and that share the same name. If you do not
prefix elements with namespace qualifiers, the namespace is the default XML namespace, and you refer
to element type names in that namespace without a prefix.
A namespace declaration looks like the following example:
<configuration xmlns="http://xml.juniper.net/ive-sa/6.2R1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
When you see namespace identifiers in your XML files, you do not need to be concerned about them, as
long as you do not delete or modify the identifiers.
Element You should avoid changing the sequence of elements in the XML file, whenever possible. Although the
Sequence schema does not enforce sequence in all cases, you gain no benefit from changing the order of elements
from the order in which they appear in the exported file, and, in some cases, you might invalidate the XML
structure by changing element sequence.
Every XML tag fits into one of the following XML tag types:
 Start tag—Defines the beginning of an element. The start tag consists of an open angle
bracket (<), a name, zero or more attributes, and a close angle bracket (>). Every start
tag must be followed by an end tag at some point in the document.
 End tag—Defines the end of an element. The end tag consists of an open angle bracket
and a forward slash (</), followed by the same name defined in its corresponding start
tag, and ends with a close angle bracket (>).
 Empty tag—The empty tag is denoted in two forms. If a tag pair has no data between
them, the tag pair is considered an empty tag. Officially, according to the XML
specification, an empty tag looks something like this:
<<empty tag example/>>
In this form, the empty tag consists of an open angle bracket (<), followed by an
element name, a slash and a close angle bracket (/>). When you see an empty tag in
your configuration files, it signifies an element that the schema requires to be included
in the XML file, but whose data is optional.
Start tags can contain attributes, and tag pairs (elements) can contain additional
elements. The following example shows an XML file for the Users object. In this example,
you see only the Administrator configuration settings.
<authentication>
<auth-servers>
<auth-server>
<local>
<users>
<user>
<username>admin</username>

<fullname>Platform Administrator</fullname>
<password-encrypted>3u+U</password-encrypted>
<one-time-use>false</one-time-use>
<enabled>true</enabled>
<change-password-at-signin>false</change-password-at-signin>
</user>
</users>
</local>
<name>Administrators</name>
</auth-server>
You make changes to the string data that is displayed between start and end tags. For
example, using the preceding example, you can add to or change the following elements:
 <username>admin</username>
 <fullname>Platform Administrator</fullname>
 <password-cleartext>password</password-cleartext>
 <change-password-at-signin>false</change-password-at-signin>
 <name>Administrators</name>
NOTE: The preceding sample displays the password element’s data as

encrypted data. You can modify the password if you change the element to
password-cleartext. If you modify the password, the password value is visible
until it is imported back into the system. Once imported, the system encrypts
the password.
If you enter passwords for new users in cleartext format, the passwords are visible in the
file, therefore, you might consider setting the Change Password at Next Login option to
true.
NOTE:
 Because passwords are encrypted by default, they are fully portable from
one system to another.
 Use the password-cleartext element and enter a text password when

changing passwords through the XML file.
If you change a user for a given authentication server or an authentication

server for a given user, you are creating a different user, not updating an
existing user or authentication server. User and authentication server together
logically define a unique user.

Comparing Configuration Settings and Values Shown in the User Interface with the Ones in the
XML File
The elements in the XML file are closely related to the objects and their options as you
see them in the admin console. The element names in the XML instance file correlate
closely with the displayed object and option names.
For example, select Users > User Roles > [Role] > General > Session Options in the admin
console. The admin console renders the possible values for a roaming session as an
option button group, consisting of the values:
 Enabled
 Limit to subnet
 Disabled
The following snippet from the exported configuration file shows the session options for
the Users role. On the bolded line, the roaming session option is set to disabled:
<session-options><SessionOptions>
<MaxTimeout>60</MaxTimeout>
<RoamingNetmask />
<Roaming>Enable</Roaming>
<PersistentSession>false</PersistentSession>
</SessionOptions>
In the schema file, you can locate the allowable values for the roaming session option:
<Attribute roaming:START>
<xsd:element name="roaming" minOccurs="0">
...
<xsd:enumeration value="enabled">
...
<xsd:enumeration value="limit-to-subnet">
...
<xsd:enumeration value="disabled">
...
</xsd:element>
<Attribute roaming:END>
To change the value for the roaming session from Disabled to Limit to subnet, replace
disabled with limit-to-subnet.
This example shows that the admin console often provides all of the allowable values,
displayed either in an option button group, as check boxes, as list boxes, or as other types
of user interface components. The XML file displays only the current state of your
configuration. The schema file displays all of the actual values for the configuration
options that are supported.
Understanding Referential Integrity Constraints

The system configuration objects are part of a data model that is enforced through the
use of referential integrity constraints. You cannot change these constraints, but you

should understand them before you attempt to delete objects that maintain dependencies
to other objects.
If you violate the referential integrity constraints, your import operation fails.
In Figure 189 on page 685 the boxes represent object types and the arrows represent
dependent relationships between the object types. Arrows point from dependent objects
to objects.
Figure 189: Object Referential Integrity Constraints
The system does not allow you to delete an object on which another object depends.
Conversely, when you add an object, you must add any other objects on which that object
depends.
Sign-in URLs depend upon realms and sign-in pages. Realms depend upon both
authentication servers and roles. Policies depend upon roles. Users depend upon
authentication servers.
Consider the following scenarios based on the preceding figure:
 If you add sign-in URLs, you must add realms, sign-in pages, roles, and authentication
servers. You need to add an authentication server and at least one role to support the
realm, and you must add the realm and the sign-in page to support the new sign-in
URL.
 If you add a user, you must be able to assign it to an authentication server. If there is
no authentication server on the target node yet, you must add one in the XML file.
 If you add a policy, you must be able to assign it to a role. If there is no role on the target
system, you must add one in the XML file.
 If you delete an authentication server, you might strand realms and users, therefore,
you need to make sure no realms or users depend on the authentication server before
you attempt to delete it.
 If you delete a role, you might strand policies and realms. To delete a role, you must
first delete any policy that depends upon the role, or reassign associated policies to

another role. Also, to delete a role, you must first delete or reassign any realm that
depends upon that role.
 If you delete a sign-in page, you might strand one or more sign-in URLs. To delete a
sign-in page, you must first delete any associated sign-in URLs or reassign them to
other sign-in pages.
Referential integrity checks are performed only during XML import.
Using Operation Attributes

Operation attributes define the positioning or action of XML data within the schema. If
you do not specify an operation attribute, the modified data is merged by default.
XML data with an operation attribute has the following format:
<object1 xc:operation="operator for object1 and its children unless new operator is
defined">
….
<object2>
…
<object3 xc:operation="operator for object3">
…
</object3>
…
</object2>
…
</object1>
The operation attribute is applied to all children objects unless a different operation
attribute is defined in children objects.
The following operation attributes are supported:
 Merge—The configuration data identified by the element that contains this attribute
is merged with the configuration at the corresponding level in the configuration
datastore identified by the target parameter. This is the default behavior.
 Replace—The configuration data identified by the element that contains this attribute
replaces any related configuration in the configuration datastore identified by the target
parameter. Only the configuration actually present in the configuration parameter is
affected.
 Create—The configuration data identified by the element that contains this attribute
is added to the configuration if and only if the configuration data does not already exist
on the device.
 Delete—The configuration data identified by the element that contains this attribute
is deleted in the configuration datastore identified by the target parameter.
 Insert before—Changes the position of a configuration element in an ordered set.
 Insert after—Changes the position of a configuration element in an ordered set.
 Rename—Changes the name of one or more of a configuration object's identifiers.

If you are merging a list of objects to an existing list of objects in the configuration store,
the results of the merged list might be unexpected. During a merge operation the order
of the objects in the new list is not maintained. If you are importing a list of objects and
would like to preserve the order of the new list, you should use the replace operation
attribute. You can also use insert before or insert after to ensure that you produce the
hierarchy that you intended.
Operation attributes are applied to elements recursively unless new operators are also
defined within lower-level elements. There are limitations on the legal operator that can
be used in child elements without conflict with the parent operator. Table 95 on page 687
displays the legal operator relationships between parent and child elements.
Table 95: Legal Operator Attribute Relationships
Child > Insert

V-Parent Create Merge Replace Delete before
None OK OK OK OK OK
Create OK OK Error Error OK
Merge OK OK OK OK OK
Replace Error OK OK Error OK
Delete Error OK Error OK Error
Insert OK OK OK OK OK
before
Insert OK OK OK OK OK
after
Rename OK OK OK OK OK
The following examples demonstrate the import operation:
Example 1: Set the MTU to 1500 on an interface named "Ethernet0/0" in the running
configuration.
<interface>
<name>Ethernet0/0</name>
<mtu>1500</mtu>
</interface>
Example 2: Add an interface named “Ethernet0/0” to the running configuration, replacing

any previous interface with that name.
<interface xc:operation="replace">
<name>Ethernet0/0</name>
<mtu>1500</mtu>
<address>
<name>192.0.2.4</name>

<prefix-length>24</prefix-length>
</address>
</interface>
NOTE:
The default import modes have the following equivalent attributes on the
root object of the configuration tree:
 Standard Import is always a merge operation.
 Quick Import is a create operation.
 Full Import is a replace operation.
Related Using the Import/Export Feature for XML Configuration Files on page 674
Documentation
 Example: Using the Configuration XML File Import/Export Feature to Add Multiple

Users on page 688
Example: Using the Configuration XML File Import/Export Feature to Add Multiple
Users
This example shows how to use the configuration XML file import/export feature. The
example is illustrative. There are additional ways to use export files.
Assume you have just added a new device to the network, and you want to add your
2,000 users to the system. Instead of adding them one at a time in the admin console,
you want to perform a mass import You can export the user accounts, extract the relevant
XML that defines users, replicate each element as needed, and then import them. In this
situation, your configuration should include the option to force the users to change their
passwords the first time they log in to the system.
In this procedure, you only see examples for User 1, User 2, and User 2000. All other users
are included in your import file. You set the passwords to numbered instances of the
word password, such as password1, password2, and so on. All users in this example are
assigned to the same auth server, although you can specify any combination of auth
servers that are valid on your system.
To add multiple new users:
1. Select Maintenance > Import/Export > Export XML.
2. Follow the instructions to export local user accounts.
3. Save the exported file as users.xml.
4. Open the users.xml file.
5. Copy and paste the User container element repeatedly until you have added the
necessary number of users. Although the example shows only three new users, you
might add hundreds of new users to the file.

6. Update the appropriate data in each User container element as shown in “Example
1” on page 689.
7. Save the users.xml file.
8. Select Maintenance > Import/Export > XML Import/Export > Import.
9. Click Browse to locate and select your users.xml file.
10. Click Import.
Example 1
<authentication>
<auth-servers>
<auth-server>
<local>
<users>
<user>
<username>user1</username>
<fullname>User1</fullname>
<password-cleartext>password1
</password-cleartext>
<change-password-at-signin>true
</change-password-at-signin>
</user>
<user>
<username>user2</username>
<fullname>User2</fullname>
<password-cleartext>password2
</password-cleartext>
<change-password-at-signin>true
</change-password-at-signin>
</user>
<name>System Local</name>
</auth-server>
</auth-servers>
</authentication>
</configuration>
Related Guidelines for Modifying Configuration XML Files on page 680

Documentation


Using the Push Configuration Feature
This topic describes the push configuration feature. It includes the following information:
 Push Configuration Overview on page 690

 Guidelines and Limitations on page 690
 Configuring Targets on page 691
 Configuring Push Settings on page 693
 Viewing Configuration Push Results on page 696
Push Configuration Overview

The push configuration feature supports simple configuration management across an
enterprise without requiring you to deploy the systems as a cluster. You push a partial
configuration from the running configuration on the source system to the running
configuration on one or more target systems.
It is not desirable to push the some groups of settings to a running configuration, so the
following groups of settings are not supported:
 Network configurations
 Licenses
 Cluster configurations
 Certificates
 SNMP settings
 Syslog server settings
 Push configuration targets
Guidelines and Limitations

Table 96 on page 691 summarizes the guidelines and limitations for using the push
configuration feature.

Table 96: Push Configuration Guidelines and Limitations
Category Guidelines and Limitations
General The following guidelines and limitations apply:
 You can push a configuration only to systems running the same software version (same build number).
 The source device pushes data over the management port (if configured) or the internal port. The target
device can receive data over the internal or external port.
 You can push to a single target or to multiple targets. For example, if you install several new systems,
you can push a common configuration to set their initial configuration.
 You can push a configuration to up to 8 targets per job. You can run up to 25 push jobs simultaneously.
The maximum number of targets configured by one source at one time is therefore 200.
 When a configuration push job begins on a target, no warning is displayed, and the administrators are
automatically logged out to avoid potential conflicts.
 When the job has completed on a target, the target device restarts its services. Brief interrupts might
occur while the service restarts. We recommend you push to targets when they are idle or when you can
accommodate brief interruptions.
 Immediately after pushing an Active Directory authentication server configuration, you must edit the
configuration to change the Computer Object name. Unexpected problems might arise if two systems
join an Active Directory domain using the same Computer Object name.
Licenses The push configuration job does not push licenses or licensing settings.
Clusters You can push a configuration to target that is a member of a cluster, as long as the target is not a member
of the same cluster as the source.
Configuring Targets
To configure push configuration targets:
1. Select Maintenance > Push Config > Targets to display the target list and source options
configuration page.
2. Complete the configuration for the source options as described in Table 97 on page 692.
3. Click New Target to display the configuration page for targets.

Figure 190: Push Configuration Target List and Source Device Settings
Page – Pulse Policy Secure
Figure 191: Push Configuration Target List and Source Device Settings
Page – Pulse Connect Secure
Table 97: Push Configuration Target Source Device Configuration Options
Settings Guidelines
Allow this Select this option to allow the system to accept configuration pushed from another system. This option
system to be a must be selected on targets, but does not have to be selected on the source system.
target
Validate target Select this option on the source system if you want the source system to validate the target system server
server certificate certificate before pushing the configuration.
Save Changes Click this button if you have changed the source device configuration options described above.
Delete Select a row in the table and click Delete to remove the target from the list. When you delete a target, the
push configuration results associated with that target are also deleted.

Figure 192: Push Configuration Targets Configuration Page
Table 98: Push Configuration Targets Configuration Guidelines
Settings Guidelines
Name Specify a name to identify the target within the system. Target names and target sign-in URLs cannot be
edited after they have been saved.
Sign-in URL Specify the URL for the administrator sign-in page. Sign-in URLs cannot be edited after they have been
saved.
Admin Username Specify an account on the target system that the push configuration job can use to sign-in and make
changes to the configuration. The job can make wide-ranging configuration changes, so the user must
have full administrative privileges. In other words, the user must belong to the .Administrators role.
Password Specify the corresponding password.
Auth. Realm Specify the administrator authentication realm on the target system. The access management framework
must be configured so that the job process (run as the username specified above) can sign in without
any human interaction. For example, you cannot have dynamic credentials or multiple roles that are not
merged, as these both require manual interaction.
We recommend that you create an administrator account on each target that can be used exclusively
for push configuration. Configure the administrator realm so that the realm policy and role mapping rules
do not result in prompts requiring human interaction. For example, the user must be able to log in with
static password authentication or two-factor tokens that do not use challenge-response type
authentication. For example, certificates, Soft ID, and Defender Authentication are not supported.
Configuring Push Settings

To configure the settings to be pushed:
1. Select Maintenance > Push Config > Push Configuration to display the configuration
page.
2. Complete the configuration and push configuration operation as described in


Figure 193: Push Configuration Selected Settings Page
Table 99: Push Configuration Selected Settings and Action Guidelines
Settings Guidelines
Select Settings and Export

Table 99: Push Configuration Selected Settings and Action Guidelines (continued)
Settings Guidelines
What to push Select Selected configuration or Entire configuration.
If you select Selected configuration, the page displays controls to select settings groups.
If you select Entire configuration, all settings from the source system are pushed, except for the
following:
 Network configurations
 Licenses
 Cluster configurations
 Certificates
 SNMP settings
 Syslog server settings
 Push configuration targets
Expand All Click this button to expand the display of all settings groups.
Select All Click this button to select all settings for all groups.
Settings
System Expand this group and select settings found under the System menu.
NOTE: You cannot push host-specific network settings to a target. If you want to copy these settings
to another system, use the configuration XML file import/export feature.
Sign-in Expand this group and select settings found under the Sign-in menu.
Endpoint Security Expand this group and select settings found under the Endpoint Security menu.
NOTE: ESAP and JEDI packages are encrypted when exported.
Authentication Realms Expand this group and select authentication realm settings, including user realms and MAC address
authentication realms.
Roles Expand this group and select settings found under the Roles menu.
Resource Profiles Pulse Connect Secure only.
Expand this group and select settings resource profiles settings.
Resource Policies Expand this group and select settings resource policies settings.
Junos Pulse Expand this group and select settings found under the Junos Pulse menu.
Local User Accounts Expand this group and select local authentication server settings.
Infranet Enforcer Pulse Policy Secure only.
Expand this group and select settings found under the Infranet Enforcer menu.

Table 99: Push Configuration Selected Settings and Action Guidelines (continued)
Settings Guidelines
Network Access Pulse Policy Secure only.
Expand this group and select settings found under the Network Access menu.
Maintenance Expand this group and select settings found under the Maintenance menu.
Push Configuration
Available Targets / Use the Add and Remove buttons to select the targets.
Selected Targets
Overwrite duplicate Select this option to overwrite settings on the target that have the same name as settings being
settings pushed.
If you do not select this option, the push configuration job copies only configuration objects that
have names different from the configuration objects on the target.
Push Configuration Click this button to push the selected configuration data to the specified targets.
You cannot halt the process or change the target until the entire push configuration job is complete.
If errors occur during the push process, the job stops, and the configuration for the target is rolled
back to the previous state. Error messages are displayed on the Results page.
If you have specified multiple targets and a push configuration job to a target fails, the job continues
to the next target until specified targets are updated (or fail). The results page displays the status
and any problems encountered during the process.
Viewing Configuration Push Results

Purpose The source system saves and displays up to 25 push configuration results in the Results
tab. When the results table reaches 25 entries, the system removes the oldest result data
when the next push configuration job is started.
Action To view push configuration job results:
1. Select Maintenance > Push Config > Results to display the results page.
Figure 190 on page 692 shows the results page for Pulse Policy Secure. The page for
Pulse Connect Secure is similar.
2. Examine the results to verify success or learn the reasons the push job failed.
Click the job name to display additional information about the job.
Select a job and click Delete to remove it from the results page.

Figure 194: Push Configuration Results Page
Related Configuration File Administration Overview on page 657

Documentation



CHAPTER 19
System Maintenance
This chapter describes how to upgrade the system, download client installers, and other
maintenance tasks. It includes the following information:
 Using the System Maintenance Pages on page 699

 Configuring System Maintenance Options on page 700
 Upgrading the System Software on page 703
 Restarting, Rebooting, and Shutting Down the System on page 711
 Testing Network Connectivity on page 712
Using the System Maintenance Pages
You can use the System > Maintenance pages to perform the following tasks:
 Enable system maintenance options, such as software version monitoring and disk
clean-up.
 Upgrade, downgrade, or rollback the system software.
 Download client installer files so that you can distribute them in out-of-band methods
to end users.
 Test network connectivity between the system and servers that have been configured
to be used with it.
 Display hardware status.
Related Configuring System Maintenance Options on page 700

Documentation

 Restarting, Rebooting, and Shutting Down the System on page 711
 Testing Network Connectivity on page 712
 Displaying Hardware Status on page 735

Configuring System Maintenance Options
You can use the maintenance options page to enable various system maintenance
features.
To enable various system maintenance features:
1. Select Maintenance > System > Options to display the maintenance options page.
Figure 195 on page 701 shows the system maintenance options for Pulse Policy
Secure. The system maintenance options page for Pulse Connect Secure is similar.
2. Select options as described in Table 100 on page 701.

Chapter 19: System Maintenance
Figure 195: System Maintenance Options Configuration Page
Table 100: System Maintenance Options Configuration Guidelines

Options Guidelines
Automatic version Automatically notifies you about critical software patches and updates. If you enable this option, the
monitoring system reports the following data: your company name, an MD5 hash of your license settings, and
information describing the current software version. We strongly recommend that you enable this
service.
Gzip compression Pulse Connect Secure only. Use gzip compression to reduce the amount of data sent to browsers that
support HTTP compression. This can result in faster page downloads for some users.
NOTE: Gzip compression is not supported on the MAG Series Pulse Secure
Gateways.

Table 100: System Maintenance Options Configuration Guidelines (continued)
Options Guidelines
Kernel Watchdog Enables the kernel watchdog that automatically restarts the system under kernel deadlock or when
kernel runs low on some key resources.
NOTE: Enable the kernel watchdog only when instructed by Pulse Secure Technical Support.
File System Enables the system to automatically clean up the file system when disk utilization reaches 90%.
Auto-clean
NOTE: The clean-up operation deletes files that might be relevant in debugging—for example, debug
logs, core files, and snapshots might be deleted.
Web installation and Pulse Policy Secure only. After you deploy OAC software to endpoints, software updates occur
automatic upgrade automatically. A client can receive updates from the server. If you upgrade the OAC software on your
of Odyssey Access server, updated software components are pushed to a client the next time it connects.
Clients
Web installation and After you deploy Junos Pulse client software to endpoints, software updates occur automatically. A
automatic upgrade Pulse client can receive updates from the server. If you upgrade the Pulse software on your Pulse server,
of Junos Pulse updated software components are pushed to a client the next time it connects.
Clients
A bound endpoint receives connection set options and connections from its binding server, but it can
have its Pulse client software upgraded from any Pulse server that has the automatic upgrade option
enabled. During a client software upgrade the client loses connectivity temporarily.
Hardware Use hardware acceleration to offload cryptographic operations from the main CPU. This can significantly
acceleration improve performance.
Java instrumentation Pulse Connect Secure only. Caches the Java instrumentation to improve the performance of Java
caching applications.
Show Auto-allow Pulse Connect Secure only. The auto-allow option provides the means to automatically add bookmarks
for a given role to an access control policy, for example, Web bookmarks with auto-allow set are added
to the Web access control policy. You only use this feature if you also use Resource Policies. We
recommend that you use Resource Profiles instead.
End-user Select one of the following options:

Localization
 Automatic (based on browser settings)
 English (U.S.)
 Chinese (Simplified)
 Chinese (Traditional)
 French
 German
 Japanese
 Korean
 Spanish
External User Records Management

Table 100: System Maintenance Options Configuration Guidelines (continued)
Options Guidelines
Persistent user Specify the maximum number of user records.

records limit
This feature is useful when system performance is affected due to a large number of user records. We
highly recommend you consult Juniper Networks Technical Support prior to using this feature. Deleting
a user record removes all persistent cookies, SSO information, and other resources for that user. It does
not remove the user record from the external or internal authentication server. If you delete a user record
and that user logs back in to the authentication server, new user records are created. Records are not
removed if that user is currently logged in.
Number of records to Specify a number. Older records are removed first. A user record is not deleted if that user is currently
delete when the limit logged in.
is exceeded
Delete records now Check whether the persistent user records limit has been exceeded. If it is, delete the number of user
records specified in the option above.
Automatic deletion Check whether the persistent user records limit will be exceeded whenever a new user record is about
of user records during to be created. If true, delete the records prior to creating the user new record.
new user logins
Related Using the System Maintenance Pages on page 699

Documentation

Upgrading the System Software
This topic describes how to upgrade, downgrade, and rollback the system software. It
 Downloading a Software Package on page 703

 Uploading a Software Package on page 704
 Downgrading the System Software on page 707
 Rolling Back the System Software on page 707
Downloading a Software Package

To download a software package:
1. Go to http://www.juniper.net/support/downloads/ and browse to the software

download page for your product.
2. When prompted, log in with your Pulse Secure customer username and password.
3. Accept the license agreement.
4. When prompted, save the software package to your local host.

Uploading a Software Package

You can upload a software package to the system without immediately initiating the
upgrade process. This is known as staging the upgrade. You can stage one package.
Uploading a second package overwrites the previous staging.
To upload a software package:
1. Select Maintenance > System > Upgrade/Downgrade to display the system software
maintenance page.
Figure 196 on page 705 shows the system software maintenance page for Pulse Policy
Secure. The system software maintenance page for Pulse Connect Secure is similar.
2. Under Managed Staged Service Package, select Upload new package into staging area
and use the Browse button to locate and select the service package file.
3. Click Submit to upload the file.
The Upload Status window shows the progress of the upload operation.

Figure 196: Software Upgrade Page
NOTE: If you have enabled logging for Administrator changes (System >
Log/Monitoring > Admin Access > Settings page), a log is written to the
Admin Access logs page.
Upgrading the System Software

Installing a service package can take several minutes and requires the system to reboot.
Because existing system data is backed up during this process, you can decrease
installation time by clearing your system log before trying to install a service package.

To upgrade the operating system:
maintenance page.
Figure 196 on page 705 shows the system software maintenance page.
2. Under Install Service Package, select one of the following options to proceed:
 From File—Use the Browse button to locate and select the service package file.
 From Staged Package—Select the service package file that was previously uploaded.
NOTE: Do not select the Deletes option when you are upgrading
software. The Deletes option is available to support downgrading
software.
3. Click Install.
The system displays the Service Package Installation Status page, which provides a
summary of the integrity checks and compatibility checks and other status indicators.
Figure 197 on page 706 shows the software upgrade status page.
Figure 197: Software Upgrade Status Page
Admin Access logs page. If you have enabled logging for System Status
(System > Log/Monitoring > Events > Settings page), logs are written to the
Events logs page.

Downgrading the System Software

If necessary, you can downgrade to an earlier version of the system software. When you
downgrade, you must clear the system and configuration data to avoid unexpected
behavior that can occur when the system has data that relates to the newer software.
If you downgrade the system, you must reestablish network connectivity before you can
reconfigure it.
To downgrade the operating system:
maintenance page.
Figure 196 on page 705 shows the system software maintenance page.
2. Under Install Service Package, select one of the following options to proceed:
 From File—Use the Browse button to locate and select the service package file.
 From Staged Package—Select a service package file that was previously uploaded.
3. Select the Deletes option to delete all system and user configuration data before
installing the service package, restoring the member to an unconfigured state.
4. Click Install.
Rolling Back the System Software

If necessary, you can rollback the system to the previous software version and
configuration state. The system is rebooted and unavailable for a few minutes when you
rollback.
To rollback the operating system:
1. Select Maintenance > System > Platform to display the system maintenance platform
page.
Figure 198 on page 708 shows the system maintenance platform page for Pulse
Policy Secure. The system maintenance platform page for Pulse Connect Secure is
similar.
2. Click Rollback.

Figure 198: System Maintenance Platform Page
NOTE: The rollback option appears only if you have previously upgraded the
system software.
NOTE: If you have enabled logging for System Status (System >
Log/Monitoring > Events > Settings page), logs are written to the Events logs
page.

Documentation

Downloading Client Installer Files
You can use the system maintenance client installers page to download client installer
files. The downloadable files include .exe and .msi files for use installing clients on
Windows platforms, and .dmg files for installing clients on Macintosh platforms.
To download client installer files:
1. Select Maintenance > System > Installers to display the client installer files page.

Figure 199 on page 709 shows the client installer files for Pulse Policy Secure.
Figure 200 on page 710 shows the client installer files for Pulse Connect Secure.
2. Click Download to download the file to your local host.
Figure 199: System Maintenance Client Installers Page – Pulse Policy Secure

Figure 200: System Maintenance Client Installers Page – Pulse Connect Secure

Documentation


Restarting, Rebooting, and Shutting Down the System
You can use the admin console to perform restart, reboot, and shut down operations.
The following items explain these terms:
 Restart—Kills all processes and restarts the system. The system is available again after
a few minutes.
 Reboot—Power cycles and reboots the system. The system is available again after a
few minutes.
 Shut Down—Shuts down the system. The system is not available again until the physical
power button on the physical device is used to restart the system.
NOTE: The restart, reboot, and shutdown operations are applied to all enabled
members of a cluster. If you do not want to apply the operations to all
members of the cluster, use the System > Clustering > Status page to disable
members; then perform the restart, reboot, or shut down operation.
To restart, reboot, or shut down the system:
page.
Figure 201 on page 712 shows the system maintenance platform page for Pulse Policy
Secure. The system maintenance platform page for Pulse Connect Secure is similar.
2. Click the desired node operation:
 Restart Services
 Reboot
 Shut Down

Admin Access logs page. If you have enabled logging for System Status
(System > Log/Monitoring > Events > Settings page), logs are written to the
Events logs page.

Documentation

Testing Network Connectivity
You can use the admin console to test network connectivity to all the servers with which
the system is configured to communicate, for example network services or AAA servers.
To test network connectivity:
page.

Figure 202 on page 713 shows the system maintenance platform page for Pulse
Policy Secure. The system maintenance platform page for Pulse Connect Secure is
similar.
2. Click Test Connectivity.
Server connectivity results are highlighted in the figure.

Documentation



CHAPTER 20
Logging and Monitoring
This chapter describes local logging features, SNMP, and syslog. It includes the following
information:
 Logging Overview on page 715

 Configuring Events to Log on page 716
 Configuring SNMP on page 719
 Configuring Syslog on page 728
 Enabling Client-Side Logging on page 731
 Displaying System Status on page 731
 Displaying Hardware Status on page 735
 Displaying Active Users on page 738
 Displaying System Logs on page 739
 Using Log Filters on page 744
 Displaying User Access Statistics on page 748
Logging Overview
The system generates event logs related to system performance, administrator actions,
network communications, access management framework results, user sessions, and
so forth. The system supports the following log collection methods:
 Local log collector and log viewer.
 Reporting to syslog servers.
 Reporting to SNMP servers.
Table 101 on page 715 describes the event log severity levels.
Table 101: Event Log Severity Levels
Severity Level Description
Critical (level 10) The system cannot serve user and administrator requests or loses functionality to a
majority of subsystems.

Table 101: Event Log Severity Levels (continued)
Severity Level Description
Major (levels 8-9) The system loses functionality in one or more subsystems, but users can still access the
system for other access mechanisms.
Minor (levels 5-7) The system encounters an error that does not correspond to a major failure in a
subsystem. Minor events generally correspond to individual request failures.
Info (levels 1-4) The system writes an informational event to the log when a user makes a request or
when an administrator makes a modification.
In addition to managing system logs, you can use the admin console to configure collection
of client-side logs, including Host Checker logs.
Related Displaying System Logs on page 739

Documentation

 Configuring SNMP on page 719
 Enabling Client-Side Logging on page 731
 Configuring Archiving for System Logs, Configuration Files, and Snapshots on page 658
Configuring Events to Log
To configure log event categories:
1. Select System > Log/Monitoring.
2. Click the Settings tab to display the configuration page shown in Figure 203 on page 717.
NOTE: To configure log events for each local log category, you must perform
this procedure on each local log tab: Events, User Access, Admin Access, and
Sensors.

Chapter 20: Logging and Monitoring
Figure 203: Log Events Settings Configuration Page
Table 102: Log Events Settings
Settings Guidelines
Maximum Log Size

Max Log Size Specify the maximum size of the local log. The default is 200 MB. The maximum is 500 MB. The
default is a good choice for logs formatted with the Standard format. If you use a more verbose
format, such as WELF, specify a larger value.
When the local log reaches the maximum log size, the current data is rolled over to a backup log
file. A new, empty, file is then created for all subsequent (new) log messages. The log viewer
displays the most recent 5000 log messages (the display limit). If the current log file contains
fewer than 5000 log messages, older log messages from the backup log file can be displayed, up
to a total of 5000 log messages. This makes the log files appear as one, even though they are
stored separately.
When you save the log messages or use the FTP archive function, the backup log file is appended
to the current log file and is then downloaded as one log file. If the log files are not archived or saved
by the time they are rolled over again, the oldest log messages (saved in the backup log file) are
lost.
Archiving Click the Archiving link to display the configuration page for Archiving jobs, including log archiving.

Table 102: Log Events Settings (continued)
Settings Guidelines
Select Events to Log – Events Tab

Connection Requests Log events related to connection requests.
System Status Log events related to changes in system status.
System Errors Log events related to system errors.
Enforcer Events Log events related to Infranet Enforcer communication.
Enforcer Command Trace Log events related to Infranet Enforcer command execution.
Statistics Log user access statistics reported on the System > Log/Monitoring > Statistics tab. If you unselect
the Statistics option, the statistics are not written to the log file, but are still reported on the statistics
page.
Performance Log events related to performance, such as CPU utilization.
License Protocol Events Log events related to licensing.
IF-MAP Server Trace Log events related to IF-MAP.
RADIUS Statistics Logs events related to RADIUS.
Select Events to Log – User Access Tab

Login/logout Log events related to sign in and sign out.
User Settings Log events related to changes to user settings.
Client Certificate Log events related to certificate security.
Enforcer Deny Messages Log events related to Infranet Enforcer.
IF-MAP Client User Log events related to IF-MAP.

Messages
RADIUS Accounting Log events related to RADIUS.

Messages
Endpoint Heartbeat Log events related to endpoint heartbeat messages.

Messages
Pulse Client Messages Log events related to Pulse clients.
Select Events to Log – Admin Access Tab

Administrator changes Log events related to configuration changes.
Administrator logins Log events related to administrator access.

Table 102: Log Events Settings (continued)
Settings Guidelines
License changes Log events related to licensing.
Select Events to Log – Sensor Tab

None If you have configured communication with an IDP sensor for coordinated threat control,
communication between the network nodes is logged. There is no way to select less than the whole
set of sensor event logs.

Documentation
 Displaying System Logs on page 739

Configuring SNMP
If you prefer, you can use a third-party SNMP manager, such as HP OpenView, to monitor
system health. The system supports SNMP v2c and SNMPv3.
To configure the SNMP agent:
2. Click the SNMP tab to display the SNMP configuration page.

Figure 204: SNMP Configuration Page – Pulse Policy Secure

Figure 205: SNMP Configuration Page – Pulse Connect Secure
Table 103: SNMP Configuration Settings

Settings Guidelines
MIB File Use the Pulse Secure MIB file link to download the device management information base MIB)
file. You add this file to your SNMP manager configuration.
SNMP Version Select your SNMP server version:
 v2c
 v3
Agent Properties
SNMP Queries Select to support SNMP queries.

Table 103: SNMP Configuration Settings (continued)
Settings Guidelines
SNMP Traps Select to send SNMP traps.
System Name Specify a system name.
System Location Specify a location.
System Contact Specify a system contact.
Community String  Required only for SNMPv2c.

 To query the system, your network management station must send it the community string.
 To stop the SNMP system, clear the community field.
SNMPv3 Configuration
Username Specify the SNMPv3 username. The User-Based Security Model (USM) is the default Security
Module for SNMPv3. The system supports only one user at a time to be registered with an SNMP
engine. Editing the SNMPv3 user attributes overwrite any already registered SNMPv3 user. The
SNMPv3 user must have read-only access on all MIBs supported by the system. SNMPv3 user
configuration attributes can also be used for SNMP traps.
Security Level Selection Auth Protocol Auth Password Priv Protocol Priv Password
No Auth, NoPriv — — — —
Auth, NoPriv Select MD5 Enter an — —

(HMAC-MD5-96) authentication
or SHA password. The
(HMAC-SHA-96). password can
contain any ASCII
characters and
must be at least
8 characters in
length.
Auth, Priv Select MD5 Enter an Select either Enter a privacy

(HMAC-MD5-96) authentication CBC-DES or password. The
or SHA password. The CFB-AES-128. password can
(HMAC-SHA-96). password can contain any ASCII
contain any ASCII characters and
characters and must be at least
must be at least 8 characters in
8 characters in length.
length.
Trap Thresholds NOTE: Setting a threshold value to 0 disables that respective trap.
Check Frequency Specify the frequency in seconds for sending traps. The default is 180 seconds.
Log Capacity Specify the percent of log space used. The default is 90%.
Users Specify the percent of user capacity used. The default is 100%.

Table 103: SNMP Configuration Settings (continued)
Settings Guidelines
Physical Memory Specify the percent of physical memory used. The default is 0 (not reported).
Swap Memory (Virtual Specify the percent of swap memory used. The default is 0 (not reported).
Memory)
NOTE: We recommend you monitor swap memory to alert you to potential memory issues. The
threshold for traps for physical memory usage might be reached even if the system is not experiencing
any difficulties.
Disk Specify the percent of disk utilization. The default is 80%.
CPU Specify the percent of CPU utilization. The default is 0 (not reported).
Meeting Users Specify the percent of meeting users. The default is 100%.
Optional Traps
Critical Log Events Send traps when the system logs critical events.
Major Log Events Send traps when the system logs major events.
Save SNMP Settings? Click Save Changes to update the SNMP agent configuration. The page is refreshed and displays
the SNMP engine ID. If the configuration is changed to move from SNMP v2c to SNMP v3, the system
generates and displays two engine IDs.
SNMP Servers
Hostname / IP address Specify the hostname or IP address for the SNMP servers to which the system will send any traps
it generates.
Port Specify the port for the SNMP server. Typically, SNMP uses port 162.
Community Specify the community string (if necessary).
Keep the following configuration tips in mind when you configure your SNMP manager
to listen for this SNMP agent:
 Add the Pulse Secure MIB file to the SNMP manager configuration.
 If using SNMPv2c, the community string configuration for the SNMP manager and
SNMP agent must match.
 If using SNMPv3, the SNMPv3 user configuration for the SNMP manager and the SNMP
agent must match.
 If using SNMPv3, you must specify the Authoritative Engine ID for SNMPv3 traps that
was generated when you saved the SNMP agent configuration.
Table 104 on page 724 is a reference of MIB objects for Pulse Secure IVE systems. Some
objects apply only to Pulse Connect Secure.

Table 104: MIB Objects
Object Description
logFullPercent Returns the percentage of available file size filled by the current log as a parameter of
the logNearlyFull trap.
signedInWebUsers Returns the number of users signed in through a Web browser.
signedInMailUsers Returns the number of users signed in to the e-mail client.
blockedIP Returns the IP address—blocked due to consecutive failed login attempts—sent by the
iveToomanyFailedLoginAttempts trap. The system adds the blocked IP address to the
blockedIPList table.
authServerName Returns the name of an external authentication server sent by the

externalAuthServerUnreachable trap.
productName Returns the licensed product name.
productVersion Returns the software version.
fileName Returns the file name sent by the archiveFileTransferFailed trap.
meetingUserCount Returns the number of concurrent meeting users sent by the meetingUserLimit trap.
iveCpuUtil Returns the percentage of CPU used during the interval between two SNMP polls. This
value is calculated by dividing the amount of CPU used by the amount of CPU available
during the current and previous SNMP polls. If no previous poll is available, the
calculation is based on the interval between the current poll and system boot.
iveMemoryUtil Returns the percentage of memory utilized by the system at the time of an SNMP poll.
The system calculates this value by dividing the number of used memory pages by the
number of available memory pages.
iveConcurrentUsers Returns the total number of users logged in.
clusterConcurrentUsers Returns the total number of users logged in for the cluster.
iveTotalHits Returns the total number of hits to the system since last reboot. Includes total values
from iveFileHits, iveAppletHits, meetingHits, and iveWebHits.
iveFileHits Returns the total number of file hits to the system since last reboot.Incremented by
the Web server with each GET/POST corresponding to a file browser request.
iveWebHits Returns the total number of hits by means of the Web interface since last reboot.
Incremented by the Web server for each http request received by the system, excluding
file hits, applet hits, and meeting hits.
iveAppletHits Returns the total number of applet hits to the system since last reboot.Incremented
by the Web server for each GET request for a Java applet.
ivetermHits Returns the total number of terminal hits to the system since last reboot.

Table 104: MIB Objects (continued)
Object Description
logName Returns the name of the log (admin/user/event) for the logNearlyFull and iveLogFull
traps.
iveSwapUtil Returns the percentage of swap memory pages used by the system at the time of an
SNMP poll. The system calculates this value by dividing the number of swap memory
pages used, by the number of available swap memory pages.
diskFullPercent Returns the percentage of disk space used in the system for the iveDiskNearlyFull trap.
The system calculates this value by dividing the number of used disk space blocks by
the number of total disk space blocks.
blockedIPList Returns a table with the 10 most recently blocked IP addresses. The blockedIP MIB
adds blocked IP addresses to this table
ipEntry An entry in the blockedListIP table containing a blocked IP address and its index (see
IPEntry).
IPEntry The index (ipIndex) and IP address (ipValue) for an entry in the blockedIPList table.
ipIndex Returns the index for the blockedIPList table.
ipValue A blocked IP address entry in the blockedIPList table.
logID Returns the unique ID of the log message sent by the logMessageTrap trap.
logType Returns a string sent by the logMessageTrap trap stating whether a log message is
major or critical.
logDescription Returns a string sent by the logMessageTrap trap stating whether a log message is
major or critical.
ivsName Returns the name of a virtual system.
ocspResponderURL Returns the name of an OCSP responder.
fanDescription Returns the status of the system fans.
psDescription Returns the status of the system power supplies.
raidDescription Returns the status of the system RAID device.
iveLogNearlyFull The log file (system, user access, or administrator access) specified by the logName
parameter is nearly full. When this trap is sent, the logFullPercent (%of log file full)
parameter is also sent. You can configure this trap to be sent at any percentage. To
disable this trap, set the Log Capacity trap threshold to 0%. The trap’s default value
is 90%.
NOTE: When SNMP traps are enabled, the iveLogNearlyFull and iveLogFull traps are
sent when the log files are 90% full and 100% full respectively, even if the threshold
is set to 0 (disabled).

Object Description
iveLogFull The log file (system, user access, or administrator access) specified by the logName
parameter is completely full.
NOTE: When SNMP traps are enabled, the iveLogNearlyFull and iveLogFull traps are
sent when the log files are 90% full and 100% full respectively, even if the threshold
is set to 0 (disabled).
iveMaxConcurrentUsersSignedIn Maximum number or allowed concurrent users are currently signed in. You can configure
this trap to be sent at any percentage. To disable this trap, set the Users trap threshold
to 0%. The trap’s default value is 100%.
iveTooManyFailedLoginAttempts A user with a specific IP address has too many failed sign-in attempts. Triggered when
a user fails to authenticate according to the settings for the Lockout options on the
Security Options tab.
When the system triggers this trap, the system also triggers the blockedIP (source IP
of login attempts) parameter.
externalAuthServerUnreachable An external authentication server is not responding to authentication requests.
When the system sends this trap, it also sends the authServerName (name of
unreachable server) parameter.
iveStart The system has just been turned on.
iveShutdown The system has just been shut down.
iveReboot The system has just been rebooted.
archiveServerUnreachable The system is unable to reach the configured archive server.
archiveServerLoginFailed The system is unable to log into the configured archive server.
archiveFileTransferFailed The system is unable to successfully transfer files to the configured archive server.
When the system sends this trap, it also sends the fileName parameter.
iveRestart Supplies notification that the system has restarted according to the administrator’s
instruction.
iveDiskNearlyFull Supplies notification that the system disk drive is nearly full. When the system sends
this trap, it also sends the diskFullPercent parameter. You can configure this trap to be
sent at any percentage. To disable this trap, set the Disk trap threshold to 0%. This
trap’s default value is 80%.
iveDiskFull Supplies notification that the system disk drive is full.
logMessageTrap The trap generated from a log message. When the system sends this trap, it also sends
the logID, logType, and logDescription parameters.

Object Description
memUtilNotify Supplies notification that the system has met the configured threshold for memory
utilization. To disable this trap, set the Physical Memory trap threshold to 0. The
threshold is 0%, by default.
cpuUtilNotify Supplies notification that the system has met the configured threshold for CPU
utilization. To disable this trap, set the CPU trap threshold to 0. The threshold is 0%,
by default.
swapUtilNotify Supplies notification that the system has met the configured threshold for swap file
memory utilization. To disable this trap, set the Swap Memory trap threshold to 0. The
threshold is 0%, by default.
iveFanNotify Supplies notification that the status of the fans has changed.
ivePowerSupplyNotify Supplies notification that the status of the power supplies has changed.
iveRaidNotify Supplies notification that the status of the RAID device has changed.
iveNetExternalInterfaceDownTrap Supplies the type of event that brought down the external interface. The nicEvent
(nicEvent) parameter can contain values of “external” for an external event and “admin” for an
administrative action.
iveNetInternalInterfaceDownTrap Supplies the type of event that brought down the internal interface. The nicEvent
iveClusterDisableNodeTrap Supplies the name of the cluster that contains disabled nodes, as well as a string
(clusterName,nodeList) containing the names of all disabled nodes. Node names are separated by white space
in the string.
iveClusterChangedVIPTrap(vipType, Supplies the status of a virtual IP for the cluster. The vipType indicates whether the
currentVIP, newVIP) changed VIP was external or internal. The currentVIP contains the VIP prior to the
change, and newVIP contains the VIP after the change.
iveNetManagementInterfaceDownTrap Supplies the type of event that brought down the management port. The nicEvent
iveClusterDelete(nodeName) Supplies the name of the node on which the cluster delete event was initiated.

Documentation


Configuring Syslog
If desired, you can configure the system to send logs to a syslog server.
To configure reporting to a syslog server:
2. Click the Settings tab to display the configuration page.
NOTE: To enable syslog reporting for each local log category, you must
perform this procedure on each local log tab: Events, User Access, Admin
Access, and Sensors.

Figure 206: Syslog Server Configuration Page – Pulse Policy Secure

Figure 207: Syslog Server Configuration Page – Pulse Connect Secure
Table 105: Syslog Server Configuration Guidelines
Settings Guidelines
Server name/IP Specify the fully qualified domain name or IP address for the syslog server.
Facility Select a syslog server facility level (LOCAL0-LOCAL7).
Your syslog server must accept messages with the following settings: facility = LOG_USER and
level = LOG_INFO.
Filter Select a filter format. Any custom filter format and the following predefined filter formats are
available:
 Standard (default)—This log filter format logs the date, time, node, source IP address, user,
realm, event ID, and message.
 WELF—This customized WebTrends Enhanced Log Format (WELF) filter combines the standard
WELF format with information about the system realms, roles, and messages.
 WELF-SRC-2.0-Access Report—This filter adds access queries to the customized WELF filter.
You can easily use this filter with NetIQ’s SRC to generate reports on user access methods.

Documentation


Enabling Client-Side Logging
Client-side logging is not enabled by default. If necessary, you can enable client-side
logging when Host Checker is run.
To enable client-side logging:
2. Click the Client Logs tab to display the configuration page shown in
3. Select the Host Checker option to enable client-side logging when Host Checker is run
on the endpoint.
Figure 208: Client Logs Configuration Page

Documentation

Displaying System Status
The System Status page is a dashboard of system version information, system capacity
utilization, uptime, and summary user information. The System Status page is the “home”
page that is displayed when you log into the admin console as an administrator. To
navigate to the System Status page from other admin console pages, select System >
Status.
Figure 209 on page 732 shows the System Status page for Pulse Policy Secure. The
table that follows describes the numbered figure callouts.

Figure 209: System Status Page – Pulse Policy Secure

Figure 210: System Status Page – Pulse Connect Secure
Callout Description
1 Click the Critical Events link to display a new window with a table of the last 10 critical system events.

Callout Description
2 Click the Page Settings link to display a new window with the System Status Settings page shown in
3 Click the System Version Download Package link to download the software version running on the system. You
might do this when you need to synchronize software on another node to the software version running on this
system.
4 Click the System Date and Time Edit link to display the System Date and Time configuration page. See Configuring
the System Date and Time.
5 Click a System Capacity Utilization report Edit link to display a new window with controls to customize the appearance
of the report graphs.
6 Click a System Capacity Utilization report Download link to download graph data in XML format.
7 Click an Enforcer Status link to navigate to its configuration page.
Figure 211 on page 734 shows the System Status Settings configuration page. The settings
Figure 211: System Status Settings Configuration Page

You can use this page to select the reports displayed on the System Status page, as well
as data properties, such as the time dimension and refresh rate.
The following reports are available:
 Concurrent Users—Shows a count of users signed into the system. In clustered

environments, the graph includes two lines. The first line displays the number of local
users signed into the node selected from the list, and the second line displays the
number of concurrent users signed into the entire cluster.
 Hits per Second—Shows a count of hits currently being processed by the system. In a
clustered environment, you may select a node from the list to determine which node’s
data is displayed in the graph. The graph includes three lines: total number of hits,
number of Web hits, and number of client/server hits.
 CPU and Memory Usage—Shows the percentage of the CPU and memory being used.
In a clustered environment, you may select a node from the list to determine which
node’s data is displayed in the graph.
 Throughput—Shows the amount of data (in KB) being processed. In a clustered

environment, you may select a node from the list to determine which node’s data is
displayed in the graph. The graph includes four lines: external in, external out, internal
in, and internal out.
 Meetings—Shows the count of concurrent meetings. This option is available only on

Pulse Connect Secure.
 Connections—Shows a count of concurrent SSL connections.
 Rates—Shows the rate of attempted logins, successful logins, and Host Checker
updates.

Documentation

Displaying Hardware Status
You can use the Maintenance > System > Platform page to display the hardware health
status, including information about hard drives, fans, and power supplies.
To display hardware health status:
1. Select Maintenance > System > Platform to display the System Maintenance page.
Figure 212 on page 736 shows the system maintenance page for Pulse Policy Secure.
Figure 213 on page 736 shows the system maintenance page for Pulse Connect
Secure.
2. Review the hardware status information described in Table 106 on page 736.

Figure 212: System Maintenance Page – Pulse Policy Secure
Figure 213: System Maintenance Page – Pulse Connect Secure
Table 106: Hardware Status Information

Hardware Component Status Message
Hard Disk Status Displays a health statement for the device disk drive. See Table 107 on page 737
and Table 108 on page 737 for details.
Fan Status Displays a health statement for the device fan(s).
Power Supply Displays a health statement for the device power supply.

Table 107 on page 737 lists the RAID status and hard drive status for Policy Secure
gateways. Depending on your system, you may or may not see all these possible
statuses.
Table 107: RAID and Hard Drive Status for Policy Secure gateways
RAID Status Drive 1 Drive 2
Hard Disk RAID is operational Active Active
Hard Disk RAID is in single drive mode Missing Active
Hard Disk RAID is in single drive mode Active Missing
Hard Disk RAID has failed Failed Active
Hard Disk RAID has failed Active Failed
Hard Disk RAID is in the process of recovering Active Reconstructing
Hard Disk RAID is in the process of recovering Reconstructing Active
Hard Disk RAID is in the process of recovering Active Verifying
Hard Disk RAID is in the process of recovering Verifying Active
Hard Disk RAID status is unknown Unknown Active
Hard Disk RAID status is unknown Active Unknown
Hard Disk RAID status is unknown Unknown Unknown
Not available n/a n/a
Table 108 on page 737 lists all the possible RAID status and hard drive status for the
MAG-SM360. You can also view the RAID and hard drive status in log messages and in
SNMP.
Table 108: RAID and Hard Drive Status for the MAG-SM360
RAID Status Drive 1 Drive 2
Optimal Optimal Optimal
Degraded Rebuilding Optimal
Degraded Optimal Rebuilding
Degraded Offline Optimal
Degraded Optimal Offline


Documentation

Displaying Active Users
You can use the Active Users page to display the system active users table and to perform
administrative actions pertaining to active sessions.
The system active users table displays all users who have an active session (in contrast
to the users tables that appear on the authentication server configuration pages, which
display session records for active and inactive sessions that were authenticated by the
particular authentication server).
Figure 214 on page 738 shows the Active Users page for Pulse Policy Secure.
Figure 215 on page 738 shows the Active Users page for Pulse Connect Secure.
Figure 214: System Active Users Page – Pulse Policy Secure
Figure 215: System Active Users Page – Pulse Connect Secure
If a user signs in and is placed in a VLAN without an IP address, the table does not display
an IP address under Signed in IP.
If there is a NAT device between the user’s computer and the Infranet Enforcer, the table
displays both the NAT device’s IP address and the endpoint's virtual source IP address
under Signed in IP. For example, if the NAT device’s IP address is 10.64.9.26, and the
endpoint’s virtual source IP address is 192.168.80.128, the following information is
displayed under Signed in IP: 10.64.9.26 (192.168.80.128 behind NAT).

To display the system Active Users page:
1. Select System > Status.
2. Click the Active Users tab to display the system active users page.
3. Use the controls described in Table 109 on page 739 to perform administrative actions
pertaining to active sessions.
Table 109: Active Users Page
Buttons Administrative Actions
Update Refresh records displayed on the page:
 To refresh the page, click Update.

 To display a specific user, enter the username in the Show Users Named box and click Update. If
you do not know the exact username, use the asterisks (*) as a wildcard character.
 To change the table size, enter a number in the Show N users box and click Update.
TIP: To sort the table of currently signed-in users and administrators, click a column header.
Delete Session Select the check box next to the appropriate names and then click Delete Session to immediately
delete the session. The user is signed out by your action.
Delete All Sessions Use this option to immediately delete all sessions. Users are signed out by your action.
NOTE: If you want to sign out administrators, you must choose them individually and use the Delete
Session button.
Refresh Roles Manually evaluate all authentication policies, role-mapping rules, role restrictions, user roles, and
resource policies for all currently signed-in users. Use this button if you make changes to an
authentication policy, role-mapping rules, role restrictions, or resource policies and you want to
immediately refresh the roles of all users.
Disable All Users Sign out all end-users who are currently signed-in and also prevent any other users from signing in.
To allow users to sign in again after you disable all users, click Enable All Users.
Related  Displaying System Status on page 731

Documentation
Displaying System Logs
This topic describes how to display local system logs. It includes the following information:
 Displaying Events Logs on page 740

 Displaying User Access Logs on page 742
 Displaying Admin Access Logs on page 743
 Displaying Sensor Logs on page 743

Displaying Events Logs

The Events logs include system events, such as session timeouts, system errors and
warnings, requests to check server connectivity, and system restart notifications. The
local log viewer displays the most recent 5000 log messages (the display limit).
To display Events logs:
1. Select System Log/Monitoring.
2. Click the Events tab.
3. Click the Log tab to display the log page.
Figure 216 on page 740 shows the log page for Pulse Policy Secure. Figure
217 on page 741 shows the log page for Pulse Connect Secure.
4. Use the features described in Table 110 on page 741 to examine log records or manage
the log collection.
Figure 216: Events Logs Page – Pulse Policy Secure

Figure 217: Events Logs Page – Pulse Connect Secure
Table 110: Log Management Features
Filter Select a filter format. Any custom filter formats and the following predefined filter formats are
available:
 Standard (default)—This log filter format logs the date, time, node, source IP address, user, realm,
event ID, and message.
 WELF-SRC-2.0-Access Report—This filter adds access queries to the customized WELF filter. You
can use this filter with NetIQ’s SRC to generate reports on user access methods.
NOTE: Format filters change only the data displayed (or columns exported), and do not affect the
log data that has been collected.

Table 110: Log Management Features (continued)
Query In the log display, several fields are hyperlinks. The hyperlinks function as dynamic queries on the
local log collection. For example, if you click the log ID, the date, or an IP address or username, the
log viewer queries the log collection for records that match the value you clicked, and redisplays
the log collection. You can apply additional query filters by clicking additional hyperlinked values,
essentially creating a Boolean AND query (for example, date AND IP address).
Use the Reset Query button to clear the query filters and redisplay the unfiltered log collection.
Use the Save Query button to save the dynamic log query as a custom filter. When you click the
Save Query button, the system displays the Filters tab displays with the Query field prepopulated
with the variables you selected from the log.
NOTE: Query filters change only the display (or rows exported), and do not affect the log data that
has been collected.
Save Log As Save the local log collection to a file. We recommend you retain the system generated log name,
which follows a consistent convention: juniper.logtype.nodename.log.
The local log viewer displays the most recent 5000 log messages (the display limit). If the current
log file contains fewer than 5000 log messages, older log messages from the backup log file are
displayed, up to a total of 5000 log messages. This makes the log files appear as one, even though
they are stored separately.
When you save the log messages or use the FTP archive function, the backup log file is appended
to the current log file, and is then downloaded as one log file. If the log files are not archived or saved
by the time they are rolled over again, the oldest log messages (saved in the backup log file) are
lost.
Clear Log Clear the local log and log.old file.
When you clear the local log, events recorded by the syslog server are not affected. Subsequent
events are recorded in a new local log file.
Save All Logs The Save All Logs button appears on the Events, User Access, Admin Access, and Sensors tabs.
When you click Save All Logs, the system generates a file that includes event, user access, admin
access, sensor logs, and XML data for all of the system statistics and graphs shown on the Status
> Overview page. After you click Save All Logs, you are prompted to download a file named
juniperlogs-graphs.tar.gz to your local host.
Clear All Logs The Clear All Logs button appears on the Events, User Access, Admin Access, and Sensors tabs. It
clears event, user access, admin access, sensor logs, and XML data for all of the system statistics
and graphs shown on the Status > Overview page. When you clear the local log, events recorded
by the syslog server are not affected. Subsequent events are recorded in a new local log file.
Displaying User Access Logs

The User Access logs include information about user access, such as the number of
simultaneous users at each one hour interval (logged on the hour) and user sign-ins and
sign-outs. The local log viewer displays the most recent 5000 log messages (the display
limit).

To display User Access logs:
2. Click the User Access tab.
3. Click the Log tab.
the log collection.
Displaying Admin Access Logs

The Admin Access logs include information about administrator actions, such as
administrator changes to user, system, and network settings. It includes a log entry
whenever an administrator signs in, signs out, or changes licenses on the appliance. The
local log viewer displays the most recent 5000 log messages (the display limit).
To display Admin Access logs:
2. Click the Admin Access tab.
the log collection.
Displaying Sensor Logs

The Sensor logs include information related to communication with an IDP sensor if you
have deployed a coordinated threat control solution. The local log viewer displays the
most recent 5000 log messages (the display limit).
To display Sensor logs:
2. Click the Sensor tab.
the log collection.

Documentation

 Configuring Events to Log

Using Log Filters
This topic describes how to use log filters. It includes the following information:
 Reviewing the Configuration of Predefined Log Format Filters on page 744

 Creating a Custom Log Collection Filter on page 745
 Example: Using the Source IP Address Filter on page 747
Reviewing the Configuration of Predefined Log Format Filters

To view the configuration of predefined log format filters:
3. Click the Filter tab to display the log filters page.
Figure 218 on page 744 shows the log filters page for Pulse Policy Secure. Figure
219 on page 745 shows the log filters page for Pulse Connect Secure.
4. Click the hyperlinked name of the filter to display its configuration page. You cannot
edit the predefined filter named Standard, but you may edit the predefined WELF
filters and any other custom filters that appear in the list.
Figure 218: Log Filters Page

Figure 219: Log Filters Page – Pulse Connect Secure
Creating a Custom Log Collection Filter

If desired, you can create custom log collection filters to change the records displayed
or exported. For example, it is common to see administrators use a filter for RADIUS
accounting logs. This filter allows only the accounting log message, and it puts the entire
message in a comma separated list. The order of the filtered message is: Date, Time,
User, Realm, "List of Roles", NAS-ID, Acct-Status, Auth-Type, Attr-Value1, Attr-Value2,
Attr-Value3.
Accounting attribute messages are different from authentication attribute messages in

that the attribute name is not printed in the log message, but a comma is inserted for
every attribute to be logged, even if it is not present.
To create a custom log collection filter:
3. Click the Filter tab.
4. Click New Filter to display the configuration page.

Figure 220: New Filter Page – Pulse Policy Secure
Table 111: Filter Settings
Settings Guidelines
Filter Name Specify a name that is helpful to you and other administrators in understanding usage for your
customer filter.
Make default Make the filter the default on syslog and archiving configuration pages.
Query
Start Date Enter a start date. Click Earliest Date to write all logs from the first available date stored in the log
file.
End Date Enter an end date. Click Latest Date to write all logs up to the last available date stored in the log
file.
Query Use the Filter Variables Dictionary to insert query expressions in the Query box. Enclose the query
value in single quotes.
For example, insert the query expression sourceip=. Then complete the expression by adding the
value ’192.168.0.1’.

Table 111: Filter Settings (continued)
Settings Guidelines
Export Format Select an export format:
 Standard (default)—This log filter format logs the date, time, node, source IP address, user, realm,
event ID, and message.
 Custom—Use the Standard as a template for your custom selection of columns to be included in
exports (when log collections are saved to files).
NOTE: Log query filters change only the data displayed (or rows exported).
Log format filters change only the data displayed (or columns exported).
Use of filters does not affect the log data that has been collected.
Example: Using the Source IP Address Filter

When drilling into logs to verify behavior or troubleshoot an issue with a dual-stack device,
it is helpful to redisplay the log collection filtered on the IP address.
To filter on an IP address:

2. Create the filter:
a. Select User Access and then Filter.
b. Define the filter expression, name the filter, and click Save. In this example, we
create a filter based on source IP address and name it IPv6_Address_Filter:Standard.
3. Use the filter:
a. Select Logs to display the user logs table.
b. Under View by filter, select IPv6_Address_Filter:Standard, as shown in

c. If desired, under Edit Query, edit the value of the sourceip= variable expression to
filter on different source IP addresses.
d. Click Update to apply the filter and redisplay the log collection.
Figure 221: Using IP Address Filters
Related Displaying System Logs on page 739

Documentation

Displaying User Access Statistics
Every hour, the system logs the peak count of Web users in the previous hour. It displays
the hourly counts for the past week on the Statistics page. It writes the report to the
system log once a week.
To display user statistics:
1. In the admin console, select System > Log/Monitoring.
2. Click the Statistics tab to display the page.

3. Scroll the page to view the data.
Figure 222: User Statistics Page – Pulse Policy Secure
Figure 223: User Statistics Page – Pulse Connect Secure

NOTE: Upgrading software clears all statistics. If you configure the system
to log statistics hourly, however, older statistics are still available in the log
file after an upgrade.

Documentation


CHAPTER 21
Troubleshooting Tools
This chapter describes admin console troubleshooting tools. It includes the following
information:
 Using the Admin Console Troubleshooting Tools on page 751

 Using Policy Tracing on page 752
 Using the Debug Log on page 757
 Using the RADIUS Diagnostic Log on page 759
 Using the tcpdump Utility on page 760
 Using Network Troubleshooting Commands on page 762
 Troubleshooting TCP and UDP Port Status on page 765
 Running NSLookup to Test Name Server Connectivity on page 768
 Using the Kerberos Debugging Utility on page 770
 Using Remote Debugging on page 771
Using the Admin Console Troubleshooting Tools
You can use the admin console troubleshooting tools to investigate user access issues
and system issues. The following tools are available through the Maintenance >
Troubleshooting pages:
 Policy tracing—Diagnose user access issues.
 Simulation—Pulse Connect Secure only. Diagnose user access issues.
 Session recording—Pulse Connect Secure only. Work with Pulse Secure Global
Support Center (PSGSC) to diagnose user access issues.
 Debug logs—Work with PSGSC to diagnose system issues.
 RADIUS diagnostic log—Pulse Policy Secure only. Diagnose issues with the Pulse
Policy Secure RADIUS server.
 tcpdump—Sniff packet headers to diagnose networking issues.
 Network troubleshooting commands—Use standard network commands, such as ping,

traceroute, NSlookup, and other commands to diagnose networking issues.
 Kerberos debugging—Diagnose issues with Kerberos communication.

 System snapshots—Work with PSGSC to reproduce and diagnose system issues.
 Remote debugging—Enable PSGSC to access your system directly to help you

diagnose system issues.
If the admin console is unavailable, you can use the serial port console to perform some
troubleshooting operations, such as use ping and traceroute commands, view logs, create
system snapshots, and perform configuration rollbacks and factory resets.
Related Using Policy Tracing on page 752

Documentation
 Using Policy Tracing

 Using the Simulation Utility
 Using the Session Recording Utility
 Using the Debug Log on page 757
 Using the RADIUS Diagnostic Log on page 759
 Using the tcpdump Utility on page 760
 Using Network Troubleshooting Commands on page 762
 Using the Kerberos Debugging Utility on page 770
 Using the Kerberos Debugging Utility
 Using System Snapshots
 Using Remote Debugging on page 771
Using Policy Tracing
It is common to encounter a situation where the system denies a user access to the
network or to resources, and the user logs a trouble ticket. You can use the policy tracing
utility and log to determine whether the system is working as expected and properly
restricting access, or whether the user configuration or policy configuration needs to be
updated to enable access in the user’s case.

Chapter 21: Troubleshooting Tools
To create a policy trace log:
1. Select Troubleshooting > User Sessions > Policy Tracing to display the configuration
page.
Figure 224 on page 753 shows the policy tracing configuration page.
Figure 224: Policy Tracing Configuration Page – Pulse Policy Secure
Table 112: Policy Trace Configuration Guidelines
Settings Guidelines
Record Trace File

Table 112: Policy Trace Configuration Guidelines (continued)
Settings Guidelines
User Specify the username to trace. If you are tracing anonymous access, you can use the asterisks
wildcard character (*) because you might not know the internal username the system assigns to
the next anonymous session.
Source IP Specify the source IP address if you know it. If you are able to provide the source IP address, the
policy trace log can include events that occur before the user ID is entered into the system.
Realm Select the realm to trace.
Events to Log
Pre-Authentication Logs events related to evaluation of realm rules.
Authentication Logs events related to authentication.
Role Mapping Logs events related to role mapping.
IF-MAP Logs events related to IF-MAP queries related to the session.
Sensor Event Policies Logs events related to sensor policies.
Infranet Enforcer Policies Logs events related to Layer 3 Infranet Enforcer policies.
RADIUS Attributes Logs events related to Layer 2 802.1x access.

Policies
Host Enforcer Policies Logs events related to Host Enforcer policies (OAC-only).
UAC Message Trace Logs UAC messages.
3. Click Start Recording.
Figure 225 on page 755 shows the policy tracing page with the recording indicator.

Figure 225: Policy Tracing Page During Recording
4. Initiate the action you want to trace, such as a user sign in.
5. Click View Log to display the policy trace results log.
6. Click Stop Recording when you have enough information.
Figure 226 on page 756 shows the page with policy trace results.

Figure 226: Policy Tracing Results Page
Table 113 on page 756 describes options for managing the policy trace results log file.
Table 113: Post-Trace Options

Control Guidelines
Delete Trace Under Events to Log, click Delete Trace to clear the results displayed on this page.
Update Specify a number of rows to display and click Update to change the number of rows that are
displayed.

Table 113: Post-Trace Options (continued)
Control Guidelines
Save Log As Click this button to save the trace results log to a file. This is useful particularly when you are working
with the Pulse Secure Global Support Center (PSGSC) to troubleshoot a case.
Clear Log Click this button to clear the log file from the system.
Related Using the Admin Console Troubleshooting Tools on page 751

Documentation

Using the Debug Log
The Pulse Secure Global Support Center (PSGSC) might direct you to create a debug
log to assist them in helping you debug an issue with the system. The debug log is used
only by PSGSC.
To use debug logging:
1. Select Troubleshooting > Monitoring > Debug Log to display the configuration page.
3. Click Save Changes. When you save changes with Debug Logging On selected, the
system begins generating debug log entries.
4. Initiate the action you want to debug, such as a user sign in. You can reset the debug
log file to restart debug logging if it takes you too long to initiate the action.
5. Click Save Debug Log to save the debug log to a file that you can send to PSGSC.
You can clear the log after you have saved it to a file.
6. Unselect Debug Logging On and click Save Changes to turn off debug logging.

Figure 227: Debug Logging Configuration Page – Pulse Policy Secure
Figure 228: Debug Logging Configuration Page – Pulse Connect Secure
Table 114: Debug Log Configuration Guidelines
Settings Guidelines
Current Log Size Displays the size of the current log file. If it is large, use the controls to save, reset, or clear the log
file.
Debug Logging On Specify the source IP address if you know it. If you are able to provide the source IP address, the
policy trace log can include events that occur before the user ID is entered into the system.
Debug Log Size Specify a maximum debug logfile size. The default is 2 MB. The maximum is 250 MB.
Debug Log Detail Level Specify the debug log detail level. Obtain this from PSGSC.
Include logs Select this option to include system logs in the debug log file. Recommended.
Process Names Specify the process name. Obtain this from PSGSC.

Table 114: Debug Log Configuration Guidelines (continued)
Settings Guidelines
Event Codes Specify the event code. Obtain this from PSGSC.
Related  Using the Admin Console Troubleshooting Tools on page 751

Documentation
Using the RADIUS Diagnostic Log
The RADIUS diagnostic log utility allows you to view trace and debug-level RADIUS
messages. When RADIUS diagnostic logging is enabled, the diagnostic tool logs all
requests that the Pulse Policy Secure receives from RADIUS clients. RADIUS requests
initiated by the Pulse Policy Secure do not appear in the log.
Observe the following guidelines:
 Diagnostic logging affects system performance.
 All events that appear in the log have an ID code, and all messages in a thread are
tagged with the same ID. This allows you to track individual logins or login attempts.
 Source IP addresses are represented as 127.0.0.1 (the loopback address).
 For Layer 2 connections, the calling station ID is the MAC address of the endpoint.
 Passwords are suppressed and do not appear in the logs.
 When the log fills up, logging stops. You can clear the log to restart logging.
 Raw traffic is not available in the log. To view raw traffic, use the tcpdump feature.
To use RADIUS diagnostic logging:
1. Select Troubleshooting > Monitoring > RADIUS to display the configuration page.
3. Click Save Changes. When you save changes with RADIUS Diagnostic Logging On
selected, the system begins generating diagnostic log entries.
4. Initiate the action you want to debug, such as a user sign in. You can clear the debug
log file to restart diagnostic logging if it takes you too long to initiate the action.
5. Click Save And Clear Log to save the diagnostic log to a file that you can send to
PSGSC. You can clear the log after you have saved it to a file.
6. Unselect RADIUS Diagnostic Logging On and click Save Changes to turn off diagnostic
logging.

Figure 229: RADIUS Diagnostic Logging Configuration Page
Table 115: RADIUS Debug Log Configuration Guidelines
Settings Guidelines
RADIUS Diagnostic Specify the source IP address if you know it. If you are able to provide the source IP address, the
Logging On policy trace log can include events that occur before the user ID is entered into the system.
Max Diagnostic Log Size Specify a maximum logfile size. The default is 1000 MB.

Documentation

Using the tcpdump Utility
You can run the tcpdump utility from the admin console.
To use tcpdump:
1. Select Troubleshooting > Tools > TCP Dump to display the configuration page.
3. Click Start Sniffing to start the tcpdump process.
4. Initiate the action you want to debug, such as a user sign in.

5. Click Stop Sniffing to write the tcpdump output to the screen.
6. Click Get to save the output to a file, or click Delete to clear the output.
Figure 230: TCP Dump Configuration Page – Pulse Policy Secure
Figure 231: TCP Dump Configuration Page – Pulse Connect Secure
Table 116: Debug Log Configuration Guidelines
Settings Guidelines
TCP Dump Displays whether the utility is stopped or running.

Status

Table 116: Debug Log Configuration Guidelines (continued)
Settings Guidelines
Interface Select the ports on which to sniff.
VLAN Port Select the VLAN port.
Promiscuous Select a promiscuous mode option.

mode
Filter Specify a filter expression. For information about TCP dump filter expressions, see the UNIX man page.
Example Result
tcp port 80 Sniffs packets on TCP port 80.
port 80 Sniffs packets on TCP or UDP port 80.
ip Sniffs the IP protocol.
tcp Sniffs the TCP protocol.
dst #.#.#.# Sniffs the destination IP address specified, where

#.#.#.# is a valid IP address.
src #.#.#.# Sniffs the source IP address specified, where #.#.#.#

is a valid IP address.
port 80 or port 443 Sniffs on port 80 or port 443.
src #.#.#.# and dst #.#.#.# Sniffs the source and destination IP addresses or hosts
specified, where each #.#.#.# represents a valid IP
address.
tcp port 80 or port 443 and dst #.#.#.# and src #.#.#.# This example shows how to specify multiple
parameters to create a filter that sniffs on TCP port
80, or on TCP or UDP port 443, and on the destination
and source ports, where each #.#.#.# represents a
valid IP address.

Documentation

Using Network Troubleshooting Commands
You can run common network troubleshooting commands such as arp, ping, ping6,
traceroute, traceroute6, NSlookup, and AvgRTTs from the admin console. You can use
these connectivity tools to see the network path from the system to a specified server.
If a client can ping or traceroute to the access system, and the access system can ping
the target server, any remote users should be able to access the server through the access
system.

To run network troubleshooting commands:
1. Select Troubleshooting > Tools > TCP Commands to display the configuration page.
3. Click OK to run the command and write the output to the screen.
4. Click Clear to clear the output.
Figure 232: Network Troubleshooting Commands Configuration Page – Pulse Policy Secure

Figure 233: Network Troubleshooting Commands Configuration Page – Pulse Connect Secure

Table 117: Network Troubleshooting Commands Configuration Guidelines
Settings Guidelines
Command Select a network troubleshooting command:
 Ping/Ping6—Use the ping command to verify that the system can connect to other systems on
the network. In the event of a network failure between the local and remote nodes, you do not
receive a reply from a pinged device. In that case, contact your LAN administrator for help. The
ping command sends packets to a server and returns the server response, typically a set of
statistics including the target server’s IP address, the time spent sending packets and receiving
the response, and other data. You can ping unicast or multicast addresses, and you must include
the target server name in the request. Select ping to ping an IPv4 address or hostname. Select
ping6 to ping an IPv6 address. We do not support DNS resolution for hosts with IPv6 addresses.
Hence, ping6 does not support pings to hostnames.
 Traceroute/Traceroute6—Use the traceroute command to discover the path that a packet takes
from the Pulse Connect Secure to another host. Traceroute sends a packet to a destination
server and receives an ICMP TIME_EXCEEDED response from each gateway along its path. The
TIME_EXCEEDED responses and other data are recorded and displayed in the output, showing
the path of the packet round-trip. Select traceroute to target an IPv4 address or hostname. Select
traceroute6 to target an IPv6 address. We do not support DNS resolution for hosts with IPv6
addresses. Hence, traceroute6 does not support traceroute to hostnames.
 NSLookup—Use NSlookup to get detailed information about a name server on the network. You
can query on several different types of information, including a server’s IP address, alias IP address,
start-of-authority record, mail exchange record, user information, well-known services information,
and other types of information.
 ARP—Use the arp command to map IP network addresses to the hardware addresses. The
Address Resolution Protocol (ARP) allows you to resolve hardware addresses. To resolve the
address of a server in your network, a system sends information about its unique identifier to a
server process executed on a server in the intranet. The server process then returns the required
address to the client process.
 AvgRTTs—Use AvgRTTs to display the average round-trip time (RTT) to the localhost.
 Portprobe—Display the Transmission Control Protocol (TCP) or the User Datagram Protocol
(UDP) port status (open or closed).
Target server Specify the IP address or hostname for the target server.
Interface Select the interface from which to send the command.
VLAN Port If you are operating on an IVS license, you can select a VLAN port, to test connectivity to a subscriber
intranet.
Output Displays command output.
Related  Using the Admin Console Troubleshooting Tools on page 751

Documentation
 Troubleshooting TCP and UDP Port Status on page 765
 Running NSLookup to Test Name Server Connectivity on page 768
Troubleshooting TCP and UDP Port Status

Problem The system makes several connections to back-end servers using various port numbers.
If communication between the system and the back-end servers stops, it can be difficult
to determine the source of the problem.

Solution You can use the Portprobe command to display the Transmission Control Protocol (TCP)
or the User Datagram Protocol (UDP) port status (open or closed).
NOTE: Only the system internal ports, management port and internal VLAN
ports support the Portprobe command.
A TCP port can be closed under two conditions:
 The system sends a connection request to the back-end server port and the back-end
server closes the connection (sends an RST packet).
 The connection request times out because the back-end server is not found or the
back-end server is too busy to respond to the connection request.
If either of these conditions occurs, the system sends a ping command to the back-end
server. If the ping command is successful, the back-end server is considered reachable
but the back-end server port is closed. If the ping command fails, the back-end server is
considered unreachable.
For UDP ports, the system sends a UDP datagram with a ping to the back-end server
port. If the back-end server responds with Internet Control Message Protocol (ICMP)
port unreachable or ICMP unreachable, the back-end port is considered unreachable. If
the back-end server responds with ICMP host unreachable then the back-end server is
considered unreachable.
To troubleshoot the TCP or UDP port:
1. Select Maintenance > Troubleshooting > Tools > Commands.
2. Select the Portprobe command.
3. Select either TCP or UDP.
4. Enter the target server and port number. You can enter an IP address, hostname or
FQDN for the target server.
5. Enter the probe count. This is the number of times the system attempts to
communicate with the back-end server port. The default for TCP is one; the default
for UDP is five.
6. Enter the probe timeout. This is the number of seconds the system waits for a response
from the back-end server port.
7. Select either the internal port or the management port. If the management port is not
configured, it is not displayed.
8. If using an internal port, select the internal VLAN port from the list.
9. Click OK.
Figure 234 on page 767 and Figure 235 on page 768 show an example of a successful and
an unsuccessful port probe.

Figure 234: Successful TCP Port Probe

Figure 235: Unsuccessful UDP Port Probe

Documentation

Running NSLookup to Test Name Server Connectivity
To run NSLookup to test name server connectivity:
1. In the admin console, choose Maintenance > Troubleshooting >Tools > Commands.
2. From the Command list, select NSLookup.
3. Select the type of query to use from the Query Type drop down menu.
4. Enter the query, which is a host name, an IP address, or other information, depending
on your selection of query type.
5. Enter the DNS server name or IP address.
6. If you are operating on an IVS license, you can select a VLAN port, to test connectivity
to a subscriber intranet.
7. Enter other options.
8. Click OK to run the command.

Figure 236: Network Troubleshooting Commands Configuration Page – Pulse Policy Secure
Figure 237: Network Troubleshooting Commands Configuration Page – Pulse Connect Secure

Documentation


Using the Kerberos Debugging Utility
You can run the Kerberos debugging utility from the admin console. The utility checks
the DNS infrastructure for validity of the Kerberos realms and defined credentials.
To use the Kerberos debugging utility:
1. Select Maintenance > Troubleshooting > Tools > Kerberos to display the configuration
page.
3. Click Run to start the debugging process.
4. Click Get to save the output to a file, or click Delete to clear the output.
Figure 238: Kerberos Debugging Utility Configuration Page
Table 118: Kerberos Debugging Utility Configuration Guidelines
Settings Guidelines
Probe Select this option to display the configuration elements for the Kerberos DNS test.
Kerberos
DNS Setup
Kerberos Specify the realm name.

Realm
Site Specify the fully qualified domain name.

Table 118: Kerberos Debugging Utility Configuration Guidelines (continued)
Settings Guidelines
Output Displays results of the probe, for example:
KDCs for realm matrix.net:

top.matrix.net,top.matrix.net
Operation complete

Documentation

Using Remote Debugging
Remote debugging allows Pulse Secure Global Support Center (PSGSC) to directly
access this system over a secure connection. You should enable this feature only if you
have been requested to do so by PSGSC in response to an issue that you have reported.
To enable remote debugging:
1. Select Maintenance > Troubleshooting > Remote Debugging to display the configuration
page.
2. Complete the configuration and actions as described in Table 119 on page 772.
Figure 239: Remote Debugging Configuration Page – Pulse Policy Secure

Figure 240: Remote Debugging Configuration Page – Pulse Connect Secure
Table 119: Remote Debugging Configuration and Action Guidelines
Settings Guidelines
Debugging Displays whether remote debugging is enabled or disabled.

Status
Debugging Specify a code as instructed by.

Code PSGSC
Connect to Specify the fully qualified domain name as instructed by PSGSC.
Enable Click this option to allow remote debugging.

Debugging

Documentation


CHAPTER 22
Clustering
 About Clustering on page 773

 About Cluster Licensing on page 775
 Task Summary: Deploying a Cluster on page 776
 Defining and Initializing a Cluster on page 777
 Joining an Existing Cluster on page 778
 Re-Adding a Node to a Cluster on page 779
 Deploying Two Nodes in an Active/Passive Cluster on page 780
 Failing Over the VIP to Another Node on page 782
 Deploying Two or More Units in an Active/Active Cluster on page 782
 Synchronizing the Cluster State on page 784
 Specifying Active/Passive, Active/Active, and Other Cluster Settings on page 787
 Adding Multiple Cluster Nodes on page 788
 Managing Network Settings for Cluster Nodes on page 789
 Changing the IP Address of a Cluster Node on page 789
 Deleting a Cluster on page 790
 Restarting or Rebooting Cluster Nodes on page 790
 Summary: Admin Console Cluster Procedures on page 791
 Monitoring Clusters on page 793
 NSRP Clustering Considerations with the ScreenOS Enforcer on page 794
 Using the Policy Secure gateway with an SRX Series Cluster on page 795
 Troubleshooting Cluster Communication Problems on page 795
 Summary: Serial Console Cluster Procedures on page 797
 Joining a Policy Secure gateway to a Cluster Through Its Serial Console on page 798
 Disabling a Clustered Policy Secure gateway Using Its Serial Console on page 799
About Clustering
You can purchase a clustering license to deploy two or more Policy Secure gateway
appliances as a cluster. These appliances support active/passive or active/active
configurations

across a LAN to provide high availability, increased scalability, and load-balancing

capabilities.
You define a cluster on one Policy Secure gateway by specifying the following data:
 A name for the cluster
 A password for the cluster members to share
 A name to identify the machine in the cluster
Entering this information allows you to initiate the first member of your cluster. You then
must specify which Policy Secure gateways you want to add to the cluster. After a Policy
Secure gateway is identified as an intended member, you can add it to the cluster
through either the admin console or the serial console (if the machine is in the initial
factory state).
When a Policy Secure gateway joins a cluster, it initializes its state from the existing
member that you specify. The new member sends a message to the existing member
requesting synchronization. The existing member sends the system state to the new
member and overwrites all system data on that machine. After that point, the cluster
members synchronize data when there is a state change on any member. Cluster
member communication is encrypted to prevent attacks from inside the corporate
firewall. Each Policy Secure gateway uses the shared password to decrypt
communication from another cluster member. For security reasons, the cluster
password is not synchronized across Policy Secure gateways. During synchronization,
the new node receives the current service package, which upgrades the node if it is
running an older service package.
If a Policy Secure gateway is not part of a cluster, the Clustering page displays the Create
tab. The Create tab allows you to create the configurations for cluster nodes, even if you
have no physical devices available to join the cluster.
After you create the cluster, the Clustering page shows the Status tab and the Properties
tabs which replace the original Join and Create tabs. Use the Status tab to specify a
Policy Secure gateway to add to a cluster, manage network settings for cluster nodes,
and upgrade the cluster service package. The Properties tab allows you to specify
active/passive, active/active, and other cluster settings, and to delete a cluster.
NOTE: Clustering is not supported across WAN links.
NOTE: Clustering is only supported for like devices. For example, an IC6500
can only be in cluster with another IC6500.
Related Task Summary: Deploying a Cluster on page 776

Documentation
 Defining and Initializing a Cluster on page 777

 About Cluster Licensing on page 775

Chapter 22: Clustering
About Cluster Licensing
UAC Release 4.0 introduces several clustering license changes including:
 A license is no longer required to create a cluster. Prior to Policy Secure gateway

Release 4.0, to create a multiple node cluster that supports multiple concurrent
users, you were required to purchase one ADD-ccccE license for one cluster node,
and n-1 CL licenses (one for each of the remaining cluster nodes). For example, to
create a 4-node cluster supporting 2000 concurrent users, you needed to purchase
one ADD-2000E license and 3 CL licenses.
 CL licenses are no longer necessary but are still supported. When you upgrade to
Policy Secure gateway Release 4.0, your existing licenses continue to work. There is
no cluster grace period for the node with a CL license installed. When the node with
a CL license installed disconnects, the capacity computation is the same as before
Release 4.0.
 A 5-day cluster grace period provides license flexibility when a node crashes or loses
connectivity with the rest of the cluster.
 We recommend that you distribute your ADD licenses equally across the cluster to
avoid losing large number of licenses when a node disconnects from the cluster.
With UAC Release 4.0, the maximum number of concurrent users allowed in a cluster is
the sum of all user licenses on all connected nodes. If a node disconnects from the cluster
(either active/active or active/passive), up until the grace period ends the maximum
license per each remaining node is their current license plus the minimum of their own
license and the licenses of the other nodes.
Table 120 on page 775 illustrates why we recommend distributing licenses equally across
all cluster nodes.
Table 120: License Distribution Examples
License Distribution Example
Example 1: Equal distribution Suppose Node A and Node B are part of a cluster, and each node has 500 concurrent user
licenses. As long as both nodes are connected, the maximum number of licenses is 1000.
Suppose Node B disconnects from the cluster. Until the clustering grace period ends, the
maximum number of licenses on Node A is 500 (from Node A’s original license) + minimum
(licenses on Node A (500), licenses on Node B (500)) = 500 + 500 = 1000.
After the grace period ends, the maximum number of licenses on Node A reverts to its original
license of 500.

Table 120: License Distribution Examples (continued)
License Distribution Example
Example 2: Unequal distribution In this example, Node A and Node B are part of a cluster. Node A has 600 ADD licenses and
Node B has 400 ADD licenses. As long as both nodes are connected, the maximum number
of licenses is 1000.
(licenses on Node A (600), licenses on Node B (400)) = 600 + 400 = 1000. After the grace
period ends, the maximum number of licenses on Node A is 600.
Suppose Node A disconnects from the cluster. Until the clustering grace period ends, the
maximum number of licenses on Node B is 400 (from Node B’s original license) + minimum
(licenses on Node A (600), licenses on Node B (400)) =400+400 = 800. After the grace
period ends, the maximum number of licenses on Node B is 400.
Example 3. Unequal distribution In this example, Node A and Node B are part of a cluster. Node A has 1000 ADD licenses
(extreme) and Node B has no ADD licenses. As long as both nodes are connected, the maximum
number of licenses is 1000.
(licenses on Node A (1000), licenses on Node B (0)) = 1000 + 0 = 1000. After the grace
period ends, the maximum number of licenses on Node A is 1000.
Suppose Node A disconnects from the cluster. Until the clustering grace period ends, the
maximum number of licenses on Node B is 0 (from Node B’s original license) + minimum
(licenses on Node A (1000), licenses on Node B (0)) =0+0 = 0. After the grace period ends,
the maximum number of licenses on Node B is 0.
For the scenarios in Examples 2 and 3, we recommend you distribute the licenses equally
amongst the nodes.

Documentation
 About Clustering on page 773

Task Summary: Deploying a Cluster
We recommend that you first deploy a cluster in a staging environment first and then
move to a production environment after you test authentication realm, user role, and
resource policy configurations, as well as any applications your end-users may access.
To create a Policy Secure gateway cluster:
1. Ensure that all intended Policy Secure gateway nodes use the same hardware
platform (for example, all are IC 6500 devices).
2. Ensure that all intended Policy Secure gateway nodes are initially configured (for
example, Policy Secure gateway hostname is specified and the internal and
external IP addresses are assigned), and that they are running the same service
package version.

3. In the admin console. select System > Configuration > Licensing , and enable the
clustering feature on the primary server by entering a standalone license and any
feature licenses.
4. Select System > Clustering > Create Cluster, and initialize the Policy Secure gateway
cluster by defining the cluster name and adding the first/primary Policy Secure
gateway to the cluster.
5. Select System > Clustering > Status, and add the names and IP addresses of future
cluster Policy Secure gateways to the primary Policy Secure gateway.
6. Select System > Clustering > Join Cluster, and populate the cluster with additional
Policy Secure gateways as necessary.
Related Defining and Initializing a Cluster on page 777

Documentation

Defining and Initializing a Cluster
If you are currently running standalone Policy Secure gateways that you want to cluster,
we recommend that before you create a cluster, you configure system and user settings
on one machine. Then, use the same machine to create the cluster. This machine joins
the cluster as part of the creation process. When other Policy Secure gateways join the
cluster, this machine propagates its configuration to the new cluster member.
To define and initialize a cluster:
1. Configure one Policy Secure gateway with the appropriate license and system, user,
resource, and application data.
2. In the admin console, select System > Clustering > Create and enter a cluster name,
a cluster password, and a name for this machine, (such as Server-1).
You need to enter the password again when configuring additional Policy Secure
gateways to join the cluster. All machines in the cluster use this password to
communicate.
3. Click Create Cluster. When you are prompted to confirm the cluster creation, click
Create. After the Policy Secure gateway initializes the cluster, the Clustering page
displays the Status tab and the Properties tab. Use the Status tab to specify
additional cluster members before you try to add another Policy Secure gateway to
the new cluster.

Documentation


Joining an Existing Cluster
This topic describes how to add a member to a cluster. It includes the following
information:
 Before You Begin on page 778

 Specifying a Policy Secure gateway to Join to a Cluster on page 778
 Adding a Policy Secure gateway to a Cluster Through the Admin Console on page 779
Before You Begin

The method you use to join a Policy Secure gateway to a cluster depends on whether
the Policy Secure gateway is configured or uninitialized (still in its factory state). For a
Policy Secure gateway in its factory state, we recommend the serial console procedure
because it requires minimal information for the machine to join a cluster.
NOTE:
 If you add a Policy Secure gateway running an earlier version service
package to a cluster, the Policy Secure gateway automatically detects the
mismatch, gets the newer package from the cluster, and joins the cluster.
 Existing node-specific settings are erased when a Policy Secure gateway

node joins a cluster. These settings include network interface addresses,
route tables, virtual ports, ARP caches, VLAN interface, SNMP settings,
and so on. You must manually reconfigure these settings for the newly
joined node. You cannot use the Import system configuration feature to
import these configurations and settings into a Policy Secure gateway
node that joins the cluster.
Specifying a Policy Secure gateway to Join to a Cluster

Before a Policy Secure gateway can join a cluster, you must specify its network identity
on an active cluster member.
To specify a Policy Secure gateway to add to an existing cluster:
1. In the admin console of an active cluster member, select the System > Clustering >
Cluster Status tab.
2. Click Add Members to specify a Policy Secure gateway that will join the cluster:
a. Enter a name for the member.
b. Enter the machine’s internal IP address.
c. Enter the machine’s external IP address if necessary. Note that the External IP
address field does not appear if you did not enable the external port in the External
Port tab.
d. Change the netmask and gateway settings for the node if necessary.

e. Click Add Node. When you are prompted to confirm adding the new member, click
Add.
f. Repeat this procedure for each Policy Secure gateway you intend to add to a cluster.
Adding a Policy Secure gateway to a Cluster Through the Admin Console

Before you can add a Policy Secure gateway to a cluster (through either the Web or the
serial console), you need to make its identity known to the cluster. Note that if a Policy
Secure gateway has a cluster license key, it has only a Clustering > Join tab.
To add a Policy Secure gateway to a cluster through its admin console:
1. On an existing cluster member, select System > Clustering > Cluster Status, and specify
the Policy Secure gateway you want to add to the cluster.
2. In the admin console of the Policy Secure gateway you want to add to a cluster:
a. Select System > Configuration > Licensing, and enter the correct license key
(containing the machine type, the initials CL to indicate a cluster, and the number
of endpoints—for example, IC6500-CL-1000E) to enable the clustering feature.
b. Select System > Clustering > Join, and enter:
 The name of the cluster to join
 The cluster password you specified when defining the cluster
 The IP address of an active cluster member
c. Click Join Cluster. When you are prompted to confirm joining the cluster, click Join.
After the Policy Secure gateway joins the cluster, you may need to sign in again.
While the new node synchronizes its state with the existing cluster member, each node’s
status on the Status page indicates <Enabled, Enabled, Transitioning, or Enabled,
Unreachable>.
Related Summary: Serial Console Cluster Procedures on page 797

Documentation

Re-Adding a Node to a Cluster
With some maintenance operations, you might need to remove a node from a cluster,
then re-add and re-join it to the cluster.
When a Policy Secure gateway node joins a cluster, all of its node-specific settings
(including network interface addresses, route tables, virtual ports, ARP caches, VLAN
interface, SNMP settings) are overwritten by the corresponding configuration setting it
receives from the cluster.
To populate the newly joined node with the correct node-specific settings:
1. Add the node to the cluster.

2. On any of the existing nodes in the cluster, manually configure the appropriate
node-specific settings for the newly added node by selecting the node from the menu
in the settings page.
3. Add the node to the cluster.
When the node joins the cluster, it receives its newly configured node-specific settings
from the cluster.
NOTE: You configure the node-specific settings for the newly added node
manually because binary import options are not useful. The only
recommended binary import option into a cluster is “Import everything except
network settings and licenses” from the Configuration page, which restores
cluster-wide configuration (sign-in, realms, roles, resource policies etc.) from
a backup binary file. Because this option skips node-specific settings, you
must perform step 2 manually to populate the newly joined node with the
right set of node-specific settings.
Related Joining an Existing Cluster on page 778

Documentation

Deploying Two Nodes in an Active/Passive Cluster
You can deploy a cluster pair in active/passive mode. In this mode, one Pulse Policy
Secure node actively serves user requests while the other runs passively in the background
to synchronize state data, including system state, user profile, and log messages. User
requests to the cluster VIP (virtual IP address) are passed to the active node. If the active
node goes off line, the standby node automatically starts servicing user requests. Users
do not need to sign in again.
In some cases, you might need to manually force failover of the cluster VIP to the other
node. You can perform a manual failover by using the Fail-Over VIP button on the
Clustering Status page.
Figure 241 on page 781 illustrates an active/passive cluster configuration using two nodes
that have enabled external ports. Note that this mode does not increase throughput or
user capacity,but provides redundancy to handle unexpected system failure.User requests
are directed to the cluster VIP, which then routes them to the currently active machine.

Figure 241: Active/Passive Clustering
The following list provides deployment guidelines:
 A cluster VIP is optional if all the endpoints that connect to the Pulse Policy Secure
support OAC or Pulse. A Pulse Secure client on the endpoint can connect directly to a
cluster node and download information about the other cluster nodes. If the cluster
node to which the client is connected goes off line, the client automatically connects
to the other nodes in the cluster.
A cluster VIP is required if you are using agentless access for endpoint platforms such
as Macintosh or Linux, that connect to the Pulse Policy Secure.
 Switches, access points, and other RADIUS clients should be configured to send RADIUS
requests to the cluster VIP rather than the IP address of each node. This is particularly
important if the RADIUS client receives RADIUS Change of Authorization (CoA) or
RADIUS Initiated Disconnect (RID) messages from the Infranet Enforcer.
 A cluster VIP is required for the Infranet Enforcer to connect to the active node. If you
do not use a cluster VIP, you must create a Pulse Policy Secure instance on the
Infranet Enforcer that specifies the IP address of each node. You can configure an
Infranet Enforcer to operate with up to eight Pulse Policy Secure nodes. (However, the
Infranet Enforcer can operate with only one node at a time.) All nodes with which an
Infranet Enforcer operates must be members of the same cluster. When a node goes
down, the Infranet Enforcer tries to connect to each node in its list until it succeeds. If
the primary node goes down, and the Infranet Enforcer connects to a subsequent
node in the list, the Infranet Enforcer will stay connected to that device even if the
primary node comes back up.
 If you use a VIP, you must use a device certificate for the node that refers to that VIP.
Related Failing Over the VIP to Another Node on page 782

Documentation


Failing Over the VIP to Another Node
In an active/passive cluster, you might need to fail the VIP to the other node, regardless
of which node you are currently using.
To fail over the VIP:
1. In the admin console, select System > Clustering > Cluster Status.
2. Click the Fail-Over VIP button to move to the other node. The Fail-Over VIP button is
a toggle button, so you can move from one node to the other, regardless of which is
the leader. The fail over occurs immediately.
Related Deploying Two Nodes in an Active/Passive Cluster on page 780

Documentation

Deploying Two or More Units in an Active/Active Cluster
NOTE:
When choosing and configuring a load balancer for your cluster, we
recommend that you ensure the load balancer:
 Supports IPsec
 Listens for traffic on multiple ports
 Can be configured to manage traffic using assigned source and destination

IP addresses (not destination port)
In active/active mode, you have the option of using an external load balancer with a
Policy Secure gateway cluster. If you do use a load balancer, all the nodes actively
handle user requests sent by the load balancer or round-robin DNS. The load balancer
hosts the cluster VIP and routes user requests to a Policy Secure gateway defined in
its cluster group based on source-IP routing. If a Policy Secure gateway goes off line,
the load balancer adjusts the load on the active Policy Secure gateways. Users do not
need to sign in again.
The Policy Secure gateway synchronizes state data on all nodes if you add or delete the
host entry on the Network Settings pages. If you add or delete the host entry using the
Clustering tab for a cluster member, the state data affects only the node and the Policy
Secure gateway does not synchronize the data across the entire cluster.
The Policy Secure gateway hosts an HTML page that provides service status for each
Policy Secure gateway in a cluster. External load balancers can check this resource to
determine how to effectively distribute the load among all the cluster nodes.
To perform the Layer 7 health check for a node:
 In a browser—Enter the URL:
https://<IC Series device-Hostname>/dana-na/healthcheck/healthcheck.cgi

 In an external load balancer—Configure a health check policy that sends the following
request to cluster nodes:
GET /dana-na/healthcheck/healthcheck.cgi HTTP/1.1\r\nHost: localhost\r\n\r\n
The node returns one of two values:
 “Security gateway is accessible” string—This value means the node is active.
 500—This value indicates an error, and cluster Policy Secure gateways stop
forwarding user requests to the node.
Figure 242 on page 783 illustrates an active/active Policy Secure gateway cluster
configuration in which the Policy Secure gateways have enabled external ports.
This active/active cluster configuration is deployed behind an external load balancer.

You can deploy a cluster pair or multiunit cluster in active/active mode. Policy Secure
gateway user requests are directed to the cluster VIP defined on the load balancer,
which routes them to the appropriate machine.
Figure 242: Active/Active Clustering

NOTE:
In active/active mode:
 A cluster VIP is optional if all the endpoints that connect to the Policy
Secure gateway support OAC or Pulse. A Pulse Secure client on the
endpoint can connect directly to a cluster node and download
information about the other cluster nodes. If the cluster node to which the
client is connected goes offline, the client automatically connects to the
other nodes in the cluster.
However, a cluster VIP is required if you are using agentless access for
endpoint platforms that connect to the Policy Secure gateway.
 A cluster VIP is optional to connect the Infranet Enforcer to the Policy

Secure gateway. If you don’t use a cluster VIP, you must create a Policy
Secure gateway instance on the Infranet Enforcer that specifies the IP
address of each node. You can configure an Infranet Enforcer to operate
with up to eight Policy Secure gateways. (However, the Infranet Enforcer
can only operate with one Policy Secure gateway at a time.) The group of
Policy Secure gateways with which an Infranet Enforcer operates must
all be members of the same cluster. When a Policy Secure gateway goes
down, the Infranet Enforcer tries to connect to a Policy Secure gateway in
its list until it succeeds.
 If you use a VIP, you must use a device certificate for the Policy Secure
gateway that refers to that VIP.

Documentation

Synchronizing the Cluster State
Policy Secure gateway state synchronization occurs only by means of the internal
network interface cards (NICs), and each cluster member must use the cluster
password to communicate with other members. Cluster members synchronize data
when a state change occurs on any member. Policy Secure gateway cluster state data is
either persistent (permanently stored on the Policy Secure gateway) or transient
(stored on the Policy Secure gateway for only the user’s session). Policy Secure
gateway state data falls into the following major categories:
 System state—This state is persistent and does not change often.
 Network settings
 Authentication server configurations

 Authorization group configurations, such as access control list, messaging, and

application data
 NACN password, administrator name and password for signing into the ScreenOS
Enforcer using SSH, and serial number(s) of the Enforcer(s).
 Infranet Enforcer state—This state is transient.
 The cluster member to which each Infranet Enforcer connects. This enables other
cluster members to use the appropriate cluster member for communications with
each Infranet Enforcer.
NOTE: When the Policy Secure gateway connects to the Infranet

Enforcer, the Policy Secure gateway examines the setting for Cleanup
Infranet State Delay on the Infranet Enforcer. If this setting has a default
value of 120 seconds, the Policy Secure gateway changes it to 180
seconds. This is to give a cluster of Policy Secure gateways additional
time to reboot without disrupting connections from endpoints to
resources that are protected by the Infranet Enforcer.
 User session—This state is transient and dynamic. The user session consists of the
following data:
 Host Checker status of the endpoint
 User’s set of roles
 Monitoring state—This persistent information consists of log messages.
If you notice too much latency occurring on one or more nodes, you might need to
change the Clustering Timeouts Settings.
Whether you deploy a cluster in active/passive or active/active mode, the Policy

Secure gateway is responsible for synchronizing data between cluster members. The
Policy Secure gateway synchronizes all system data and user session data
immediately. If one cluster member goes off line, users do not need to sign in to the
Policy Secure gateway again.
When you add a Policy Secure gateway to a cluster, the cluster leader does not send
log messages to the new member. Log messages are also not synchronized between
cluster members when one member restarts its services or when an off line machine
comes back online. Once all machines are on line, however, log messages are
synchronized.
NOTE: If you are running an active/active cluster, do not allow the cluster to
switch to active/passive mode unless the active/active and active/passive
clusters share compatible spread timeout settings.

You can also configure synchronization settings to improve performance:
 Specify the synchronization protocol—When three or more Policy Secure

gateways are running in a cluster you can use the synchronization protocol
(Unicast, Multicast, or Broadcast) that best suits the network topology.
 Synchronize log messages—Log messages can create a huge payload on the network
and affect cluster performance. This option is disabled by default.
 Synchronize user sessions—This option synchronizes all user session information

(such as instances of access to services) among all Policy Secure gateways in the
cluster.
 Synchronize last access time for user sessions—This option allows you to propagate
user access information in the cluster. If this option is the sole synchronization item
among the cluster nodes, you can significantly reduce CPU impact among the cluster
Policy Secure gateways.
NOTE:
 If you configure your cluster as active/passive, the Synchronize user sessions
and Synchronize last access time for user sessions options are
automatically selected.
 If you select both the Synchronize log messages and Synchronize user
sessions check boxes, everything is replicated on the cluster nodes, including
networking information. Even though networking information, including
syslog and SNMP settings, can be configured per node or per cluster, all of
the networking information is synchronized between nodes when these
two options are set.
 If your cluster node configurations diverge because of changes made to

one node while another is disabled or unavailable, the Policy Secure
gateway manages the remerging of the configurations automatically, for
up to 16 updates. Beyond the maximum number of allowable updates,
you might need to intervene and remerge the configurations manually. In
some instances, the Policy Secure gateway may be unable to remerge the
configurations if there is not enough overlapping configuration
information between two nodes to manage the internode
communication.
For example, for a two-node cluster in which the two nodes are partitioned
from each other because of a network outage, if the internal network IP
address of one of the nodes changes in one of the partitions, the two
partitions are unable to rejoin, even when the network is repaired. In such
a case, you must remerge the configurations manually.

Documentation


Specifying Active/Passive, Active/Active, and Other Cluster Settings
Use the Properties page to change the name of a cluster, specify in which configuration
to run a cluster (active/passive or active/active), specify synchronization and network
healthcheck settings, or delete a cluster.
To modify cluster properties:
1. In the admin console of an active cluster member, select the System > Clustering >
Cluster Properties page.
2. (Optional) Edit the name of the cluster in the Cluster Name field to change the cluster’s
name.
3. Under Configuration Settings, select one of the following options:
 Active/Passive to run a cluster pair in active/passive mode. Then specify an internal

VIP (virtual IP address) and an external VIP if the external port is enabled.
NOTE: To run a two-unit cluster in active/passive mode, the Policy

Secure gateways must reside on the same subnet.
 Active/Active runs a cluster of two or more nodes in active/active mode using an

external load balancer.
NOTE: To change a two-unit active/passive cluster to an active/active

cluster with more than two nodes, first change the configuration of the
two-unit cluster to active/active and then add the additional nodes.
4. Under Synchronization Settings, specify one or more types of data to synchronize

using the following options:
 Synchronize log messages—Propagates all log messages among all of the Policy
Secure gateways in the cluster.
 Synchronize user sessions—Synchronizes all user session information (such as

instances of access to services) among all Policy Secure gateways in the
cluster.
NOTE: If you have a clustering configuration that includes Infranet

Enforcers, you must select the Synchronize user sessions check box.
Clearing this check box prevents the Policy Secure gateway from
synchronizing auth tables on the Infranet Enforcer.
 Synchronize last access time for user sessions—Propagates the latest user access
information across the cluster.

NOTE:
If you select both the Synchronize log messages check box and the
Synchronize user sessions check box, everything is replicated on the
cluster nodes, including networking information. Even though
networking information, including syslog and SNMP settings, can be
configured per node or per cluster, all of the networking information
is synchronized between nodes when these two options are set.
 If you are using a load balancer in conjunction with the Policy Secure
gateway, we recommend you clear the Synchronize last access time
for user sessions check box.
 Doing so can greatly improve cluster synchronization performance.

However, disabling this option while users are connected to the
Policy Secure gateway can result in client-side warnings informing the
user that the session is about to expire. These warnings are
generated automatically because of timestamp mismatches. The
user sessions do not actually disconnect.
5. Under Network Healthcheck Settings, specify the number of ARP ping failures allowed
before the Policy Secure gateway’s internal interface is disabled. Also specify
whether or not to disable the Policy Secure gateway’s external interface if the
internal interface fails.
6. Select the Advanced Settings check box to specify timeouts for the underlying cluster
system. Do not change any values under this setting unless instructed to do so by
Pulse Secure Technical Support.
8. If you are using an external load balancer, select System > Network > Load Balancer.
9. Depending on the port to which endpoints connect, enter the IP address of the load
balancer in the Internal Address box or the External Address box.
10. Select the Between endpoints and the Policy Secure gateway check box.

Documentation
 Deploying Two Nodes in an Active/Passive Cluster on page 780

Adding Multiple Cluster Nodes
To add multiple nodes to a cluster:
1. Select System > Clustering > Cluster Status.
2. Click Add Members.
3. Enter the node name and internal IP address.

4. Modify or add the default internal netmask and internal gateway addresses, if
necessary.
5. Click Add.
6. Repeat the process until you have added all of the nodes.
7. Click Save Changes to save the node configurations.
The Policy Secure gateway automatically enables the added nodes, even if they are
unreachable.

Documentation
  Deploying Two Nodes in an Active/Passive Cluster on page 780
Managing Network Settings for Cluster Nodes
To modify the network settings for a cluster or each individual node in a cluster, select
System > Network, and make your changes on the Network Settings pages. After you
create a cluster, these pages provide a list from which you can select the entire cluster
or a specific node to modify. When you save changes on a Network page, the settings
are saved for the specified cluster or cluster node. If you change network settings for an
entire cluster, they propagate to every node in the cluster.
To access a node-specific Network page select System > Clustering > Cluster Status, and
select the node’s name in the Member Name column.
Related Synchronizing the Cluster State on page 784

Documentation
 Adding Multiple Cluster Nodes on page 788

 Changing the IP Address of a Cluster Node on page 789
Changing the IP Address of a Cluster Node
Changing the IP address of a cluster while it belongs to a cluster is not supported. In order
to change the IP address, you must first remove it from the cluster, update the IP address
and then add it back.
NOTE: If you attempt to change the IP address of a node while it belongs to

a cluster, unpredictable results might occur.
For example:
1. Select System > Clustering > Cluster status.
2. Select the check box for the name of the node whose IP address you want to change.
3. Click Remove.

4. After the node is removed, sign in to that node, change its IP address and click Save
Changes.
5. In the main node, add the changed node to the cluster configurations.
6. Log in to the changed node and rejoin the cluster.
The following procedure is a model for changing both node IP addresses in an

active/passive cluster:
1. Select System > Clustering > Cluster status.
2. Click Delete Cluster.
3. Change the IP address of each node.
4. Log in to the main node and re-create the cluster, changing it from active/active to
active/passive and defining the internal and/or external VIP addresses.
5. Add the other node to the cluster configurations.
6. Log in to the passive node and add it to the cluster.

Documentation

 Deleting a Cluster on page 790
Deleting a Cluster
If you delete a cluster, all of the nodes begin running as standalone Policy Secure
gateway systems.
To delete a cluster:
1. In the admin console of an active cluster member, select System > Clustering > Cluster
Status.
2. Select the check box for each cluster node you want to delete.
3. Click the Remove Cluster button.
4. At the prompt, click Remove.
Related Managing Network Settings for Cluster Nodes on page 789

Documentation

Restarting or Rebooting Cluster Nodes
When you create a cluster of two or more Policy Secure gateways, the clustered Policy
Secure gateways act as a logical entity. When you reboot one of the clustered Policy
Secure gateways using either the serial console or the admin console, all Policy Secure
gateways in the cluster restart or reboot.

To reboot only one Policy Secure gateway in a cluster:
1. Select System > Clustering > Status to disable the Policy Secure gateway you want to
restart or reboot within the cluster.
2. Select Maintenance > System > Platform, or the serial console’s <Reboot this IC>,
<Shutdown this IC>, or <Restart Services> menu options under System Operations.
3. Reboot the Policy Secure gateway, then enable the Policy Secure gateway within the
cluster again.
The Policy Secure gateway reconciles session state with the Infranet Enforcer upon
restart or cluster failover. If the Infranet Enforcer is running ScreenOS 6.0r2 or later, a
Policy Secure gateway restart or failover does not interrupt network traffic of existing
sessions, as long as the restart or failover occurs within two minutes.

Documentation
 NSRP Clustering Considerations with the ScreenOS Enforcer on page 794

Summary: Admin Console Cluster Procedures
Table 121 on page 791 describes the information displayed on the Status tab and the
various management tasks you can perform, including disabling, enabling, and removing
a Policy Secure gateway node from a cluster.
Table 121: Cluster Status Page Information
GUI Element Description
Status Information labels Displays the cluster name, type, configuration, internal VIP, and
external VIP for an active/passive cluster.
Add Members button Click this button to specify a Policy Secure gateway you intend to
add to
the cluster. You can add multiple nodes at the same time.
Enable button Click this button to add a node that was previously disabled. When
you add a node, all state information is synchronized on the node.
Disable button Click this button to disable a node within the cluster. The node retains
awareness of the cluster but does not participate in state
synchronizations or receive user requests unless members sign in to
the node, directly.
Remove button Click this button to remove the selected node or nodes from the
cluster. After removal, the node runs in standalone mode.
Fail-Over VIP button Click this button to failover the VIP to the other node in the
active/passive cluster. Only available if cluster is configured as
active/passive.
Member Name column Lists all nodes belonging to the cluster. You can click on a node’s
name to modify its name and network settings.

Table 121: Cluster Status Page Information (continued)
GUI Element Description
Internal Address column Shows the internal IP address of the cluster member using Classless
Interdomain Routing (CIDR) notation.
External Address column Shows the external IP address of the cluster member using CIDR
notation. Note that this column shows only the external IP address
of the cluster leader unless you specify a different address for the
node on its individual network settings page, which is accessible by
clicking its name in the Member Name column. If you change the
external IP address on the Network > Network Settings page, the
change affects all cluster nodes.
Status column Shows the current state of the node:
 Green light/enabled—The node is handling user requests and

participating in cluster synchronization.
 Yellow light/transitioning—The node is joining the cluster.
 Red light/disabled—The node is not handling user requests or
participating in cluster synchronization.
 Red light/enabled, unreachable—The node is enabled but because
of a network issue, it cannot be reached.
Note: A node’s state is considered standalone when it is deployed
outside of a cluster or after being removed from a cluster.
Notes column Shows the status of the node’s connection to the cluster:
 OK—The node is actively participating in the cluster.

 Transitioning—The node is switching from the standalone state
to the enabled state.
 Unreachable—The node is not aware of the cluster. A cluster
member might be unreachable even when it’s online and can be
pinged. Possible reasons include: its password is incorrect, it doesn’t
have information about all cluster nodes, it’s configured with a
different group communication mode, it is running a different
service package version, or the machine is turned off.
Sync Rank column Specifies the synchronization order for nodes when a node rejoins a
cluster. Accepts sync ranks from 0 (lowest rank) to 255 (highest
rank). The highest rank takes precedence. If two nodes have identical
sync ranks, the alphanumeric rank of the member name is used to
determine precedence.
Note:
Update button Updates the sync rank after you change the precedence of the nodes
in the Sync Rank column.
Related Monitoring Clusters on page 793

Documentation

 Task Summary: Deploying a Cluster on page 776

Monitoring Clusters
You can monitor clusters using the standard logging tools provided by the Policy Secure
gateway. Specifically, you can use several cluster-specific SNMP traps to monitor
events that occur on your cluster nodes, such as:
 External interface down
 Internal interface down
 Disabled node
 Changed virtual IP address (VIP)
 Deleted cluster node (cluster stop)
NOTE: In general, it is desirable to configure your SNMP traps on a clusterwide

basis so that any given cluster node can send its generated traps to the right
target. Setting up clusterwide configuration for the traps is particularly
important when you also use a load balancer, because you might not know
which node is responsible for a specific operation. In that case, the load
balancer can independently determine which cluster node can manage an
administrative session.
You can use SNMP traps that are included in the Pulse Secure Standard MIB to monitor
these events. These traps include:
 iveNetExternalInterfaceDownTrap—Supplies type of event that brought down the

external interface.
 iveNetInternalInterfaceDownTrap—Supplies type of event that brought down the

internal interface.
 iveClusterDisableNodeTrap—Supplies the cluster name on which nodes are disabled,

along with a space-separated list of disabled node names.
 iveClusterChangedVIPTrap—Supplies the type of the VIP, whether external or internal,

and its value before and after the change.
 iveClusterDelete—Supplies the name of the cluster node on which the cluster delete
event was initiated.
These traps are always enabled and available in the MIB. You cannot disable the traps.

Documentation

 Troubleshooting Cluster Communication Problems on page 795

NSRP Clustering Considerations with the ScreenOS Enforcer
The Policy Secure gateway supports clustering of Infranet Enforcers in either

active/passive or active/active configurations (NSRP clustering). For active/active
support, dynamic IPsec enforcement must be configured with VSD interfaces for IPsec.
ScreenOS Release 6.1
or later is required. For more information see
The Policy Secure gateway pushes IPsec policies to the Infranet Enforcer as a
permanent configuration. If an IPsec policy is sent to an Infranet Enforcer in a cluster,
and one of the cluster members is down, the new policy is not transferred when the
peer reboots. The peer receives only RTO during coldstart, but the permanent IPsec
policy belongs to the Infranet Enforcer’s configuration, not RTO. In this case, you must
synchronize the
global-config from the peer manually on the rebooted device to ensure that the
configurations are in synchronization.
In topologies in which the Policy Secure gateway and two or more Infranet Enforcers are
clustered in either active/active or active/passive mode, IP address and serial number
configuration for each of these scenarios is different. Table 122 on page 794 describes
the placement of IP address and serial number information in each combination of
Policy Secure gateway and Infranet Enforcer clusters.
Table 122: IP Address and Serial Number Combinations
Combination Description
Single Policy Secure gateways with One Policy Secure gateway entry on Enforcers, points to
active/passive Screen OS Enforcers Policy Secure gateway Internal IP address.
One Screen OS Enforcer entry on Policy Secure gateway,

with serial numbers for both Enforcers.
Single Policy Secure gateways One Policy Secure gateway entry on ScreenOS Enforcers,
with points
active/active Screen OS Enforcers to Policy Secure gateway internal IP address.
One Enforcer entry on Policy Secure gateway, with serial
numbers
for both Screen OS Enforcers.
active/passive Policy Secure One Policy Secure gateway entry on Enforcer, points to
gateways with active/passive Policy Secure gateway cluster internal VIP address
ScreenOS Enforcers
numbers for both Screen OS Enforcers.
active/passive Policy Secure gateways with One Policy Secure gateway entry on Screen OS
Enforcers, points active/active Screen OS Enforcers to Policy Secure gateway cluster
internal VIP address.
One Screen OS Enforcer entry on Policy Secure

gateway, with serial numbers for both Enforcers.

Table 122: IP Address and Serial Number Combinations (continued)
Combination Description
active/active Policy Secure Two Policy Secure gateway entries on Enforcer, each entry
gateways with active/passive on Enforcer points to one of the IP address of a node in
Screen OS Enforcers the A/A cluster.

numbers for both Enforcers.
active/active Policy Secure gateways with Two Policy Secure gateway entries on
Enforcers, each entry on active/active Screen OS Enforcers Screen OS Enforcer points
to one of the IP address of a
node in the A/A cluster.
One Screen OS Enforcer entry on Policy Secure

gateway, with serial numbers for both Enforcers.
Related Troubleshooting Cluster Communication Problems on page 795

Documentation

Using the Policy Secure gateway with an SRX Series Cluster
UAC IPsec enforcement is not supported with the Policy Secure gateway and an SRX
Series active/active cluster.
Related Troubleshooting Cluster Communication Problems on page 795

Documentation

Troubleshooting Cluster Communication Problems
When problems occur with cluster communication, you may be directed by your Pulse
Secure Support representative to use the cluster node troubleshooting tools.
To use the cluster node troubleshooting tools:
In the admin console, select Maintenance > Troubleshooting > Monitoring > Node Monitor,
in Maintenance > Troubleshooting > Clustering Network Connectivity, and in Maintenance
> Troubleshooting > Clustering Group Communication.
You can use a built-in feature on the clustering Status page to identify the status of each
cluster node. Mouseover the Status light icon to display a tool tip containing a hexadecimal
number. The hexadecimal number is a snapshot of the status of the system. It is a bit
mask indicating a number of states as shown in Table 123 on page 795.
Table 123: Cluster Status
Value Meaning
0x000001 System is in standalone mode.
0x000002 System is in cluster disabled state.

Table 123: Cluster Status (continued)
Value Meaning
0x000004 System is in cluster enabled state.
0x000008 System is unreachable (because it is off line, has the wrong password, has
a different cluster definition, different version, or other problem).
0x00002000 The node owns the VIPs (on) or not (off).
0x000100 System is synchronizing its state from another node (initial synchronizing
phase).
0x000200 System is transitioning from one state to another.
0x00020000 Group communication subsystems at the local and remote nodes are
disconnected from each other.
0x00040000 Management interface (mgt0) is displayed disconnected.
0x00080000 Management gateway is unreachable for ARP ping.
0x000800 Interface int0 displays disconnected (no carrier).
0x001000 Interface int1 displays disconnected (no carrier).
0x002000 System is syncing its state to another node that is joining.
0x004000 Initial Synchronization as master or slave is taking place.
0x008000 System is the leader of the cluster.
0x010000 The spread daemon is running and the cache server is connected to it.
0x020000 The gateway on int0 is unreachable for ARP pings (see log file).
0x040000 The gateway on int1 is unreachable for ARP pings (see log file).
0x080000 Leader election is taking place.
0x100000 Server lifecycle process (dsmon) is busy.
0x200000 System is performing poststate synchronization activities.
0x30004  The spread daemon is running and the cache server is connected to it.
 The gateway on int0 is unreachable for ARP pings (see log file).
 System is in cluster enabled state.

Table 123: Cluster Status (continued)
Value Meaning
0x38004  The spread daemon is running and the cache server is connected to it.
 The gateway on int0 is unreachable for ARP pings (see log file).
 System is the leader of the cluster.
 System is in cluster enabled state.
Each code, as you see it in the system, may relate specifically to one state. However,
each code may represent a combination of states, and so the actual code does not appear
in Table 123 on page 795. Instead, the code you see in the system is the sum of several of
the hexadecimal numbers shown in Table 123 on page 795. You will need to factor out the
codes, as in the following example:
 0x38004—The rightmost digit (4) in this hexadecimal number corresponds to:
 0x000004—The system is in a cluster enabled state.
 0x38004—The digit in the fourth position from the right (8) corresponds to:
 0x008000—This system is the leader of the cluster.
 0x38004—The leftmost digit (3) in this hexadecimal number does not exist in the
table, which indicates that it corresponds to the sum of two other digits, in this case, 1
and 2, as shown in the following codes:
 0x020000—The gateway on int0 is unreachable for ARP pings (see log file).
 0x010000—The spread daemon is running and the cache server is connected to it.
Related  Monitoring Clusters on page 793

Documentation
Summary: Serial Console Cluster Procedures
If you are adding a factory-set Policy Secure gateway to a cluster, we recommend that
you use the serial console, which enables you to join an existing cluster during the
initialization process by entering minimal information. When a Policy Secure gateway
joins a cluster, it receives the cluster state settings, which overwrite all settings on a
machine with an existing configuration and provide new machines with the required
preliminary information.
You can also use a Policy Secure gateway’s serial console to disable the Policy Secure
gateway within a cluster. If the Policy Secure gateway is in a synchronization state, you
cannot access its admin console. Therefore, if you need to upgrade or reboot the Policy
Secure gateway, for example, you must first disable the Policy Secure gateway from a
cluster through its serial console.
Related Joining a Policy Secure gateway to a Cluster Through Its Serial Console on page 798
Documentation


Joining a Policy Secure gateway to a Cluster Through Its Serial Console
Before a configured or factory-set Policy Secure gateway can join a cluster, you must
make its identity known to the cluster.
NOTE:
 To add a Policy Secure gateway currently running as a standalone
machine to a cluster through its admin console, it must be running the
same or a more recent version service package on the same hardware
platform as the other members.
 If you add a Policy Secure gateway running an earlier version service

package to a cluster, the Policy Secure gateway automatically detects the
mismatch, gets the newer package from the cluster, and joins the cluster.
To add a Policy Secure gateway to a cluster through its serial console:
1. In the admin console of an existing cluster member, select System > Clustering >
Cluster Status and specify the Policy Secure gateway to add to the cluster.
2. Connect to the serial console of the machine you want to add to the cluster.
3. Reboot the machine and watch its serial console. After the system software starts, a
message appears stating that the machine is about to boot as a standalone Policy
Secure gateway and to press the Tab key for clustering options. Press the Tab key as
soon as you see this option.
NOTE: The interval to press the Tab key is five seconds. If the machine
begins to boot in standalone mode, wait for it to finish and then reboot
again.
4. Enter the number instructing the Policy Secure gateway to join an existing cluster.
5. Enter the requested information, including:
 The internal IP address of an active member in the cluster
 The cluster password, which is the password you entered when defining the cluster
 The name of the machine to add
 The internal IP address of the machine to add
 The netmask of the machine to add
 The gateway of the machine to add
The active cluster member verifies the cluster password and that the new machine’s
name and IP address match what you specified in the admin console. If the

credentials are valid, the active member copies all of its state data to the new cluster
member, including certificate, user, and system data.
6. Enter the number instructing the Policy Secure gateway to continue the join cluster
operation. When you see a message confirming that the machine has joined the
cluster, select System > Clustering > Cluster Status in the admin console of any active
cluster member to confirm that the new member’s Status is green, indicating that
the Policy Secure gateway is now an enabled node of the cluster (status is green).

Documentation

Disabling a Clustered Policy Secure gateway Using Its Serial Console
To disable a Policy Secure gateway within a cluster using its serial console:
1. Connect to the serial console of the machine you want to disable within the cluster.
2. Enter the number that corresponds to the Policy Secure gateway’s System Operations
option.
3. Enter the number that corresponds to the Disable Node option.
4. Enter y when the serial console prompts you to confirm that you want to disable the
node.
5. Verify that the Policy Secure gateway has been disabled (status is red) within the
cluster by selecting System > Clustering > Status in the admin console of any active
cluster member.

Documentation  Joining a Policy Secure gateway to a Cluster Through Its Serial Console on page 798



CHAPTER 23
Customizable Admin and End-User UIs
 Customizable Admin Console and End User Elements Overview on page 801
Customizable Admin Console and End User Elements Overview
The Policy Secure gateway enables you to customize a variety of elements in both the
admin console and the end-user interface. This section contains information about
which elements you can customize and where you can find the appropriate configuration
options.
You can customize the look and feel of the following user interface elements in the admin
console:
 Sign-in pages (default and custom)—You can customize the page that administrators
see when they sign into the admin console using settings in the Authentication > Signing
In > Sign-in Pages page. Using settings in this page, you can create welcome messages,
sign out messages and other instructions; control page headers; customize select error
messages; and create a link to a custom help page within the default Policy Secure
gateway sign-in page.
 UI look and feel—You can customize the header, background color, and logo displayed
in the admin console using settings in the Administrators > Admin Roles > Select Role
> General > UI Options page. You can also use settings in this page to enable or disable
the “fly out” hierarchical menus that appear when you mouse over one of the menus
in the left panel of the admin console.
 System utilization graphs—You can choose which system utilization graphs the
Policy Secure gateway displays on the opening page of the admin console using
settings in the System > Status > Overview page. You can also use settings in this
page to fine-tune the look and data within each of the graphs.
 User realm views—You can use customization options on the Users > User Realms
page to quickly view the settings that are associated with a specific user realm or set
of user realms.
 Administrator roles—You can delegate select responsibilities to other administrators

using settings in the Administrators > Admin Roles section of the admin console. In
doing so, you can restrict the visibility of certain options and capabilities to those other
administrators.

Customizable End-User Interface Elements Overview

You can customize the sign-in page that users see when they sign into the Policy Secure
gateway using settings in the Authentication > Signing In > Sign-in Pages page. Using
settings in this page, you can create welcome messages, sign out messages and other
instructions; control page headers; customize select error messages; and create a link
to a custom help page within the default Policy Secure gateway sign-in page. Or, you
can upload your own custom sign-in page to the Policy Secure gateway.

CHAPTER 24
Delegating Administrator Roles
 About Delegating Administrator Roles on page 803

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

 Deny the help desk administrators access to the remaining System pages and
Maintenance pages, which are used primarily for configuring system-wide settings
such as installing licenses and service packages, not for troubleshooting user problems.
NOTE: In addition to delegated administrator roles that you create, the

Policy Secure gateway also includes two basic types of administrators:
super administrators (.Administrators role), who can perform any
administration task through the admin console and read-only
administrators (.Read-only Administrators role), who can view—but not
change—the entire Policy Secure gateway configuration through the admin
console.
You can also create a security administrator role called “Help Desk Manager” and assign
users to this role who are responsible for managing the help desk administrators. You
might configure settings for the “Help Desk Manager” role to allow the Help Desk Manager
to create and delete their administrator roles. The Help Desk Manager might create
administrator roles that segment responsibilities by functional areas of the Policy Secure
gateway. For example, one administrator role might be responsible for all log monitoring
issues. Another might be responsible for all problems related to accessing protected
resources.
Related Creating Administrator Roles on page 804

Documentation
 Specifying Management Tasks to Delegate on page 805

Creating Administrator Roles
On the Administrators page, you can set default session and user interface options for
delegated administrator roles.
To create individual administrator accounts, you must add the users through the
appropriate authentication server (not through the role). For example, to create an
individual administrator account, select Authentication > Auth. Servers > Administrators
> Users in the admin console. For instructions on how to create users on third-party
servers, see the documentation that comes with that product.
To create an administrator role:
1. In the admin console, select Administrators > Admin Roles.
2. Do one of the following:
 Click New Role to create a new administrator role with the default settings.
 Select the check box for an existing administrator role and click Duplicate to copy
the role and its custom permissions. Note that you cannot duplicate the system
default roles (.Administrators and .Read-Only Administrators).

Chapter 24: Delegating Administrator Roles
3. Enter a Name (required) and Description (optional) for the new role and click Save
Changes.
4. Modify settings for the role according to the instructions in the sections that follow.
NOTE: If you select one of the Policy Secure gateway’s default

administrator roles (.Administrators or .Read-Only Administrators), you can
only modify settings in the General tab (since the default Policy Secure
gateway administrators roles always have access to the functions defined
through the System, Users, Administrators, and Resource Policies tabs).
You cannot delete the .Administrators and .Read Only Administrators roles
because they are default roles defined on the Policy Secure gateway.
Related Specifying Management Tasks to Delegate on page 805

Documentation

Specifying Management Tasks to Delegate
This topic describes how to delegate management tasks to various delegated

administrator roles. It includes the following information:
 Delegating System Management Tasks on page 805

 Delegating User and Role Management on page 806
 Delegating User Realm Management on page 806
 Delegating Administrative Management on page 806
 Delegating Resource Policy Management on page 807
Delegating System Management Tasks

Select Administrators > Admin Roles > Select Role > System to delegate various Policy
Secure gateway system management tasks to different administrator roles. When
delegating privileges, note the following:
 The Policy Secure gateway allows all administrators read-access (at minimum) to the
admin console home page (System > Status > Overview), regardless of the privilege
level you choose.
 The Policy Secure gateway does not allow delegated administrators write-access to
pages where they can change their own privileges. Only those administrator roles
that come with the system (.Administrators and .Read-Only Administrators) may
access these pages:
 Maintenance > Import/Export (Within this page, .Read-Only Administrators can

export settings, but cannot import them.)

 Maintenance > Archiving > Local Backups
Delegating User and Role Management

Select Administrators > Admin Roles > Select Role > Users > Roles to specify which user
roles the administrator role can manage. When delegating role management privileges,
note that:
 Delegated administrators can only manage user roles.
 Delegated administrators cannot create new user roles, copy existing roles, or delete
existing roles.
 If you allow the delegated administrator to read or write to any feature within a user
role, the Policy Secure gateway also grants the delegated administrator read access
to the Overview page for that role.
Delegating User Realm Management

Select Administrators > Admin Roles > Select Role > Users > Authentication Realms to
specify which user authentication realms the administrator role can manage. When
delegating realm management privileges, note the following:
 System administrators can manage only user realms.
 System administrators cannot create new user realms, copy existing realms, or delete
existing realms.
 If you allow the system administrator to read or write to any user realm page, the
Policy Secure gateway also grants the system administrator read-access to the
General page for that role.
Delegating Administrative Management

Select Administrators > Admin Roles > Select Roles > Administrators to specify which
system administrator roles and realms the security administrator role can manage. When
delegating security administrative privileges, note the following:
 The security administrator role provides control over all administrative roles and realms.
 You can give a security administrator control exclusively over administrator roles, over
administrator realms, or over both.
 You can restrict or grant the security administrator the permission to add and delete
administrator roles and administrator realms.

Delegating Resource Policy Management

Select Administrators > Admin Roles > Resource Policies to specify which user resource
policies the administrator role can manage. When delegating resource policy management
privileges, note that delegated system administrators cannot modify the following
characteristics of resource policies:
 The resource itself (that is, the IP address/netmask).
 The order in which the Infranet Enforcer evaluates the resource policies.
Related About Delegating Administrator Roles on page 803

Documentation

Defining Role Management Privileges for an Administrative Role
To define role management privileges for an administrative role:
2. Select the administrator role that you want to modify.
3. Select the Users > Roles tab (this is the default).
4. Under Delegate user roles, select the option button for Administrator can manage ALL
roles or Administrator can manage SELECTED roles. If you only want to allow the
administrator role to manage only selected user roles, select those roles in the Available
roles list and click Add.
5. Specify which user role pages the delegated administrator can manage by selecting
one of the following options:
 Write All—Specifies that members of the administrator role can modify all user role
pages.
 Custom Settings—Allows you to choose administrator privileges (Deny, Read, or

Write) for individual user role pages.
6. Under Delegate as read-only roles, select the user roles that you want to allow the
administrator to view but not manage.
NOTE: If you specify both write access and read-only access for a feature,
the Policy Secure gateway grants the most permissive access. For
example, if you select Administrators can manage ALL roles under
Delegated user roles, and then you select the “Users” role in the
Delegate as read-only roles section, the Policy Secure gateway allows
the delegated administrator role full management privileges to the
“Users” role.


Documentation

Defining Realm Management Privileges for an Administrative Role
To define realm management privileges for an administrative role:
2. Select the administrator role to modify.
3. Select Users > Authentication Realms.
4. Under Delegate user realms, select the option button for Administrator can manage
ALL realms or Administrator can manage SELECTED realms. If you only want to allow
the administrator role to manage selected user roles, select those roles in the Available
realms list and click Add.
5. Specify which user role pages the delegated administrator can manage by selecting
one of the following options:
 Write All—Specifies that members of the administrator role can modify all user role
pages.
 Custom Settings—Allows you to choose administrator privileges (Deny, Read, or

Write) for the individual user role pages.
6. Under Delegate as read-only roles, select the user authentication realms that you
want to allow the administrator to view but not modify.
NOTE: If you specify both write access and read-only access for an
authentication realm page, the Policy Secure gateway grants the most
permissive access. For example, if you select Administrators can manage
ALL realms under Delegated user realms, and then select the “Users”
role in the Delegate as read-only realms section, the Policy Secure
gateway allows the delegated administrator role full management
privileges to the “Users” realm.

Documentation


Defining Security Administrator Privileges
To define security administrator privileges:
1. In the admin console, select Administrators > Admin Roles > Select Role >
Administrators.
2. Select the Manage ALL admin roles check box.
3. Select the Administrators tab.
4. To allow the security administrator to add and delete admin roles, select the Allow
Add/Delete admin roles check box. This allows the security administrator the ability
to create administrator roles, even if the security administrator is not part of the
.Administrators role.
5. To indicate the level of access to allow the security administrator role to set for system
administrators for each major set of admin console pages (General, System tasks,
Users, Administrators, and Resource Policies) choose one of the following options:
 Deny All—Specifies that members of the security administrator role cannot see or
modify any settings in the category.
 Read All—Specifies that members of the security administrator role can view, but
not modify, all settings in the category.
 Write All—Specifies that members of the security administrator role can modify all
settings in the category.
 Custom Settings—Allows you to pick and choose security administrator privileges

(Deny, Read, or Write) for the individual features within the category.
6. Select the Manage ALL admin realms check box.
7. To allow the security administrator to add and delete admin realms, check the Allow
Add/Delete admin realms check box. This allows the security administrator the ability
to create and delete administrator realms, even if the security administrator is not
part of the .Administrators role.
8. To indicate the level of realm access to allow the security administrator role to set
for system administrators for each major set of admin console pages (General,
Authentication Policy, and Role Mapping,) choose one of the following options:
 Deny All—Specifies that members of the security administrator role cannot see or
modify any settings in the category.
 Read All—Specifies that members of the security administrator role can view, but
not modify, all settings in the category.
 Write All—Specifies that members of the security administrator role can modify all
settings in the category.
 Custom Settings—Allows you to choose security administrator privileges (Deny,

Read, or Write) for the individual features within the category.

NOTE: All administrators that can manage admin roles and realms have
at least read-only access to the admin role’s Name and Description and
to the realm's Name and Description, as displayed on the General page.

Documentation

Defining General System Administrator Role Settings
Defining Default Options for Administrator Roles
To define the default options for all delegated administrator roles:
2. Click Default Options.
3. Modify settings in the Session Options and UI Options. These become the new defaults
for all new delegated administrator roles.
Managing General Role Settings and Options
To manage general role settings and options:
1. In the admin console, select Administrators > Admin Roles > Select Role > General
> Overview.
2. (Optional) Create a label for the delegated administrator role using the Name and
Description fields.
3. Under Options, select one of the following:
 Session Options—To apply the settings configured in the General > Session Options
tab to the role.
 UI Options—To apply the settings configured in the General > UI Options tab to the
role.
4. Click Save Changes to apply the settings to the role.
Specifying Access Management Options for the Role
Use the Administrators > Admin Roles> General > Restrictions tab to specify access
management options for the role. The Policy Secure gateway does not map
administrators to this role unless they meet the specified restrictions.
To specify access management options for the role:
1. In the admin console, select Administrators > Admin Roles> Select Role > General>
Restrictions.

2. Click the tab for the option you want to configure for the role. Then configure in
accordance with role configuration procedures.

Documentation  Specifying Management Tasks to Delegate on page 805



CHAPTER 25
Deployments with IDP
 About IDP Technology on page 813

 IDP Deployment Scenarios Overview on page 815
 Understanding Pulse Policy Secure Deployments with IDP Devices on
page 817
 Activating IDP for the ScreenOS or Junos Enforcer on page 820
 Managing Interoperation with IDP Devices on page 820
 Defining Automatic Response Sensor Event Policies on page 823
 Identifying and Managing Quarantined Users Manually on page 824
 Using Role-Based Policies to Monitor User Activity on page 825
About IDP Technology
Securing intranet work application and resource traffic is vital to protecting the network.
You can add levels of application security to detect internal threats coming from users
who are authenticated through the Policy Secure gateway by integrating a Policy
Secure gateway with a Juniper Networks Intrusion Detection and Prevention (IDP)
Sensor.
The Policy Secure gateway supports standalone IDP and IDP through the Juniper
Networks ISG Series Integrated Security Gateways Infranet Enforcer with the IDP
Security Module (supported in ScreenOS Release 6.2 or greater). With UAC Release
3.1, you can use SRX Series Services Gateway IDP with Junos 10.0 (SRX
3400/3600/5600/5800). With UAC Release 4.1 and JunosOS Release 11.1,
Coordinated Threat Control (CTC) is supported on all SRX series devices.
The IDP sensor monitors the network on which the IDP system is installed. The sensor’s
primary task is to detect suspicious and anomalous network traffic based on specific
rules defined in IDP rulebases.The IDP device provides the following types of protection
(some of which depend upon the specific configuration):
 Protects against attacks from user to application.
 Detects and blocks most network worms based on software vulnerabilities.
 Detects and blocks non-file-based Trojan Horses.

 Detects and blocks effects of spyware. adware, and key loggers.
 Detects and blocks many types of malware.
 Detects and blocks zero day attacks through the use of anomaly detection.
NOTE: An IDP Sensor can send logs to one Policy Secure gateway
appliance only. However, a Policy Secure gateway appliance can receive
logs from more than one IDP Sensor.
Using the Policy Secure gateway’s admin console, you can configure and manage
interaction attributes between the Policy Secure gateway and an IDP, including the
following:
 (With standalone IDP) Global configuration parameters such as the IDP hostname or
IP address, the TCP port over which the sensor communicates with the Policy Secure
gateway, and the one-time password the Policy Secure gateway and IDP use to
authenticate with one another.
 Various levels of attack severity warnings and the action that the Policy Secure gateway
takes
If you are using standalone IDP Release 5.0 or later or ISG-IDP Release 6.3 or later, you
can configure IDP policies based on user roles with Network and Security Manager (NSM).
The IDP sits within the network and monitors traffic from endpoints that are connected
through the Policy Secure gateway. You can position the IDP in-line, or you can
configure the IDP in sniffer mode.
After the Policy Secure gateway connects with the IDP sensor, the Policy Secure
gateway registers all of the IP addresses to be monitored for potential threats. With
standalone IDP, you enter the IP addresses to monitor.
Any abnormal events detected by the IDP Sensor are reported to the Policy Secure
gateway, which you configure to take appropriate action based on the severity level of
the reported events. The IDP Sensor performs reporting functions to allow you to
determine what IP address within the network has launched the attacks in addition to
any normal logging the IDP has been configured to undertake.
With a large number of connected users IDP can overwhelm the Policy Secure gateway
with more alert logs than it can process. In this situation, the number of logs sent by
the IDP to the Policy Secure gateway can be controlled by decreasing the severity level
setting in the IDP connection settings.
With IDP deployments using the Infranet Enforcer and the IDP Security Module, the
Infranet Enforcer can send messages to OAC or the Pulse debug log.
Related IDP Deployment Scenarios Overview on page 815

Documentation

page 817

Chapter 25: Deployments with IDP
IDP Deployment Scenarios Overview
Three possible deployment scenarios are shown in the following figures.
In Figure 243 on page 815 the standalone IDP is located within the internal network. All
network traffic originating from endpoints that are registered with the IDP is monitored.
You can deploy IDP in sniffer mode, or inline mode. You can use transparent mode or
route mode with an inline mode configuration. In the first deployment example, the IDP
does not monitor IPsec traffic from the user to protected resources.
Figure 243: IC Series and Standalone IDP Topology
To monitor all IPsec traffic from users to protected resources, deploy the IDP behind the
Infranet Enforcer, as shown in Figure 244 on page 816.

Figure 244: IC Series and ISG-IDP Topology
Figure 245 on page 816 depicts IDP in a Layer 2 network. The device serves as a policy
enforcement point and controls user access based on Policy Secure gateway policy
decisions.
Figure 245: IDP in a Layer 2 Deployment
You can deploy up to ten IDP devices in a network with the Policy Secure gateway.
Performance is based on how rapidly sessions are created or changed, the number of
events that IDP sends to the Policy Secure gateway, and the efficiency of the network
links that connect the devices. IDP devices must be connected over a high-speed LAN
link.
In a clustering environment, only one member of a Policy Secure gateway cluster

exchanges information with an IDP sensor. If the connected Policy Secure gateway fails
or is shut down, another cluster member will assume the load.

Related About IDP Technology on page 813

Documentation

page 817
Understanding Pulse Policy Secure Deployments with IDP Devices
This topic provides and overview of deployments with IDP devices. It includes the following
content:
 About IDP Devices on page 817

 Coordinated Threat Control Overview on page 817
 Deployments with IDP Series Devices on page 818
 Deployments with IDP-Enabled Infranet Enforcers on page 818
 Monitoring IDP-Reported Events on page 819
About IDP Devices

The IDP Sensor is a powerful tool to counteract users who initiate attacks. The IDP sensor
monitors the network on which the IDP system is installed. The IDP sits within the network
and monitors traffic from endpoints that are connected through the Policy Secure
gateway. You can position the IDP in-line, or you can configure the IDP in sniffer mode.
The sensor’s primary task is to detect suspicious and anomalous network traffic based
on specific rules defined in IDP rulebases.
The IDP device provides the following types of protection (some of which depend upon
the specific configuration):
 Protects against attacks from user to application.
 Detects and blocks most network worms based on software vulnerabilities.
 Detects and blocks non-file-based Trojan Horses.
 Detects and blocks effects of spyware, adware, and key loggers.
 Detects and blocks many types of malware.
 Detects and blocks zero day attacks through the use of anomaly detection.
Coordinated Threat Control Overview

In a coordinated threat control deployment, the IDP device reports abnormal events to
the Policy Secure gateway. The attack logs sent by the IDP device include the source
and destination IP addresses and port numbers of the attacking host, and the resource
against which the attack was launched, along with the attack identifier, severity of the
attack, and the time at which the attack was launched.

The Policy Secure gateway displays the attack information received from the IDP sensor
on the Active Users page. Based on the attackers IP address and port number, the
Policy Secure gateway can uniquely identify the user’s session.
When you learn that an attack has been launched by an active user, you can disable the
user’s account, end the user’s session, or remediate to a different role. You can choose
automatic or manual actions for attacks detected by the IDP sensor. For manual action,
you look up the information available on the Active Users page and decide on an action.
For automatic action, you configure the action in advance when you define IDP policies.
The Policy Secure gateway displays an error message to the user whose account has
been disabled indicating the reason.
Deployments with IDP Series Devices

You can deploy Policy Secure gateways with IDP Series devices in coordinated threat
control deployments and user-role-based IDP policy deployments. User-role-based
IDP policy deployments require IDP Series 5.0 or later. To display the version of an
associated IDP device in the Pulse Policy Secure admin console, select System >
Configuration > Sensors.
NOTE: An IDP Sensor can send logs to one Policy Secure gateway appliance
only. However, a Policy Secure gateway appliance can receive logs from
more than one IDP Sensor.
Using the Policy Secure gateway’s admin console, you can configure and manage
interaction attributes between the Policy Secure gateway and an IDP Series device,
including the following:
 Global configuration parameters such as the IDP hostname or IP address, the TCP port
over which the sensor communicates with the Policy Secure gateway, and the one-
time password the Policy Secure gateway and IDP use to authenticate with one
another.
 Various levels of attack severity warnings and the action that the Policy Secure gateway
takes
 IP addresses to monitor.
With a large number of connected users IDP can overwhelm the Policy Secure gateway
with more alert logs than it can process. In this situation, the number of logs sent by
the IDP to the Policy Secure gateway can be controlled by decreasing the severity level
setting in the IDP connection settings.
NOTE: With UAC Release 4.0, licensing is no longer required to use IDP in a
UAC deployment.
Deployments with IDP-Enabled Infranet Enforcers

The Policy Secure gateway also supports IDP through the Juniper Networks ISG Series
Integrated Security Gateways Infranet Enforcer with the IDP Security Module (supported
in ScreenOS Release 6.2 or greater). With UAC Release 3.1, you can use SRX Series

Services Gateway

IDP with Junos 10.0 (SRX 3400/3600/5600/5800). With UAC Release 4.1 and JunosOS
Release 11.1, coordinated threat control is supported on all SRX series devices.
Unlike a standalone IDP which requires manual configuration on the IDP to allow
communication with the IC, the ScreenOS Enforcer or the Junos Enforcer use the existing
communication channel with the Policy Secure gateway.
If you are using integrated IDP with the ISG-1000 or ISG-2000, see
If you are using Junos IDP with JunosOS Release 10.0, see Junos OS Initial Configuration
Guide for Security Devices. ISG-IDP and CTC are configured the same on the Policy
Secure gateway.
When ISG-IDP or Junos IDP are activated, ScreenOS or Junos notifies the Policy Secure
gateway when an attack event is detected from any endpoint. To avoid overwhelming
the SSH connection between the Policy Secure gateway and the Infranet Enforcer, the
number of attack notifications is limited to ten per second. If additional attacks are
detected, the Infranet Enforcer holds an additional ten notifications in a queue.
ISG-IDP or Junos devices attached to any node in a cluster may send messages regarding
sessions attached to any node in the cluster.
There is a Use IDP module as Sensor check box on the Infranet Enforcer admin console
page. If you select the check box and there is no IDP module or if the Enforcer is not
running a compatible version, the Policy Secure gateway logs an appropriate message.
With IDP deployments using the Infranet Enforcer and the IDP Security Module, the
Infranet Enforcer can send messages to OAC or the Pulse debug log.
Monitoring IDP-Reported Events

After the IDP Sensor has been set up, you can specify the events you want the IDP to
watch for and the actions that the Policy Secure gateway takes once a particular event
has been noted and reported.
In two locations on the Policy Secure gateway, you can specify actions to be taken in
response to users that perform attacks:
 Sensor Event policies page—Define the policy on this page to generate an automatic
response to users who perform attacks.
 Users page—Manually identify and quarantine or disable users on the Active Users
page, which lists users who have performed attacks.
Related Managing Interoperation with IDP Devices on page 820

Documentation
 IDP Deployment Scenarios Overview on page 815


Activating IDP for the ScreenOS or Junos Enforcer
To activate ISG-IDP or Junos IDP on the Policy Secure gateway:
1. Select UAC > Infranet Enforcer in the Policy Secure gateway admin console.
2. Select the name of the Enforcer on which you want to activate IDP.
3. Select the Use IDP Module as Sensor check box. Additional options are presented.
4. Select For sessions provisioned for this Enforcer only to limit monitored sessions to
this device. This is applicable in an IF-MAP Federation network.
5. Select 1 - INFO through 5 - Critical from the Severity menu. The severity filter allows
you to specify the level of attacks that the Infranet Enforcer reports to the Policy
Secure gateway. For example, if you select 3, only level 3 attacks or higher are
reported.
Related IDP Deployment Scenarios Overview on page 815

Documentation

page 817
Managing Interoperation with IDP Devices
The Sensors tab allows you to specify the system settings the Policy Secure gateway
uses to establish a connection to an IDP device. Select System > Configuration >
Sensors > Sensors. The main Sensor page displays the sensor, the network address, the
state (enabled), the version, and the status of any configured sensors. The following
sections describe tasks related to configuring and managing interaction between the
Policy Secure gateway and an IDP Sensor:
 Configuring Communication with an IDP Device on page 820

 Enabling or Disabling IDP Sensors on page 821
 Reconnecting to an IDP Sensor on page 822
 Refreshing and Displaying the Connection Status on page 822
 Deleting an IDP Sensor Entry on page 822
Configuring Communication with an IDP Device
To configure communication with an IDP device and a IDP log monitoring policy:
1. In the admin console, select System > Configuration > Sensors.
NOTE: To use the IDP sensor with the Policy Secure gateway you must
enable logging for the applicable policies.
2. Click New Sensor. The admin console displays the New Sensor page.

3. Under Sensor Properties, specify the following information:
 Name—A name the Policy Secure gateway uses to identify the new connection
entry.
 Hostname—The hostname or IP address of the IDP Sensor to which the Policy

Secure gateway connects in order to receive application and resource attack alert
messages.
 Port—The TCP port on the IDP Sensor to which the Policy Secure gateway
listens when receiving application and resource attack alert messages.
 One-time password—The encrypted password the Policy Secure gateway uses

when conducting the initial Transport Layer Security (TLS) handshake with the IDP
Sensor. You must enter the encrypted Policy Secure gateway OTP password as
displayed on the IDP ACM configuration summary screen.
NOTE: The hostname, TCP port, and one-time password must already
be configured on the IDP Sensor before this configuration can be
successful.
4. Under Monitoring Options, specify IP addresses to monitor and the minimum alert
severity level the IDP Sensor records and submits to the Policy Secure gateway:
 In the Addresses to Monitor field, specify individual IP addresses and address ranges,
one entry per line. IDP reports attack information only for the IP addresses that you
specify. For IDP to report all events to the Policy Secure gateway, enter 0.0.0.0/0.
For IDP to report only selected events, enter <default> to permit IDP to report
events for events with source IPs that have an active user session on the Policy
Secure gateway, and
/or enter one or more addresses or address ranges for any endpoint that you want
the IDP sensor to report.
NOTE: With ISG-IDP or Junos IDP, you do not need to specify which IP
addresses to monitor. The Infranet Enforcer monitors all IP address for
which auth tables exist.
 Select one of the severity options available in the Severity filter drop down list. The
severity level is a number on a scale from 1 to 5, where 1 is informational and 5 is
critical. This option represents the severity of messages the IDP should send to the
Enabling or Disabling IDP Sensors

To enable or disable existing IDP Sensor entries on the Policy Secure gateway:
2. Select the check box for one or more IDP Sensor entries to enable or disable.
3. Click Enable or Disable to enable or disable the specified IDP Sensor entries,
respectively.

Reconnecting to an IDP Sensor

When the connection to an IDP Sensor is down, you can use the admin console on the
Policy Secure gateway to re-establish the connection. You can also use the admin
console to refresh the status of existing connections between the Policy Secure
gateway and the IDP Sensor.
To re-establish communication with an IDP Sensor, you must generate a new One-time
Password.
To reconnect to an associated IDP Sensor:
2. Select the check box next to the IDP Sensor to which you want to reconnect.
3. Click Reconnect.
The admin console displays a message indicating that the Policy Secure gateway is
currently attempting to re-establish connection to the specified IDP Sensor. This
page automatically refreshes each second during the reconnection process.
Otherwise, the connection status page automatically refreshes once every 30
seconds.
Refreshing and Displaying the Connection Status

To refresh and display the connection status for the specified IDP Sensor:
2. Select the check box for one or more IDP Sensor entries to display current connection
status.
3. Click Refresh.
Deleting an IDP Sensor Entry

You can delete existing IDP Sensor entries that define a connection between the Policy
Secure gateway and an IDP Sensor.
To delete one or more existing IDP Sensor entries from the Policy Secure gateway:
2. Select the check box for the IDP Sensor entry or entries to delete.
3. Click Delete, then confirm that you want to delete the sensor entry or entries.
Related Defining Automatic Response Sensor Event Policies on page 823

Documentation


Defining Automatic Response Sensor Event Policies
Select System > Configuration > Sensors > Sensor Event Policies. To specify one or more
rules specify the action(s) the Policy Secure gateway takes when it receives attack
alert messages from an IDP Sensor.
To create a new IDP rule:
1. In the admin console, select System > Configuration > Sensors > Sensor Event Policies.
2. On the Sensor Event Policies page, click New Rules.
3. On the Juniper IDP Rule page, in the Rule: On Receiving... section:
 Select an existing event from the Event list.
 Click Events to edit an existing event or create a new type of event and add it to the
options in the Events list:
a. Specify a name for the event.
b. Populate the Expressions field by manually entering expressions or by selecting

one or more clauses from the Expressions Dictionary. Click Insert Expression.
For example, to check for all critical/highest severity level attacks, enter the
following expression:
idp.severity >= 4
To check for all critical/highest severity level attacks for HTTP traffic, enter the
following expression:
idp.severity >= 4 AND idp.attackStr = “*HTTP*”
c. When you finish entering the expressions you want to apply to this event, click Add
Expression.
d. Click Close.
4. In the Count this many times section, specify a number between 1 and 256 to determine
the number of times an event occurs before action is taken.
5. In the ...then perform this action section, specify one of the following actions:
 Ignore (just log the event)—Specifies that the Policy Secure gateway should log
the event, but take no further action against the user profile to which this rule
applies. This option is best used to deal with very minor “informational” attack
alert messages that come from the IDP Sensor.
 Terminate User Session—Specifies that the Policy Secure gateway should

immediately terminate the user session and require the user to sign in to the
Policy Secure gateway again.
 Disable user account—Specifies that the Policy Secure gateway should disable
the user profile associated with this attack alert message, thus rendering the
client unable to sign in to the Policy Secure gateway until the administrator re-
enables the user account.

(This option is applicable only for users who have a local Policy Secure gateway
user account.)
 Replace user’s role with this one—Specifies that the role applied to this user’s
profile should change to the role you select from the associated list. This new role
remains assigned to the user profile until the session terminates. This feature allows
you to assign a user to a specific controlled role of your choice, based on specific
IDP events. For example, if the user performs attacks, you might assign the user to
a restricted role that limits the user’s access and activities.
 Select to make this role assignment:
 Permanent—User remains in the quarantined state across subsequent logins

until the administrator releases the user from the quarantined state.
 For this session only—Default. User can log in to another session.
 Policy applies to ALL roles—To apply this policy to all users.
 Policy applies to SELECTED roles—To apply this policy only to users who are
mapped to roles in the Selected roles list. Be sure to add roles to this list from the
Available roles list.
 Policy applies to all roles OTHER THAN those selected below—To apply this policy
to all users except for those who are mapped to the roles in the Selected roles list.
Make sure to add roles to this list from the Available roles list.

Documentation

Identifying and Managing Quarantined Users Manually
When the Policy Secure gateway quarantines a user based on an attack, you can display
and manage the states by locating the user link in the Active Users page.
 A small warning icon is displayed in front of the username.
 The linked username.
 An enabled Quarantined option button on the specific user’s page. If the user is not
quarantined, the option button is disabled.
To manage quarantined users:
1. Identify quarantined users at System > Status > Active Users.
2. Locate the quarantined user and click on the username link. The user page opens,
showing a number of options.

3. Click Disabled to disallow a user from authenticating.
4. Click Quarantined to leave a user in a quarantined state. The Quarantined option is

enabled only if the user is already quarantined.
NOTE: The Policy Secure gateway assigns quarantined users to the

quarantined role, regardless of their login realm.
6. To re-enable previously quarantined or disabled users, select Authentication > Auth.

Servers > Select Server > Users and click the link for the given user.
NOTE: You can also disable users from this location.
7. Click Enabled to release the user from quarantine.
All Sensor events are logged at System > Log/Monitoring > Sensors > Log.

Documentation
 Defining Automatic Response Sensor Event Policies on page 823

Using Role-Based Policies to Monitor User Activity
If you are using IDP Release 5.0 or greater or ScreenOS ISG-IDP Release 6.3 or greater,
you can add enhanced user management capabilities to your Policy Secure gateway IDP
deployment. This feature is supported for endpoints using OAC, Pulse, and users who
connect with agentless access. Junos IDP does not support this feature at this time.
Using Network and Security Manager (NSM), you can configure application policies that
are role-based to monitor endpoints and enforce IDP rules.
When a user session is established on the Policy Secure gateway, the Policy Secure
gateway pushes session information including IP address, username and the roles to
which the user is assigned to the IDP. The session information allows IDP to apply
policies based on user roles, or on the username which is added to the IDP log.
Since role selection for a user can be based on the results of Host Checker policies, you
can set policies that are based on Host Checker results. For example, if a user is assigned
to a restrictive role based on the results of a Host Checker policy requiring a particular
instant messaging software patch, you can restrict instant messenger traffic for that role.
The Policy Secure gateway keeps the IDP device updated when a user’s role changes
or when a session is deleted. IDP’s application policy enforcement reflects the most
currently available information about a user.

For OAC users who authenticate via Layer 2, there is a short gap in role-based application
policy enforcement until the endpoint obtains an IP address. During this period, IDP
policies based on source IP are enforced.
If role-based policies are less restrictive than IP address based policies, some users could
be inadvertently blocked during this period. Once session information is obtained about
the endpoint IDP re-evaluates the endpoint and applies the less restrictive policies.
If role-based policies are more restrictive than IP address based policies, IDP cannot
apply the more restrictive policies, and an endpoint could engage in potentially damaging
behavior prior to session information being sent.
If you are using the Policy Secure gateway and IDP in a network that employs IF-MAP
client and server Federation, and IDP detects an attack that is attributed to a session,
IDP informs the Policy Secure gateway about the attack. Upon notification, the Policy
Secure gateway publishes the information to any attached IF-MAP servers. The IF-MAP
server notifies the Policy Secure gateway that originally published the session and the
Policy Secure gateway takes the appropriate action based on the applicable Sensor
Event Policies.
Related About IDP Technology on page 813

Documentation  Defining Automatic Response Sensor Event Policies on page 823

 Understanding Coordinated Threat Control in an Federated Deployment on page 467

PART 5
Appendix
 Policy Secure gateway 4500 and 6500 on page 829
 Using the IC6500 FIPS Appliance (Hardware FIPS) on page 835
 Custom Expressions and System Variables Reference on page 843


CHAPTER 26
Policy Secure gateway 4500 and 6500
 IC Series 4500 and 6500 Overview on page 829

 Understanding Device Status LED Behavior on page 830
 Understanding Ethernet Port LED Behavior on page 831
 Replacing a Cooling Fan on page 832
 Replacing a Hard Drive on page 833
 Replacing a Power Supply on page 834
IC Series 4500 and 6500 Overview
This topic describes IC4500 and IC6500 hardware. It includes the following information:
 Standard Hardware on page 829

 IC Series 6500 Field-Replaceable Units on page 829
Standard Hardware
The IC4500/6500 chassis features the following hardware components:
 Console port—You can use the console port to initially set up the IC4500/6500 before
you fully integrate it as the secure gateway to your internal network. You can also use
the console port to perform certain configuration and clustering tasks after the Policy
Secure gateway begins operating.
 Internal and external Ethernet ports—The IC4500/6500 primary connections to the

corporate network and the outside world are the internal and external Ethernet ports.
To configure the internal and external interfaces select System > Network in the
administrator admin console.
The IC4500 supports a two-node active/active or active/passive cluster. The IC6500

supports up to four-node clusters.
IC Series 6500 Field-Replaceable Units

The IC6500 chassis features three types of field-replaceable units (FRUs) that you can
add or replace. The FRUs are “hot-swappable,” meaning you do not have to first shut
down the IC6500 before adding or replacing any of the FRUs. The IC4500 has a
“cold-swappable” power supply.

For safety information, refer to the Juniper Networks Products Safety Guide available on
the Juniper Networks Support site.
 Hard disks—The IC6500 ships with one hard disk, however, you can add an optional
second hard disk to the IC6500 chassis to offer component redundancy and help
minimize Policy Secure gateway down time. When a second (redundant) hard disk is
installed, it maintains an exact copy of the software image and configuration
information on the working hard disk. Therefore, if the working hard disk fails, the
redundant hard disk immediately assumes responsibility for all Policy Secure gateway
operations. This function
is referred to as the Redundant Array of Independent Disks (RAID) mirroring process.
NOTE: The IC6500 hard disk modules are hot-swappable. You must make
sure that the Policy Secure gateway finishes booting and is operating
correctly before removing, replacing, or upgrading a hard disk module.
After you insert a new hard disk module, you must wait until the RAID
mirroring process is completely finished—which takes approximately 40
minutes—before rebooting or turning off the Policy Secure gateway.
 Power supplies—The IC6500 ships with one AC power supply installed in the back of
the chassis. You can add an optional second power supply to support redundancy and
load-sharing features. In addition, if you need to replace one of the power supplies,
you can “swap” the faulty power supply for a replacement while the optional second
power supply assumes responsibility for the entire power load, thus avoiding a situation
where you have to power off the Policy Secure gateway before replacing the
removable unit.
 Cooling fans—The IC6500 ships with two cooling fans installed in the back of the
chassis. If you need to replace one of the cooling fans, you can “swap” the faulty fan
for a replacement during operation in a matter of moments. You can purchase additional
cooling fans from your vendor when you order your IC6500, or you can purchase them
in the future to replace faulty or failed cooling fans, as necessary, in the future.
Related Understanding Device Status LED Behavior on page 830

Documentation

Understanding Device Status LED Behavior
Startup takes approximately one minute to complete. If you want to turn the device off
and on again, we recommend you wait a few seconds between shutting it down and
powering it back up.
There are three device status LEDs located on the left-side of the front panel:
 Power

Chapter 26: Policy Secure gateway 4500 and
6500
 Hard disk access
 Fault
Table 124 on page 831 lists the name, color, status, and description of each device status
LED.
Table 124: Device Status LEDs
Name Color State Description
POWER Green Off Device is not receiving power
On Steady Device is receiving power
HARD DISK Yellow Off Hard disk is idle

ACCESS
Blinking Hard disk is being accessed
FAULT Red Off Device is operating normally
Slow blinking Power supply fault
Fast blinking Fan failure
Solid Thermal failure
Related IC Series 4500 and 6500 Overview on page 829

Documentation

Understanding Ethernet Port LED Behavior
The Ethernet port LEDs show the status of each Ethernet port.
Table 125: 4-Port Copper Gigabit Ethernet LEDs (available on IC4500

and IC6500)
LED Color and State Description
Link/Activity Green Link
Blinking green Activity

Table 125: 4-Port Copper Gigabit Ethernet LEDs (available on IC4500

and IC6500) (continued)
Link Speed Off 10 Mbps
Green 100 Mbps
Yellow 1 Gbps

Documentation

Replacing a Cooling Fan
The IC6500 ships with two cooling fans installed in the back of the chassis. If you need
to replace one of the cooling fans, you can “hot-swap” the faulty fan for a replacement
during operation in a matter of moments. You can purchase additional cooling fans from
your authorized Juniper reseller, or you can purchase them in the future to replace faulty
or failed cooling fans, as necessary.
To remove and install a cooling fan module:
1. To release the cooling fan module, do one of the following:
 Press and slide the release trigger toward the center of the cooling fan module
 Loosen the thumbscrews
2. Grasp the cooling fan module and carefully pull it out.
CAUTION: Once you remove the cooling fan module, it is important that
you replace it with a replacement cooling fan. The second fan is required
for proper air flow across the chassis’s internal components; it is not a
redundant fan.
3. Line the a cooling fan module up with an empty cooling fan port on the back of the
chassis.
4. Slowly slide the module into the chassis until it clicks into place.
5. If your cooling fan is equipped with thumb screws, tighten the screws.

Chapter 26: Policy Secure gateway 4500 and 6500

Documentation

Replacing a Hard Drive
The IC6500 ships with two standard hard drives to offer component redundancy and
help minimize down time. The second (redundant) hard disk maintains an exact copy of
the software image and configuration information on the working hard disk. Therefore,
if the working hard disk fails, the redundant hard disk immediately assumes responsibility
for all operations. This function is referred to as the Redundant Array of Independent
Disks (RAID) mirroring process.
NOTE: The hard disk modules are hot-swappable. Once a new hard disk
module is inserted, you should wait until the RAID mirroring process has
completed before rebooting or turning off the appliance.
To remove and install a hard drive:
1. On the hard drive module, press the blue handle release trigger in and to the right to
release the insertion and removal handle.
2. Grasp the handle and pull the hard drive module straight out of the chassis.
Once you have removed the hard drive module, be sure to replace it with a replacement
hard drive.
3. With the insertion and removal handle on the hard drive module in the released/out
position, line the hard drive module up with an empty hard drive port on the front of
the chassis.
4. Carefully slide the hard drive module into the chassis until it is clicks into place.
Retract the handle by swinging it back across the face of the hard drive until it is
completely flush with the face of the hard drive module.

Documentation


Replacing a Power Supply
The Juniper Networks appliance ships with one AC power supply installed in the back of
the chassis. You can add an optional second power supply to support redundancy and
load-sharing features. In addition, if you need to replace one of the power supplies, you
can “hot-swap” the faulty power supply for a replacement while the optional second
power supply assumes responsibility for the entire power load, thus avoiding a situation
where you have to power off the Policy Secure gateway before replacing the removable
unit.
To remove and install an AC power supply module:
1. Press the release trigger in and to the right to release the module.
2. Grasp the insertion and removal handle and pull the power supply module straight
out of the chassis.
Once you have removed the supply module, be sure to replace it with a replacement
power supply or the “dummy” power supply port cover installed in your chassis at the
time of shipping.
3. Line the new power supply module up with an empty power supply port on the back
of the chassis.
4. Slowly slide the power supply module into the chassis until it clicks into place.
To remove and install a DC power supply module:
1. Unplug the power cord.
2. Disconnect the DC supply wires from the lugs on the DC power supply.
3. Press the release trigger in and to the right to release the module.
4. Grasp the power supply module and pull it straight out of the chassis.
5. Slowly slide the new module into the chassis until it clicks into place.
6. Connect the DC supply wires to the module using the lugs. Be sure to attach the ground
wire.
7. Attach the power cord.

Documentation  Understanding Device Status LED Behavior on page 830


CHAPTER 27
Using the IC6500 FIPS Appliance

(Hardware FIPS)
 FIPS Overview on page 835

 Understanding Name and Password Restrictions on page 836
 Initializing a Keystore on page 837
 Reinitializing the Keystore on page 837
 Joining a Cluster on page 838
 Changing the Security Officer Password on page 839
 Changing the Web User Password on page 839
 Upgrading the Sun HSM Firmware on page 840
 Importing and Exporting Keystore Binary Files on page 840
 Understanding FIPS Device Status LED Behavior on page 841
FIPS Overview
The Juniper Networks IC6500 FIPS is a standard IC6500 appliance equipped with a Sun
Crypto Accelerator 6000 PCI-E Adapter card. The tamper-proof hardware security
module installed on a Policy Secure gateway FIPS system is certified to meet the FIPS
140-2 level 3 security benchmark.
The configuration process for Policy Secure gateway FIPS administrators is almost the
same as for the non-FIPS Policy Secure gateway administrators and requires only minor
configuration changes during the initialization, clustering, and certificate generation
processes. For the few cases where administration tasks are different, this guide
includes the appropriate instructions for both Policy Secure gateway and Policy Secure
gateway FIPS administrators. For
end-users, Policy Secure gateway FIPS is the same as a standard Pulse Policy Secure
system.
The Sun Crypto Accelerator 6000 PCI-E Adapter (SCA 6000) is a host bus adapter card
that combines IPsec and SSL cryptographic acceleration with Hardware Security Module
(HSM) features. This combination of a dedicated HSM, advanced cryptographic security
and secure key management meet the security and performance needs for any service.
The SCA 6000 card has two main roles: a security officer and a user role.
The SCA 6000 replaces the need for administrator cards with the concept of a security
officer who manages keys and passwords. The security officer credential protects the

keystore from being exported and imported onto another SCA 6000 card. User roles
perform cryptographic operations, such as accessing keying material within the keystore
as well as performing bulk encryption operations.
The security officer credentials, user credentials, and RSA private keys are stored in the
HSM encrypted keystore located on the Policy Secure gateway disk. You are prompted to
provide these credentials whenever any operation requires them. Credentials are not
automatically retrieved from the HSM keystore.
Keystores are stored on the disk and are encrypted with a master key. The master key is
stored in the SCA 6000 firmware and can be backed up by a security officer by means
of a restore password. This restore password can then be used to restore the master key
onto the same or different SCA 6000 cards, thereby allowing the keystore to be shared
across a cluster, for example.
Related Understanding Name and Password Restrictions on page 836

Documentation

 Changing the Security Officer Password on page 839
Understanding Name and Password Restrictions
Name Restrictions—Security officer names and usernames must adhere to the following
requirements:
Requirement Description
Minimum Length At least one character
Maximum Length 63 characters
Valid Characters Alphanumeric, underscore (_), dash (-) and period (.)
First Character Must be alphabetic
Password Restrictions—Passwords must be at least six characters. Three characters

must be alphabetic and one character must be non-alphabetic.
Related Changing the Security Officer Password on page 839

Documentation


Chapter 27: Using the IC6500 FIPS Appliance (Hardware FIPS)
Initializing a Keystore
When the FIPS appliance is powered on from a factory-reset or when its configuration
is reset, the serial console requires the initialization of a keystore and a self-signed device
certificate. During the boot process, the current release’s SCA6000 HSM firmware is
installed on the SCA6000 HSM. The steps for initialization are:
 When you are prompted to create a new keystore, provide the following data:
 The security officer name and password. Save these credentials because they are
required for such tasks as creating new restore passwords and changing the security
officer password.
 The keystore restore or HSM master key backup password. Every time you export
the system configuration, save the current restore password for the archived keystore.
 Web username and password for running cryptographic operations using keys stored
in the HSM keystore.
 The self-signed certificate creation proceeds as usual except that the HSM is used to
generate a secure RSA private key which is stored in the HSM’s database.
Related Reinitializing the Keystore on page 837

Documentation

 Understanding Name and Password Restrictions on page 836
Reinitializing the Keystore
If a change occurs in the security policy of the deployment that requires the creation of
new RSA key pairs and corresponding certificates, you must reinitialize the keystore. You
can reinitialize the keystore from either a standalone node or a cluster.
To reinitialize the keystore from a standalone node:
1. Reboot the standalone node.
During the boot process, you are prompted to reinitialize the keystore.
2. Press Y to delete the current keystore and server certificates.
NOTE: If you do not press Ywithin 10 seconds, the appliance boots normally.

To reinitialize the keystore from a cluster:
1. Reboot a node within the cluster.
During the boot process, you are prompted to reinitialize the keystore.
2. Press Y to delete the current keystore and server certificates. A new keystore is
initialized.
NOTE: If you do not press Y within 10 seconds, the appliance will proceed
to boot normally.
3. On the node that you rebooted, open the cluster status page in the admin console
and wait for all nodes to exit from the Transitioning state.
4. For all other nodes in the cluster, connect to the serial console and type 9 to select
FIPS Options, and then type 1 to select Complete import of keystore and server
certificates.
5. At the prompt, enter the restore password when prompted.
Related Joining a Cluster on page 838

Documentation

Joining a Cluster
Joining a cluster involves using both the admin console and serial console.
To join a cluster:
1. If you have not already done so, define and initialize a cluster.
If you are currently running standalone appliances that you want to cluster, we
recommend that, before you create a cluster, you configure system and user settings
on one machine. After doing so, use the same machine to create the cluster. This
machine joins the cluster as part of the creation process. When other Policy Secure
gateways join the cluster, this machine propagates its configuration to the new
cluster member.
2. Before you can add an appliance to a cluster, make its identity known to the cluster.
3. Join the appliance to the cluster through either the admin console or the serial console.
 When joining a node to a cluster using the serial console, you are prompted for the
cluster keystore’s restore password. If the restore password fails, type 9 to select
FIPS Option, and then type 1 to select Complete import of keystore and server
certificates.
When a cluster is created on a node, the node’s keystore becomes the cluster’s
keystore. Any node joining the cluster must import the cluster’s keystore. To do this,
you need the current keystore restore password.

4. When you see the message confirming that the machine has joined the cluster, select
System > Clustering and click the Cluster Status tab in the admin console of any active
cluster member.
5. After all nodes exit from the Transitioning” state, connect to the serial console of each
node that has a non-CL license. Type 9 to select FIPS Options and then type 1 to select
Complete import of keystore and server certificates.
6. Enter the cluster keystore restore password.

Documentation
 Joining a Policy Secure gateway to a Cluster Through Its Serial Console on page 798

Changing the Security Officer Password
Occasionally you might want to change the security officer password. In a cluster, you
can perform this operation from any node. The new security officer password is updated
to the other nodes automatically.
NOTE: Changing the security officer password restarts the Web server.
To change the security officer password:
1. Connect to the serial console of the FIPS appliance you want to reset.
2. Type 9 to select FIPS Option.
3. Type 2 to select Change security officer password.
4. Enter the existing security officer password.
5. Enter the new password.
6. Re-enter the new password to confirm.
Related Understanding Name and Password Restrictions on page 836

Documentation

Changing the Web User Password
The Web username and password are used to securely store the RSA private keys in the
HSM’s encrypted database. These credentials are used by the IVE processes to carry out
RSA operations. The keys are never available for use outside the HSM. You can later
change the web password but not the Web username.
In a cluster, you can perform this operation from any node. The new password is updated
to the other nodes automatically.

NOTE: Changing the web user password restarts the web server.
To change the web password:
1. Connect to the serial console of the FIPS appliance you want to reset.
2. Enter 9 to select FIPS Option.
3. Enter 3 to select Change web user password.
4. Enter the existing web user password.
5. Enter the new password.
Related Changing the Security Officer Password on page 839

Documentation

Upgrading the Sun HSM Firmware
Some system software upgrades may also require firmware updates. Typically, firmware
upgrades occur during the boot process. After the system software updates, the serial
console prompts you for the keystore restore password before upgrading the HSM’s
firmware. If you do not remember the password, you have the option of upgrading the
firmware at a later date using the serial console. Note that the web server may not function
properly if the firmware upgrade is required and is not updated.
To upgrade the firmware using the serial console:
1. Select System > Clustering and click the Cluster Status tab in the admin console. Wait
for the node to be in the FIPS disassociated state.
2. Open a serial console and type 9 to select the FIPS option.
3. Type 6 to select Load Firmware.
Related Using the Serial Port on page 589

Documentation

Importing and Exporting Keystore Binary Files
Select Maintenance > Import/Export from the admin console to import and export the
keystore. You can do this from a standalone node or from a node within a cluster. The
keystore is exported as part of the system settings configuration file. Safely store the
restore password associated with the archived keystore because you will need it for
various FIPS operations. If you forget the restore password you can create a new one
from the serial console and then re-export the configuration.
To import the keystore, select the Import Key Store and Device Certificate check box and
import your configuration. After the import process has completed, open a serial console
for that FIPS appliance and type 9 for FIPS Options and then type 1 to select Complete

import of keystore and server certificates. If the keystore is different from the one installed
on the HSM you will be prompted for the keystore’s restore password.
NOTE: If you reboot the FIPS appliance without performing the serial console
step above, you are prompted to import the keystore during the boot process.
Type y to import the keystore. If you do not type Y within five seconds, the
FIPS appliance to boots normally. If this occurs, perform the serial console
step after the FIPS appliance completes its boot process.
If the FIPS appliance is in a cluster, go to each node within the cluster and perform the
serial console step above to complete the keystore import process.
Related Joining a Cluster on page 838

Documentation

Understanding FIPS Device Status LED Behavior
There are three device status LEDs located on the FIPS card:
 S (Status)
 F (FIPS)
 I (INIT)
Table 126: FIPS Device Status LEDs
STATUS Off Bootstrap firmware is executing
Blinking green IDLE, OPERATIONAL, or FAILSAFE

state
Green POST or DISABLED state (driver

not attached)
Blinking red Error occurred during boot process
Red HALTED (fatal error) state or when

a low-level hardware initialization
failure occurred
FIPS Off Operating in non-FIPS mode
Green Operating in FIPS mode
Blinking yellow Zeroize jumper is present

Table 126: FIPS Device Status LEDs (continued)
INT Off Board is not initialized
Green Board initialized by security officer
Yellow POST, DIAGNOSTIC or FAILSAFE

(firmware not upgraded) state
Blinking yellow Running diagnostics

CHAPTER 28
Custom Expressions and System

Variables Reference
 Using Custom Expressions in Rule Configuration on page 843
Using Custom Expressions in Rule Configuration
This topic describes custom expressions. It is intended for advanced users. It includes
 Custom Expressions on page 843

 Custom Expression Elements on page 844
 Wildcard Matching on page 847
 Using Multi-Valued Attributes on page 847
 Specifying Multivalued Attributes in a Bookmark Name on page 848
 Distinguished Name Variables on page 849
 System Variables on page 849
 Custom Variables and Macros on page 858
 Specifying Fetch Attributes in a Realm on page 861
 Specifying the homeDirectory Attribute for LDAP on page 862
Custom Expressions
Many system rules, such as role mapping rules or resource policy rules, support custom
expressions. A custom expression is a combination of variables that the system evaluates
as a Boolean object. The expression returns true, false, or error.
You can write custom expressions in the following formats. Note that elements of these
formats are described in greater detail in the table that follows:
 variable comparisonOperator variable
 variable comparisonOperator simpleValue
 variable comparisonOperator (simpleValue)
 variable comparisonOperator (OR Values)

 variable comparisonOperator (AND Values)
 variable comparisonOperator (time TO time)
 variable comparisonOperator (day TO day)
 isEmtpy (variable)
 isUnknown (variable)
 (customExpr)
 NOT customExpr
 ! customExpr
 customExpr OR customExpr
 customExpr || customExpr
 customExpr AND customExpr
 customExpr && customExpr
Custom Expression Elements
Table 127: Custom Expression Elements
Element Description
variable Represents a system variable. A variable name is a dot-separated string, and each
component can contain characters from the set [a-z A-Z 0-9_ ] but cannot start with a
digit [0-9]. Variable names are case-insensitive. For system variables that you may use in
role mapping rules and resource policies.
When writing a custom expression in a log query field, you need to use system log variables.
These variables are described in the Filter Variables Dictionary on the Filter page (System >
Log/Monitoring > Events | User Access | Admin Access > Filters > Select Filter tab).
Quoting syntax for variables:
The system supports a quoting syntax for custom expression variables that allows you to
use any character except '.' (period) in a user attribute name. To escape characters in an
attribute name, quote some or all of the variable name using { } (curly-braces). For example,
these expressions are equivalent:
 userAttr.{Login-Name} = 'xyz'
 userAttr.Login{-}Name = 'xyz'
 {userAttr.Login-Name} = 'xyz'
 userA{ttr.L}{ogin-}Name = 'xyz'
 Escape characters supported within quotes:

 \\—Escape a backslash (\).
 \{—Escape a left curly brace ({).
 \}—Escape a right curly brace (}).
 \hh—Escape a hexadecimal value where hh is two characters from [0-9A-Fa-f].

Chapter 28: Custom Expressions and System Variables Reference
Table 127: Custom Expression Elements (continued)
Element Description
Examples:
 userAttr.{Tree Frog} = 'kermit'

 userAttr.{Tree\20Frog} = 'kermit'
Notes:
 There is no limit to the number of quotes you can use in a variable name.
 You can use the quoting syntax with any variable, not just userAttr.* variables.
 You need to use curly-brace quotes only when writing custom expressions.
comparisonOperator One of the following:
 =—Equal to. Use with strings, numbers, and DNs.

 !=—Not equal to. Use with strings, numbers, and DNs.
 <—Less than. Use with numbers.
 <=—Less than or equal to. Use with numbers.
 >—Greater than. Use with numbers.
 >=—Greater than or equal to. Use with numbers.
simpleValue One of the following:
 string — quoted string that may contain wildcards.

 IP Address—a.b.c.d
 subnet—a.b.c.d/subnetBitCount or a.b.c.d/netmask
 number—Positive or negative integer
 day—SUN MON TUE WED THU FRI SAT
Notes about strings:
 A string may contain all characters except <nl> (newline) and <cr> (carriage return).
 Strings can be any length.
 String comparisons are case-insensitive.
 Strings can be quoted with single- or double-quotes. A quoted string may contain
wildcards, including star(*), question mark (?), and square brackets ([ ]).
 variable comparisonOperator variable comparisons are evaluated without wildcard
matching.
 Use a backslash to escape these characters:
single-quote (') — \'
double-quote (") — \"
backslash (\) — \\
hexadecimal — \hh [0-9a-fA-F]
Note about day:
Day and time comparisons are evaluated in the system’s time zone. Day range (day TO day)
calculations start with the first day and step forward until the second day is reached. In
time range (time TO time) calculations, the first value must be earlier than the second value.
Only time variables can be compared to day and time values. The time variables are: time.*
and loginTime.*.

Element Description
time Time of day in one of the following formats:
 HH:MM — 24-hour
 HH:MMam — 12-hour
 HH:MMpm — 12-hour
 H:MM — 24-hour
 H:MMam — 12-hour
 H:MMpm — 12-hour
Day and time comparisons are evaluated in the Pulse Connect Secure’ time zone. Day range
(day TO day) calculations start with the first day and step forward until the second day is
reached. In time range (time TO time) calculations, the first value must be earlier than the
second value. Only time variables can be compared to day and time values. The time
variables are: time.* and loginTime.*.
OR Value String containing one or more OR comparisons:
Examples:
variable comparisonOperator (number OR number ...)
variable comparisonOperator (string OR string ...)
AND Value String containing one or more AND comparisons.
Examples:
variable comparisonOperator (number AND number ...)
variable comparisonOperator (string AND string ...)
isEmpty Function that takes a single variable name (variable) argument and returns a boolean value.
isEmpty() is true if the variable is unknown or has a zero-length value, zero-length strings,
and empty lists.
Example: isEmpty(userAttr.terminationDate)
isUnknown Function that takes a single variable name (variable) argument and returns a boolean value.
isUnknown() is true if the variable is not defined. User attributes (userAttr.* variables) are
unknown if the attribute is not defined in LDAP or if the attribute lookup failed (such as if
the LDAP server is down).
Example: isUnknown(userAttr.bonusProgram)
NOT, ! Logical negation comparisonOperator. The negated expression evaluates to true if the
customExpr is false and evaluates to false if the customExpr is true. The operators NOT,
AND, and OR are evaluated from highest to lowest precedence in this order: NOT (from
right), AND (from left), OR (from left).
OR, || Logical operator OR or ||, which are equivalent. The operators NOT, AND, and OR are
evaluated from highest to lowest precedence in this order: NOT (from right), AND (from
left), OR (from left).

Element Description
AND, && Logical AND or &&, which are equivalent. The operators NOT, AND, and OR are evaluated
from highest to lowest precedence in this order: NOT (from right), AND (from left), OR
(from left).
customExpr Expression written in the Custom Expression Syntax (see above).
Wildcard Matching
In a quoted string, supported wildcards include:
 star (*)—A star matches any sequence of zero or more characters.
 question mark (?)—A question mark matches any single character.
 square brackets ([ ])—Square brackets match one character from a range of possible
characters specified between the brackets. Two characters separated by a dash (-)
match the two characters in the specified range and the lexically intervening characters.
For example, ‘dept[0-9]’ matches strings "dept0", "dept1", and up to "dept9".
To escape wildcard characters, place them inside square brackets. For example, the
expression ' userAttr.x = " value [*]" ' evaluates to true if attribute x is exactly "value*".
Using Multi-Valued Attributes

Multi-valued attributes—attributes that contain two or more values—provide you with a
convenient method for defining resources that expand into multiple individual bookmarks
on the users’ bookmarks page.
For example, assume that the user’s LDAP directory contains the multi-valued attribute
HomeShares: \\Srv1\Sales;\\Srv2\Marketing. When you configure the Windows File
share resource definition using the HomeShares multi-valued attribute,
\\<userAttr.HomeShares>, the user sees two bookmarks:
 \\Srv1\Sales
 \\Srv2\Marketing
Now let’s assume the user’s LDAP directory contains a second multi-valued attribute
defined as HomeFolders: Folder1;Folder2;Folder3. When you configure the Windows File
share resource using both of the multi-valued attributes,
\\<userAttr.HomeShares>\<userAttr.HomeFolders>, the user sees the following six
bookmarks:
 \\Srv1\Sales\Folder1
 \\Srv2\Marketing\Folder1

The only exception to this functionality is when the variable includes an explicit separator
string. In this case, only one bookmark containing multiple resources displays on the
users’ bookmark page.
You specify the separator string in the variable definition using the syntax sep=’string’
where string equals the separator you want to use. For example, to specify a semi-colon
as the separator, use the syntax <variable.Attr sep=';'>.
Use the following syntax for multi-valued attributes handling. Note that <variable> refers
to a session variable such as <userAttr.name> or <CertAttr.name>:
 <variable[Index]>—You specify indexes in a variety of ways. If, for example, the total
number of values for a given index is 5, and you want to specify the entire range of
values you use <variable[ALL]>. If you want to specify only the fourth value, you use
<variable[4]>.
 <variable> is the same as <variable[ALL]>.
 <variable> is the same as <variable[ALL]>.
 <variable sep='str'> and <variable[All] sep='str'> — These variable definitions always

refer to a single string value with all the tokens expanded out with separator strings
between the values.
NOTE: Variable names cannot contain spaces.
Specifying Multivalued Attributes in a Bookmark Name

Another common case of using multivalued attributes occurs when you include a variable
in a bookmark name and in a URL or file server/share field.
For example, again assume that the user’s LDAP directory contains the multi-valued
attribute HomeShares: \\Srv1\Sales;\\Srv2\Marketing. When you configure the Windows
File share resource definition using the HomeShares multi-valued attribute,
\\<userAttr.HomeShares>, and you use the same attribute in the bookmark name field,
<userAttr.HomeShares>, the system creates two bookmarks:
 Srv1\Sales bookmark pointing to \\Srv1\Sales
 Srv2\Marketing bookmark pointing to \\Srv2\Marketing
This does not create a situation in which you end up with the following set of conditions:
 Srv1\Sales bookmark pointing to \\Srv1\Sales
 Srv1\Marketing bookmark pointing to \\Srv1\Marketing (error)
 Srv2\Sales bookmark pointing to \\Srv1\Sales (error)
 Srv2\Marketing bookmark pointing to \\Srv2\Marketing

Distinguished Name Variables

You can compare a distinguished name (DN) to another DN or to a string, but the system
ignores wildcards, white space, and case. Note, however, that the system takes the order
of DN keys into consideration.
When the system compares an expression to a DN to a string, it converts the string to a

distinguished name before evaluating the expression. If the system cannot convert the
string due to bad syntax, the comparison fails. The DN variables are:
 userDN
 certDN
 certIssuerDN
The system also supports DN suffix comparisons using the matchDNSuffix function. For
example:
matchDNSuffix( certDn, "dc=danastreet,dc=net")
Within the parenthesis, the first parameter is the “ full” DN and the second is the suffix
DN. You can use a variable or string for each parameter. Note that this first parameter
should have more keys than the second (suffix parameter). Otherwise, if they are equal,
it is the same as <firstparam> = <secondparam>. If the second parameter has more keys,
matchDNsuffix returns false.
System Variables
The following table lists and defines system variables, gives an example for each system
variable, and provides a guide as to where you may use system variables.
Table 128: System Variables and Examples
Variable Description Usage Examples
authMethod Type of authentication method used role mapping rules, authMethod = ‘ACE Server’
to authenticates a user. resource policy rules
cacheCleanerStatus The status of Cache Cleaner. Possible cacheCleanerStatus = 1

values: cacheCleanerStatus = 0
1 - if it is running
0 - if otherwise

Table 128: System Variables and Examples (continued)
certAttr.<cert-attr> Attributes from a client-side  role mapping rules certAttr.OU = 'Retail Products
certificate. Examples of certAttr  resource policy rules Group'
attributes include:
 SSO parameter fields
 C - country  LDAP configuration
 CN - common name
 description - description
 emailAddress - email address
 GN - given name
 initials - initials
 L - locality name
 O - organization
 OU - organizational unit
 SN - surname
 serialNumber- serial number
 ST - state or province
 title - title
 UI - unique identifier
Use this variable to check that the
user’s client has a client-side
certificate with the value(s)
specified.
certAttr.altName.<Alt-attr> Subject alternative name value from  role mapping rules  certAttr.altName.email =
a client-side certificate where  resource policy rules "joe@company.com"
<Alt-attr> may be:  certAttr.altName.ipAddress =
10.10.83.2
 Email  LDAP configuration
 Emailld
 EmailDomain
 DNS
 registeredId
 ipAddress
 UPN
 UPNid
 UPNDomain
 fascn
 fascnAC
 fascnSC
 fascnCN
 fascnCS
 fascnICI
 fascnPI
 fascnOC
 fascnOI
 fascnPOA
 fascnLRC

certAttr.serialNumber Client certificate serial number.  role mapping rules  certAttr.SerialNumber =
 resource policy rules userAttr.certSerial

Note that all characters other than
 certAttr.SerialNumber =
 SSO parameter fields
[0-9 a-f A-F] are stripped out of a
"6f:05:45:ab"
string before comparison with  LDAP configuration
certAttr.SN. Wildcards are not
supported.
certDN Client certificate subject DN. role mapping rules,  certDN = 'cn=John
Wildcards are not permitted. resource policy rules Harding,ou=eng,c=Company'
 certDN = userDN (match the
certificate subject DN with the
LDAP user DN)
 certDN =
userAttr.x509SubjectName
 certDN = ('cn=John
Harding,ou=eng,c=Company' or
'cn=Julia
Yount,ou=eng,c=Company')
certDN.<subject-attr> Any variable from the client certificate  role mapping rules  certDN.OU = 'company'
subject DN, where subject-attr is the  resource policy rules  certDN.E = 'joe@company.com'
name of the RDN key.
 SSO parameter fields  certDN.ST = 'CA'
Use to test the various subject DN  LDAP configuration
attributes in a standard x.509
certificate.
certDNText Client certificate user DN stored as a  role mapping rules certDNText = 'cn=John
string. Only string comparisons to this  resource policy rules Harding,ou=eng,c=Company'
value are allowed.
certIssuerDN Client certificate-issuer subject DN.  role mapping rules  certIssuerDN = 'cn=John
This variable works like a standard DN  resource policy rules Harding,ou=eng,c=Company'
attribute such as CertDN. Wildcards  certIssuerDN =
are not permitted. userAttr.x509Issuer
 certIssuerDN =
('ou=eng,c=Company' or
'ou=operations,c=Company')
certIssuerDN.<issuer-attr> Any variable from the client  role mapping rules  certIssuerDN.OU = 'company'
certificate-issuer subject DN, where  resource policy rules  certIssuerDN.ST = 'CA'
issuer-attr is the name of the RDN key.
certIssuerDNText Client certificate-issuer subject DN  role mapping rules certIssuerDNText = 'cn=John

stored as a string. Only string  resource policy rules Harding,ou=eng,c=Company'
comparisons to this value are allowed.

defaultNTDomain Contains the Domain value set in the  role mapping rules defaultNTDomain=” CORP”
authentication server configuration  resource policy rules
when you use AD/NT authentication.
group.<group-name> User’s group membership as provided  role mapping rules  group.preferredPartner

by the realm authentication or  resource policy rules  group.goldPartner or
directory server. group.silverPartner
Only those groups
 group.employees and
evaluated for role mapping
time.month = 9
rules are available in the
detailed rules (conditions) Combination examples:
in the resource policies. We Allow all partners with active
recommend that you use status from Monday to Friday
the groups variable instead but preferred partners Monday
of group.<group-name>, through Saturday:
which is supported only for
((group.partners and time =
backwards compatibility.
(Mon to Fri)) or
(group.preferredPartners and
time = (Mon to Sat))) and
userAttr.partnerStatus = 'active'
NOTE: Spaces are not supported,

such as, group.sales managers
groups List of groups as provided by the  role mapping rules groups=('sales managers')
realm authentication or directory  resource policy rules
server.
NOTE: You can enter any characters
in the groupname, although wildcard
characters are not supported.
hostCheckerPolicy Host Checker polices that the client  role mapping rules hostCheckerPolicy = ('Norton' and
has met.  resource policy rules 'Sygate') and cacheCleanerStatus
= 1hostCheckerPolicy = ('Norton'
and 'Sygate')
loginHost Host name or IP address that the  role mapping rules loginHost = 10.10.10.10
browser uses to contact the Pulse  resource policy rules
Secure service.
 LDAP configuration
loginTime The time of day at which the user  role mapping rules  loginTime = (8:00am)
submits his credentials. The time is  resource policy rules  loginTime= (Mon to Fri)
based on system time.
NOTE: When using this variable in an
SSO parameter field, the variable
returns the UNIX string time.

loginTime.day The day of month on which the user  role mapping rules loginTime.day = 3
submits his credentials, where day is  resource policy rules
1-31. The time is based on the system
time.
You cannot use the TO operator with

this variable.
loginTime.dayOfWeek The day of the week on which the user  role mapping rules  loginTime.dayOfWeek = (0 OR
submits his credentials, where  resource policy rules 6)
dayOfWeek is in the range [0-6]  loginTime.dayOfWeek = (mon
where 0 = Sunday. TO fri)
The system does not support the TO  loginTime.dayOfWeek = (1)

operator with time.dayOfWeek  loginTime.dayOfWeek = 5
expressions if you use numbers
instead of strings. In other words, “
loginTime.dayOfWeek = (2 TO 6)”
does not work, but “
loginTime.dayOfWeek = (mon to fri)”
does work.
loginTime.dayOfYear The numeric day of the year on which  role mapping rules loginTime.dayOfYear = 100
the user submits his credentials,  resource policy rules
where dayOfYear can be set to
[0-365].

this variable.
loginTime.month The month in which the user submits  role mapping rules loginTime.month >= 4 AND
his credentials, where month can be  resource policy rules loginTime.month <=9
set to [1-12] where
1 = January.

this variable.
loginTime.year The year in which the user submits his  role mapping rules loginTime.year = 2005
credentials, where year can be set to  resource policy rules
[1900-2999].

this variable.
loginURL URL of the page that the user  role mapping rules loginURL = */admin
accessed to sign in. The system gets  resource policy rules
this value from the Administrator
URLs|User URLs column on the
Authentication > Signing In > Sign-in  LDAP configuration
Policiespage of the admin console.

networkIf The network interface on which the  role mapping rules sourceIp = 192.168.1.0/24 and
user request is received. Possible  resource policy rules networkIf = internal
values: internal, external
 SSO parameter fields
ntdomain The NetBIOS NT domain used in NT4  role mapping rules ntdomain = jnpr
and Active Directory authentication.  SSO parameter fields
ntuser The NT username used in Active  role mapping rules ntuser = jdoe
Directory authentication  SSO parameter fields
password The password entered by the user for  role mapping rules password = A1defo2z
the primary authentication server  resource policy rules
password[1] (password and password[1]) or the
secondary authentication server
password[2] (password[2]).
realm The name of the authentication realm  role mapping rules Realm = ('GoldPartners' or
to which the user is signed in.  resource policy rules 'SilverPartners')
NOTE: AND condition will always

fail as a user is only allowed to sign
in to a single realm in a session.
role List of all the user roles for the  resource policy rules  Role = ('sales' or 'engineering')
session.  SSO parameter fields  Role = ('Sales' AND 'Support')
In SSO, if you want to send all the

roles to back-end applications, use
<role sep = ";"> - where sep is the
separator string for multiple values.
The system supports all separators
except “ and >.
sourceIP The IP address of the machine on  role mapping rules  sourceIP = 192.168.10.20
which the user authenticates. You can  resource policy rules sourceIP = 192.168.1.0/24 and
specify the netmask using the bit networkIf internal
number or in the netmask format:
 userAttr.dept = ('eng' or 'it') and
'255.255.0.0'. Note that you can
sourceIP = 10.11.0.0/16
evaluate the sourceIP expression
against a string variable such as an  sourceIP = 192.168.10.0/24
LDAP attribute. (Class C)
is the same as:
sourceIP =
192.168.10.0/255.255.255.0
 sourceIP=userAttr.sourceip

time The time of day at which the role  role mapping rules  time = (9:00am to 5:00pm)
mapping rule or resource policy rule  resource policy rules  time = (09:00 to 17:00)
is evaluated. The time of the day can
 time = (Mon to Fri)
be in 12-hour or 24-hour format.
Combination examples:
Allow executive managers and
their assistants access from
Monday to Friday:
userAttr.employeeType =
('*manager*' or '*assistant*')
and
group.executiveStaff and
time = (Mon to Fri)
time.day The day of month on which the user  role mapping rules loginTime.day = 3
submits his credentials to, where day  resource policy rules
is 1-31. The time is based on the
system time.
time.dayOfWeek The day of the week on which the role  role mapping rules  loginTime.dayOfWeek = (0 OR
mapping rule or resource policy rule  resource policy rules 6)
is evaluated, where dayOfWeek is in  loginTime.dayOfWeek = (1 to 5)
the range [0-6] where 0 = Sunday.
 loginTime.dayOfWeek = 5
time.dayOfYear The day of the year on which the role  role mapping rules time.dayOfYear = 100
mapping rule or resource policy rule  resource policy rules
is evaluated. Possible values include:
1-365.
time.month The month in which the role mapping  role mapping rules  time.month >= 9 and
rule or resource policy rule is  resource policy rules time.month <= 12 and time.year
evaluated. Possible values include: = 2004
1-12  group.employees and
time.month = 9
time.year The year in which the role mapping  role mapping rules time.year = 2005
rule or resource policy rule is  resource policy rules
evaluated, where year can be set to
[1900-2999].

user Junos Pulse username for the user’s  role mapping rules  user = 'steve'
primary authentication server (user  resource policy rules  user = 'domain\\steve'
user@primary_auth_server_name and
user@primary_auth_server_name) or
user@secondary_auth_server_name secondary authentication server
(user@secondary_auth_server_name).
Use when authenticating against an
Active Directory server, domain and
username.
primary_auth_server_name is the
name of the primary auth server. If
there are spaces or special characters
in the name, it can be enclosed in
curly brackets. For example
user@{My Primary Auth Server}
secondary_auth_server_name is the
name of the secondary auth server. If
user@{My Secondary Auth Server}
NOTE: When including a domain as

part of a username, you must include
two slashes between the domain and
user. For example:
user=’yourcompany.net\\joeuser’.
username Junos Pulse system username for the  role mapping rules  username = 'steve' and time =
user’s primary authentication server  resource policy rules mon
username@primary_auth_server_name (username and
 SSO parameter fields  username = 'steve'
username@primary_auth_server_name)
username@secondary_auth_server_  username = 'steve*'
or secondary authentication server
name (username@secondary_auth_server_name).  username = ('steve' or
If the user is signing in to a certificate '*jankowski')
authentication server, then the user’s
Junos Pulse system username is the
same as CertDN.cn.
primary_auth_server_name is the
name of the primary auth server. If
user@{My Primary Auth Server}
secondary_auth_server_name is the
name of the secondary auth server. If
user@{My Secondary Auth Server}

userAgent The browser’s user agent string.  role mapping rules The browser’s user agent string.
 resource policy rules
userAttr.<auth-attr> User attributes retrieved from an  role mapping rules  userAttr.building = ('HQ*' or
LDAP, RADIUS, or SiteMinder  resource policy rules 'MtView[1-3]')
authentication or directory server.  userAttr.dept = ('sales' and
'eng')
 userAttr.dept = ('eng' or 'it' or
'custsupport')
 userAttr.division = 'sales'
 userAttr.employeeType !=
'contractor'
 userAttr.salaryGrade > 10
 userAttr.salesConfirmed >=
userAttr.salesQuota
Negative examples:
 userAttr.company != "Acme Inc"
or not group.contractors
 not (user = 'guest' or
group.demo)
Combination examples:
Allow executive managers and
their assistants access from
Monday to Friday:
userAttr.employeeType =
('*manager*' or '*assistant*')
and
group.executiveStaff and
time = (Mon to Fri)
Allow all partners with active

status from Monday to Friday
but preferred partners Monday
through Saturday:
((group.partners and time =

(Mon to Fri)) or
(group.preferredPartners and
time = (Mon to Sat))) and
userAttr.partnerStatus = 'active'

userDN The user DN from an LDAP server. If  role mapping rules  userDN = 'cn=John
the user is authenticated by the LDAP  resource policy rules Harding,ou=eng,c=Company'
server, then this DN is from the  userDN = certDN
authentication server; otherwise, the
DN comes from the realm's
Directory/Attribute server. Wildcards
are not permitted.
userDN.<user-attr> Any variable from the user DN, where  role mapping rules Any variable from the user DN,
user-attr is the name of the RDN key.  resource policy rules where user-attr is the name of the
RDN key.
userDNText User DN stored as a string. Only string  role mapping rules userDNText = 'cn=John
comparisons to this value are allowed.  resource policy rules Harding,ou=eng,c=Company'
Custom Variables and Macros

Custom variables, like system variables, are name-value pair tags that you can use when
defining role mapping rules, resource policy rules and SSO parameter fields.
Custom variables are created in the Server Catalog (for example, Authentication > Auth
Server > Name > Settings) by using a pre-defined macro on a system variable. Available
macros are:
 REGMATCH – Matches a regular expression pattern against a string text.
 APPEND – Appends a text string to another text string.
 DAYSDIFF – Calculates the difference between two dates.
NOTE: These macros are located under Variable Operators in the Variables
tab of the Server Catalog window.
A custom variable name is a dot-separated string. Each component can contain characters
from the set [a-z A-Z 0-9 _] but cannot start with a digit [0-9]. Custom variable names
are case-insensitive.
Custom variables are referenced as customVar.<variableName> . For example, if you

create a custom variable with the name check-prefix, you reference this custom variable
as customVar.check-prefix.

append
Syntax APPEND (attr, TextString)
APPEND (attr, attr2)
Description Append a text string to an attribute or append an attribute to another attribute and store
the resulting string in the custom variable.
Options attr—System variable of type string.
TextString—Quoted ASCII string.
attr2—System variable of type string.
Output Fields Returns a String value. If no match is found, returns an empty string.
If the system variable is multivalued, the custom variable is also multi-valued and uses
the same order as the system variable.
Sample Output
APPEND (userName, “@juniper.net”)
In this example, the string “@juniper.net” is appended to the userName value.

daysdiff
Syntax DAYSDIFF (attr, timeformat)
Description Calculates the number of days between the attribute and the current time.
timeformat—Output time format. Valid values are: UTC, TIMET, MMDDYYYY
Output Fields Returns an Integer value.
Sample Output
DAYSDIFF ( certAttr.validUpto, UTC)
In this example, calculate the difference in days between the current time and the value
of certAttr.validUpto and express the time in UTC (Coordinated Universal Time).

regmatch
Syntax REGMATCH (attr, regex, groupingNumber)
Description Match the regular expression pattern against an attribute and store the result in the
custom variable.
regex—Quoted string containing the regular expression to be applied to the attr option.
groupingNumber—The group value to assign to the custom variable.
Additional Information The regular expression supports the Perl Compatible Regular Expressions (PCRE) syntax.
A grouping (capture buffer) in the regex pattern can also be used to define a custom
variable.
Output Fields Returns a String value. If no match is found, returns an empty string.
If the system variable is multivalued, the custom variable is also multi-valued and uses
the same order as the system variable.
Sample Output
REGMATCH (mailId, “^(.*)@juniper.net$”, 1)
In this example, a mailId of myName@juniper.net creates a custom variable with value

“myName”.
Specifying Fetch Attributes in a Realm

To facilitate the support for various parameterized settings in user roles and resource
policies, you have the ability to specify additional fetch attributes. The system stores the
fetch attributes when users log in so that you can use them in parameterized role or
resource policy definitions.
The system pulls all the attributes that are currently stored in the Sever Catalog for the
user's authentication or authorization LDAP server. So, make sure to add the LDAP user
attributes that are used in role or resource policy definitions in the LDAP Server Catalog
first.
When a user logs in, the system retrieves user attributes that are referenced in the role
mapping rules plus all of the additional attributes referenced in the Server Catalog and
stores all these values. Note that this should not incur a significant performance overhead
because all the user attributes are retrieved in one single LDAP query.

NOTE: When you substitute variables, such as in IP/Netmasks or host names,

the values in the session are appropriately converted into the data type that
is required by the particular application definition.
Specifying the homeDirectory Attribute for LDAP

You can create a bookmark that automatically maps to a user’s LDAP home directory.
You can accomplish this using the LDAP attribute homeDirectory. You need to configure
a realm that specifies the LDAP server instance as its auth server, and you need to
configure role-mapping rules and a bookmark that points to the LDAP homeDirectory
attribute.
Related  Access Management Framework

Documentation
 Access Management Framework

PART 6
Index
 Index on page 865


Acct-Output-Octets RADIUS attribute ........................ 375
Acct-Output-Packets RADIUS attribute ...................... 375
Acct-Session-Id RADIUS attribute........................375, 381
Acct-Session-Time RADIUS attribute................375, 382
Acct-Status-Type RADIUS attribute....................375, 381
Index Acct-Terminate-Cause RADIUS attribute.........375, 382
Acct-Tunnel-Connection RADIUS attribute .................. 375
Acct-Tunnel-Packets-Lost RADIUS attribute 375
ACE Server.............................................................................. 390
Symbols
6500, 4500............................................................................829 Active Directory server.................................................... 290
802.1X ActiveX, and Host Checker .............................................. 494
Remote Desktop Protocol and machine adapter, OAC, initial configuration of............................. 24
authentication ....................................................... 69 administrator
802.1X overview ................................................................... 178 realms...................................................................425, 806
802.1X supplicant, non-Juniper See also realms
non-Pulse Secure supplicant, about ................... 203 roles........................................................................261, 806
802.1X task summary ..................................................... 180 defined ................................................................ 261
802.1X, non-Pulse Secure supplicant, before See also roles
configuring .................................................................... 204 super administrator account, creating ................ 589
administrator role, defined ............................................803
A administrator sign-in policies ........................................ 474
AAA server advanced endpoint defense ........................................... 496
ACE server .....................................................................390 Agent page, configuring roles........................................... 274
Active Directory ...........................................................290 agentless
Anonymous server ................................................... 308 sign-in notifications ................................................484
Certificate server ...................................................... 312 agentless access
LDAP server ............................................................... 316 enabling on role ........................................................... 274
local authentication server .................................... 282 agentless access, configuring ............................................ 73
MAC address authentication server..................... 328 agentless home page, customize.................................... 271
NIS server ................................................................... 367 allow saving logon information....................................... 41
RADIUS server ........................................................... 372 allow user connections...................................................... 41
SiteMinder server .......................................................396 Anonymous Server .............................................................. 308
SQL server .................................................................. 416 antispyware ...................................................................... 496
access management, restrictions, specifying 268 antispyware rule, Host Checker ..................................... 504
Access-Accept RADIUS attribute ...................................374 antivirus, Host Checker rule .............................................500
Access-Challenge RADIUS attribute .............................374 application policy enforcement, with IDP ................. 825
Access-Reject RADIUS attribute ....................................374 ARAP-Challenge-Response RADIUS attribute 374
Access-Request RADIUS attribute ................................374 ARAP-Features RADIUS attribute .................................. 374
Accounting-Request RADIUS attribute ........................374 ARAP-Password RADIUS attribute ..............................374
Accounting-Response RADIUS attribute ....................374 ARAP-Security RADIUS attribute................................... 374
Acct-Authentic RADIUS attribute........................374, 382 ARAP-Security-Data RADIUS attribute ....................... 374
Acct-Delay-Time RADIUS attribute................................374 ARAP-Zone-Access RADIUS attribute ......................... 374
Acct-Input-Gigawords RADIUS attribute ....................374 archiving ....................................................................................... 658
Acct-Input-Octets RADIUS attribute .............................374 ARP
Acct-Input-Packets RADIUS attribute ...........................374 command ..............................................................589
Acct-Interim-Interval RADIUS attribute .......................374 ARP ping timeout, configuring....................548, 553, 557
Acct-Link-Count RADIUS attribute.......................375, 381 attribute server, See authentication server
Acct-Multi-Session-Id RADIUS attribute............375, 381 attributes
Acct-Output-Gigawords RADIUS attribute .................... 375 configuring ......................................................................... 433

auth polices, Junos Enforcer ............................................. 150 authentication server limitations, authentication
auth policies, ScreenOS Enforcer..................................... 150 protocols ........................................................................ 281
auth table mapping polices, about .............................. 152 authentication settings, for users ................................. 532
auth table mapping policies, configuring .................... 154 authentication, mutual....................................................168
Auth Table Timeout ...........................................................269 authorization server, See authentication server
auth tables, about ............................................................ 150
auth tables, configuring dynamic auth table B
allocation .................................................................. 152 biderectional VPN policies
auth tables, EX Series switch ............................................ 161 IPsec, biderectional VPN policies,
authentication access policies configuring ...................................................................... 139
configuring................................................................ 432 browser
authentication methods ................................................. 168 restrictions, configuring .............................................243
authentication policies sign-in restrictions, user ......................................... 243
defined.............................................................12, 233, 425
authentication protocol set, sign in pages C
default 802.1X IP phone ......................................... 173 Callback-Id RADIUS attribute .......................................... 375
authentication protocol sets, default............................. 170 Callback-Number RADIUS attribute ............................. 375
authentication protocol sets, uses and Called-Station-Id RADIUS attribute .............................. 375
restrictions ..................................................................... 172 Calling-Station-Id RADIUS attribute ............................. 375
authentication protocols, about ................................... 168 canonical format, overview ............................................. 249
authentication protocols, limitations with captive portal, configuring redirection
authentication servers.................................................... 281 destination ....................................................................... 113
authentication protocols, OAC default ............................ 23 captive portal, general information .............................. 110
authentication protocols, recommended uses ......... 170 captive portal, overriding default redirection
authentication protocols, selecting ................................ 170 destination ....................................................................... 112
authentication realms, See realms captive portal, redirect auth policy ................................. 111
authentication server ...................................................... 279 captive portal, with EX Series switch ............................ 160
active directory captive portal, with Junos Enforcer or ScreenOS
configuring........................................................ 222 Enforcer........................................................................... 109
user configuration import/export ................. 307 certificate
Active Directory attributes, configuring ............................................... 433
multidomain configuration .............................. 305 client-side certificate ................................................ 593
defined.............................................................12, 233, 425 code-signing certificate ........................................... 593
directory server, defined......................................... 233 device certificate...............................................593, 595
LDAP importing existing .............................................. 601
configuring attributes........................................ 433 hierarchy
password management ................................ 323 discussed ........................................................... 601
local authentication key.......................................................................................... 595
accounting ..................................................... 382 importing existing .............................................. 601
mapping to realm........................................................ 427 machine certificate
preconfigured servers .................................................. 12 checking using Host Checker ....................... 505
RADIUS restrictions, configuring .............................................233
configuring attributes........................................ 433 server certificate ......................................................... 593
multiple sessions ............................................. 381 certificate authentication
role-mapping attributes ................................... 374 Pulse Policy Secure ................................................... 66
start attributes............................................381, 382 certificate authority server settings, configuring ......... 97
stop attributes ..................................................... 381 certificate restrictions, specifying for a realm or
SiteMinder role........................................................................................ 244
SSO .................................................................399 certificate revocation list See CRL

Index
certificate selection .............................................................. 40 component set options, Pulse .......................................... 52

Certificate Server .................................................................. 312 component sets, configuring for Pulse ........................... 53
certificate store selection components, Pulse overview ............................................. 38
Pulse Policy Secure ................................................... 66 concurrent sessions, limiting the number of ............ 248
certificates configuration overview, federation................................ 452
trusted client CAs ..................................................... 608 configuration overview, UAC solution.........................11, 12
certificates, configuring on Infranet Enforcer ............... 93 configuration xml files, modifying ............................... 680
certificates, IF-MAP client/server .................................... 454 Configuration-Token RADIUS attribute ........................ 375
certificates, importing ....................................................... 97 configuring IF-MAP federation client ......................... 454
certificates, with Infranet Enforcers ...................................92 Connect-Info RADIUS attribute ......................................376
certificates, with Junos Enforcers ...................................... 82 connection rules
Challenge Handshake Authentication Protocol configuring ............................................................................ 49
(CHAP) ............................................................................ 169 connection set, configuring for Pulse .............................46
changing cluster node IP address................................. 789 connections, Pulse ................................................................ 40
CHAP-Challenge RADIUS attribute ...............................375 connections, Pulse overview .............................................. 39
CHAP-Password RADIUS attribute ................................375 console, serial, See serial console
Class RADIUS attribute ....................................................... 375 conventions
client settings, IF-MAP federation ................................... 454 notice icons .............................................................. xxxv
client, IF-MAP federation................................................. 454 text.............................................................................. xxxv
clients, IF-MAP supported .............................................. 448 cooling fans, replacing ................................................... 832
clients, supported with UAC ................................................... 72 credential provider
cluster Pulse Policy Secure.....................................................70
active/active .............................................................. 782 credentials
deployment overview......................................... 782 verifying ................................................................................... 12
active/passive .............................................................. 780 CRL ...................................................................................... 608
deploying overview ............................................ 780 custom expressions
configuring ................................................................ 778 using
initializing...............................................................773, 776 general ............................................................... 433
joining .................................................................... 778 customer support ........................................................ xxxvii
logging...................................................................784, 786 contacting PSGSC ........................................................... xxxvii
managing ................................................................... 778 customized realm UI views ..............................................440
modifying properties.............................................. 787
password.................................................................... 784 D
state synchronization .............................................. 784 date and time .................................................................... 571
status defined ........................................................... 791 delegated administration
synchronization...................................................773, 784 overview .................................................................... 803
cluster nodes, restarting ................................................. 790 deleting a cluster ................................................................. 790
cluster, deleting ..................................................................... 790 deleting sessions, federation........................................... 463
cluster, status......................................................................... 791 deny message, Infranet Enforcer .................................... 145
clustering, admin console ................................................. 791 deploying Pulse Policy Secure solution to users . 16
clustering, configuring with serial console.................. 797 DHCP, using with IF-MAP ..............................................469
clustering, IF-MAP clients............................................... 467 digital certificate See certificate
clustering, IF-MAP servers ................................................. 465 directory server ................................................................. 279
clustering, infranet enforcer ............................................. 794 display splash screen ........................................................ 41
clustering, with IF-MAP federation ..............................465 DLL requirements, Host Checker See Host Checker,
clusters, monitoring ............................................................ 793 server integration interface See Host Checker,
clusters, troubleshooting ............................................... 795 client interface
command line launcher DMI communication ......................................................... 211
examples ....................................................................... 62

DMI connection, configuring (NSM) ............................. 212 Extensible Authentication Protocol (EAP)
DNS lookups ............................................................................ 51 EAP-PEAP, EAP-TTLS ............................................ 167
DNS, configuring .................................................................. 574 external interface status and statistics ........................ 574
documentation external interface, configuring ........................................ 553
comments on ........................................................ xxxvii
domain name, configuring ............................................... 574 F
dynamic auth table allocation failover, VIP ....................................................................... 782
auth tables, dynamic allocation .............................. 151 federation active users, viewing ................................... 462
dynamic certificate trust .................................................... 41 federation server replicas, configuring ......................... 465
dynamic connections ......................................................... 41 federation timing issues ................................................. 449
dynamic IPsec, configuring............................................... 137 federation, client overview ............................................... 454
dynamic policy evaluation ................................................. 239 federation, configuration overview................................ 452
federation, deleting sessions ......................................... 463
E federation, licensing
e-mail, for guest user access accounts ......................... 272 licensing, federation................................................... 448
EAP Generic Token Card (EAP-GTC) .............................169 federation, server overview .............................................. 453
EAP State of Health (EAP-SOH) ................................ 169 federation, server replica overview................................. 463
EAP Transport Layer Security (EAP-TLS) ................ 169 federation, troubleshooting .......................................... 462
EAP tunnels field-replaceable hardware ............................................. 829
tunneling protocols .................................................... 168 file
EAP, enabling on Windows machine ........................... 530 check, configuring ...................................................... 505
EAP-JUAC ............................................................................ 168 filter-ID attribute, VLAN assignment............................ 197
EAP-Message RADIUS attribute ......................................376 Filter-Id RADIUS attribute ................................................ 376
EES (Enhanced Endpoint Security.............................496 FIPS compatibility, with OAC ................................................. 31
eligible roles, defined...................................................... 432 FIPS device, clustering ...................................................... 838
encryption settings, IPsec.................................................. 138 FIPS overview ....................................................................... 835
end user license agreement (EULA), creating ............. 271 firewall rule, Host Checker ............................................. 502
Endpoint Security Assessment Plug-In, Framed-AppleTalk-Link RADIUS attribute .................376
upgrading ......................................................................... 538 Framed-AppleTalk-Network RADIUS
endpoint security software, Pulse download ............. 36 attribute ......................................................................... 376
enforcement points, description of .................................. 3 Framed-AppleTalk-Zone RADIUS attribute ............... 376
Enhanced Endpoint Security (EES).......................... 496 Framed-Compression RADIUS attribute .................... 376
event severity......................................................................... 715 Framed-Interface-Id RADIUS attribute ........................ 376
Event-Timestamp RADIUS attribute .............................376 Framed-IP-Address RADIUS attribute................376, 381
EX Ethernet switch, using with Pulse Policy Secure... 13 Framed-IP-Netmask RADIUS attribute ....................... 376
EX Series Ethernet Switch and IC Series, Framed-IPv6-Pool RADIUS attribute ............................ 376
configuring ......................................................................... 201 Framed-IPv6-Prefix RADIUS attribute ......................... 376
EX Series Ethernet Switch, overview ........................... 200 Framed-IPv6-Route RADIUS attribute......................... 376
EX Series switch and Pulse Policy Secure, overview Framed-IPX-Network RADIUS attribute ...................... 376
................................................................................................157 Framed-MTU RADIUS attribute ...................................... 376
EX series switch as a policy enforcement point .........79 Framed-Pool RADIUS attribute ...................................... 376
EX Series switch auth tables.............................................. 161 Framed-Protocol RADIUS attribute .............................. 376
EX Series switch, as an Infranet Enforcer .................. 158 Framed-Route RADIUS attribute ................................... 376
EX Series switch, auth tables ..........................................160 Framed-Routing RADIUS attribute ............................... 376
EX Series switch, configuration overview ..................... 159 fully-qualified hostname, configuring...........................574
EX Series switch, connecting with Junos Pulse
Pulse Policy Secure...................................................... 160 G
export edition, Junos Enforcer restriction ...................... 86 gateway, configuring.......................................548, 553, 557
GINA ............................................................................. 69

Index
group membership ...........................................................279 I

LDAP............................................................................ 433 Policy Secure gateway
guest user access accounts, email ............................... 272 description of ................................................................ 3
guest user access management Host Checker overview........................................................................... 7
agent ......................................................................................491 IC6500 FIPS overview .................................................. 835
guest user access management, configuring .......... 268 Idle-Timeout RADIUS attribute ...................................... 376
IDP and IF-MAP, concepts ................................................ 467
H IDP and Junos, configuring ............................................... 819
hard drive, replacing........................................................ 833 IDP and role-based policies ............................................ 825
hardware, about............................................................... 829 IDP and ScreenOS, configuring ....................................... 819
health check URL .............................................................782 IDP configuration.........................................................813, 818
Heartbeat Interval ............................................................ 269 IDP deployment examples .............................................. 815
Heartbeat Timeout ..............................................................269 IDP interaction ...................................................................... 817
Host Checker IDP licensing...................................................................... 818
auto-upgrade ............................................................ 542 IDP sensor policies ............................................................. 820
execution ................................................................... 532 IDP with IF-MAP, example ................................................ 469
frequency check ......................................................... 540 IDP, automatic response ................................................. 823
installation ............................................................. 542 IDP, interoperability.......................................................... 817
installer IDP, quarantining users manually................................. 824
directory ................................................................. 532 IDP, using with UAC.....................................................813, 818
enabling ............................................................. 533 IF-MAP and IDP ............................................................ 467
logging, disabling .................................................... 544 IF-MAP client clustering ......................................................467
machine certificate IF-MAP client, overview .................................................... 454
configuring ................................................................ 505 IF-MAP federation overview ............................................ 444
overview .................................................................... 490 IF-MAP federation, concept ............................................ 447
policies ....................................................................... 492 IF-MAP federation, workflow............................................. 451
remediation IF-MAP illustration .............................................................. 444
overview ............................................................. 535 IF-MAP server clustering .................................................... 465
specifying restrictions IF-MAP server, configuring ................................................ 453
overview ............................................................. 492 IF-MAP server, overview ................................................... 453
realm level....................................................531, 533 IF-MAP session-import and session-export,
role level.........................................................531, 533 concepts ......................................................................... 455
uninstalling ..........................................................................532 IF-MAP with IDP, example ................................................ 469
Host Checker patch assessment policies .................. 512 IF-MAP, DHCP and network equipment ..................... 469
Host Checker remediation, user experience ............. 536 IF-MAP, example ................................................................. 445
Host Checker variables ....................................................... 511 IF-MAP, using with Secure Access .................................. 444
Host Checker, compatability ............................................491 IMCs and IMVs, overview ....................................................491
Host Checker, configuration task summary .............. 494 IMV, third-party Host Checker policy ........................... 520
Host Checker, implementing .......................................... 531 Infranet Enforcer
Host Checker, installing manually ............................... 543 description of ................................................................ 3
Host Enforcer overview........................................................................... 7
enabling ...................................................................... 274 Infranet Enforcer policies, diagram .............................. 144
overview ...................................................................... 251 Infranet Enforcer, communication with.................80, 90
policies, configuring .................................................... 251 Infranet Enforcer, configuration overview................81, 91
traffic allowed by default.................................251, 275 Infranet Enforcers, certificates ............................................ 92
host, defining in resource policies ................................ 249 Infranet Enforcers, interoperability............................79, 81
hostname, configuring ....................................................... 574 initial configuration of OAC ................................................... 22
HSM firmware, upgrading (FIPS device) .................. 840 initial deployment, user experience ............................... 19
initializing keystore (FIPS device) ............................... 837

inner RADIUS proxy .............................................................. 175 Junos Enforcer, configuring ................................................. 86

installers Junos Enforcer, connecting ................................................88
preconfigured...........................................................54, 59 Junos Enforcer, IPsec ........................................................... 140
integrity measurement collectors (IMCs) and Junos Enforcers, certificates ................................................ 82
verifiers (IMVs) .................................................................491 Junos IDP, activating .......................................................... 820
interaction: clients, servers, and endpoints in an Junos Pulse
IF-MAP federated network ......................................... 446 sign-in notifications ................................................ 484
interface status and statistics ........................................ 574 Pulse Secure installer, creating....................................54, 59
interface, binding to a security zone........................83, 99
internal interface status and statistics......................... 574 K
internal interface, configuring................................548, 557 Keep-Alives RADIUS attribute ........................................ 377
internal RADIUS server, about ...................................... 166 Kerberos single sign-on, configuring ............................ 303
IP address keystore, importing and exporting (FIPS
restrictions...................................................241, 243, 533 device) ....................................................................... 840
specifying user requirements ................................ 241 keystore, initializing (FIPS device) ................................ 837
IP address, configuring...................................548, 553, 557
IP address. cluster ............................................................... 789 L
IP alias, defining .................................................................. 566 L7 Health Check URL ........................................................ 782
IP Phones Layer 2 credential provider
802.1X phones ............................................................ 173 Pulse Policy Secure.................................................... 70
IPsec address pool polices, configuring........................ 133 Layer 3 credential provider
IPsec enforcement, general............................................... 125 Pulse Policy Secure.................................................... 70
IPsec policies...................................................................121, 124 ldap server ......................................................................... 316
IPsec routing policies LDAP server catalog ............................................................... 435
routing policies, IPsec........................................126, 128 learned user settings, Pulse................................................. 39
IPsec, address pool policies led, device status ................................................................ 830
NAT, IPsec.......................................................................130 led, ethernet ...................................................................... 831
IPsec, bidirectional VPN polices ................................... 139 LEDs (FIPS device) ............................................................ 841
IPsec, configuration details on ScreenOS licenses
Enforcer ............................................................................ 137 upgrading OAC licenses.............................................31
IPsec, configuring ................................................................. 136 licenses for OAC, using with Policy Secure gateway .. 31
IPsec, configuring general.................................................. 126 licensing, IDP..................................................................... 818
IPsec, general ......................................................................... 123 limiting user sessions...................................................... 249
IPsec, general configuration......................................127, 128 link speed/duplex, configuring....................548, 553, 557
IPsec, overview...............................................................122, 123 load balancer, using with active/active luster ............ 782
IPsec, refreshing policies ................................................ 125 local authentication server ............................................. 282
IPsec, routing policy, configuring ..................................... 129 Local Computer
IPsec, transparent mode, source interface Pulse Policy Secure ................................................... 66
polices.............................................................................. 135 localized
IPsec, with Junos Enforcer ................................................ 140 sign-in notifications ................................................ 484
IPv4 address, configuring..............................548, 553, 557 location awareness
IPv6 address, configuring..............................548, 553, 557 configuring ...................................................................... 49
location awareness, with Pulse ........................................35
J location groups, about .................................................... 180
Java agent, configuring.......................................................... 74 location groups, configuring ............................................ 182
Juniper Networks EX Series Ethernet switch, using log file archiving................................................................ 658
with the IC series............................................................. 199 log severity............................................................................. 715
Junos CTC .................................................................................... 819
Junos Enforcer releases ........................................................ 81

Index
logging.....................................................................715, 716, 739 MS-CHAP-CPW-1 RADIUS attribute .............................. 377

client logs MS-CHAP-CPW-2 RADIUS attribute ......................... 377
disabling .................................................................... 544 MS-CHAP-Domain RADIUS attribute .............................. 377
clusters..................................................................784, 786 MS-CHAP-Error RADIUS attribute .................................... 377
login notifications MS-CHAP-LM-Enc-PW RADIUS attribute ................ 377
agentless .................................................................... 484 MS-CHAP-MPPE-Keys RADIUS attribute ..................... 377
Junos Pulse ................................................................... 484 MS-CHAP-NT-Enc-PW RADIUS attribute ................ 378
Login-IP-Host RADIUS attribute ..................................... 377 MS-CHAP-Response RADIUS attribute .................. 378
Login-IPv6-Host RADIUS attribute ................................ 377 MS-CHAP2-CPW RADIUS attribute .......................... 378
Login-LAT-Group RADIUS attribute ..............................377 MS-CHAP2-Response RADIUS attribute ..................... 378
Login-LAT-Node RADIUS attribute ................................377 MS-CHAP2-Success RADIUS attribute ................... 378
Login-LAT-Port RADIUS attribute .................................. 377 MS-Filter RADIUS attribute .............................................. 378
Login-LAT-Service RADIUS attribute ............................377 MS-Link-Drop-Time-Limit RADIUS attribute ............ 378
Login-Service RADIUS attribute ......................................377 MS-Link-Utilization-Threshold RADIUS
Login-TCP-Port RADIUS attribute .................................. 377 attribute ......................................................................... 378
MS-MPPE-Encryption-Policy RADIUS
M attribute ....................................................................... 378
MAC address authentication server............................ 328 MS-MPPE-Encryption-Types RADIUS
MAC address role, creating ............................................... 274 attribute ......................................................................... 378
MAC address, configuring requirement in Host MS-MPPE-Recv-Key RADIUS attribute ..................... 378
Checker policy.............................................................. 505 MS-MPPE-Send-Key RADIUS attribute.................... 378
machine account logins, Host Checker ...................... 495 MS-New-ARAP-Password RADIUS attribute ......... 378
machine authentication MS-Old-ARAP-Password RADIUS attribute........... 378
802.1X and Remote Desktop Protocol .................. 69 MS-Primary-DNS-Server RADIUS attribute................ 378
certificate authentication .......................................... 71 MS-Primary-NBNS-Server RADIUS attribute......... 378
configuration summary.............................................. 71 MS-RAS-Vendor RADIUS attribute ........................... 378
Pulse Policy Secure..............................66, 71 MS-RAS-Version RADIUS attribute ........................... 378
machine-only MS-Secondary-DNS-Server RADIUS attribute...... 378
authentication ............................................................ 64 MS-Secondary-NBNS-Server RADIUS
Macintosh version OAC............................................................ 14 attribute ....................................................................... 378
Macintosh version, OAC detailed configuration .......... 34 MTU, configuring...............................................548, 553, 557
macro
regmatch ..................................................................... 861 N
MAGx600-UAC SRX solution, licensing ..................... 216 NAS-Identifier RADIUS attribute...........................379, 381
maintenance tasks, delegating ..................................... 805 NAS-IP-Address RADIUS attribute.......................379, 381
malware, Host Checker policy ....................................... 496 NAS-IPv6-Address RADIUS attribute ..........................379
management interface status and statistics ............. 574 NAS-Port RADIUS attribute....................................379, 381
manuals NAS-Port-Id RADIUS attribute ..................................... 379
comments on ........................................................ xxxvii NAS-Port-Type RADIUS attribute ............................... 379
Max. Session Length ....................................................... 269 NetBIOS, configuring requirement in Host Checker
Message-Authenticator RADIUS attribute ................. 378 policy ...............................................................................505
monitoring .....................................................................................715 netmask
MS-Acct-Auth-Type RADIUS attribute ........................377 defining user requirements .................................... 241
MS-Acct-EAP-Type RADIUS attribute ..........................377 network interface status and statistics ........................ 574
MS-ARAP-Challenge RADIUS attribute .......................377 network policy server (NPS) with Host Checker
MS-ARAP-Password-Change-Reason RADIUS policy ............................................................................... 527
attribute ................................................................................ 377 network settings
MS-BAP-Usage RADIUS attribute ..................................377 configuring ......................................................................... 589
MS-CHAP-Challenge RADIUS attribute ....................... 377 network, OAC, initial configuration of............................ 24

NIS Server ...............................................................................367 policies

nodes, cluster ........................................................................ 778 ....................................................................................233, 471
non-Pulse Secure supplicant for 802.1X, See also authentication policies
configuring .................................................................... 205 See also sign-in policies
non-tunneled protocols .................................................. 206 Host Enforcer ............................................................... 251
non-UAC agent, definition................................................. 475 See also authentication policies
notice icons ......................................................................xxxv See also sign-in policies
notifications to agentless users .................................... 482 policies, Infranet Enforcer ................................................. 144
NPS, Host Checker policy ............................................... 527 policy decision point, Infranet
NSM, using with the Policy Secure gateway ........... 209 Enforcers................................................................80, 89, 90
NTP ............................................................................. 571 policy enforcement point, Infranet Enforcers ............... 79
port
O defining in resource policies ................................. 249
OAC requirements, configuring ....................................... 505
certificates, configuring .............................................. 30 Port-Limit RADIUS attribute ........................................... 379
Host Enforcer policy, configuring ........................... 251 post-authentication sign-in notifications,
initial configuration of ............................................... 22 configuring ................................................................... 484
installation methods .................................................. 16 power supply, replacing .................................................. 834
licenses, using with Policy Secure gateway ......... 31 pre-authentication sign-in notifications,
wireless settings, initial configuration of .............. 23 configuring .................................................................... 484
OAC, authentication method ......................................... 168 preconfigured installer..................................................54, 59
OAC, configuring for 802.1X (Windows or preconfigured OAC installer .............................................. 29
Macintosh) ........................................................................ 32 predefined Host Checker policies ................................ 498
OAC, installing manually (Windows only) ...................... 31 process check, configuring............................................... 505
OCSP, enabling ................................................................. 611 profile, OAC, initial configuration of ...............................23
Odyssey Access Client (OAC) Prompt RADIUS attribute ................................................. 379
description of ................................................................ 3 protecting against malware, spyware ........................ 496
Online Certification Status Protocol ............................... 611 protocol
OpenSSL, for Enforcer certificate .................................... 95 defining in resource policies ................................. 249
outer RADIUS proxy ............................................................. 175 protocol, defining in resource policies ........................ 249
overlapping IP with vsys ..................................................... 120 proxy RADIUS .................................................................... 426
proxy server, Host Checker updates.............................. 517
P Proxy-State RADIUS attribute ......................................... 379
password Pulse
management and session migration............................................. 233
LDAP ................................................................323 description of ................................................................ 3
Password Authentication Protocol (PAP) with installation methods ..................................................16
plain-text passwords......................................................169 Pulse and OAC ............................................................................. 34
password restrictions, specifying for a realm or Pulse and OAC on endpoints ............................................38
role ................................................................................... 245 Pulse and security certificates ..........................................35
Password-Retry RADIUS attribute ................................. 379 Pulse components overview..............................................38
patch assessment rule, configuring ...............................518 Pulse connections, configuring.......................................... 46
patch assessment version monitoring .......................... 515 Pulse connections, overview ............................................. 39
patch assessment, in Host Checker policy ................ 512 Pulse Launcher
performance, IF-MAP ..................................................... 449 examples ..........................................................................62
permissive merge, overview .............................................264 Pulse, component set options....................................... 52
persistent data, defined ................................................. 784 Pulse, configuration overview ............................................. 37
ping command ................................................................ 589 Pulse, configuring as a role option ..................................36
PKI, defined ...........................................................................593 Pulse, configuring components .......................................53

Index
Pulse, connection set options ........................................ 40 RADIUS tunnel attribute, for configuring VLAN
Pulse, default configuration ............................................... 40 assignment .................................................................... 196
Pulse, learned user settings .............................................39 RADIUS, general description .......................................... 166
Pulse, location awareness overview ................................35 RADIUS-802.1X enforcement
Pulse, platform support ....................................................36 overview of using 802.1X with UAC ............................. 3
Pulse, user experience ...................................................... 35 realm
command line launcher administrator ............................................................... 806
examples .......................................................................62 defined.......................................................................12, 233
managing ...................................................................... 806
Q mapping to sign-in policy ...................................... 480
quick start, federation configuration preconfigured realms .................................................12
federation, quick start ............................................ 450 security requirements............................................. 233
realm configuration for RADIUS proxy............................175
R realm selection, flowchart ..................................................477
RADIUS access policies, use cases .................................. 196 reason strings, for IMV/IMC remediation
RADIUS attribute logging, about .................................. 195 reason strings............................................................ 535
RADIUS attribute logging, configuring ......................... 196 redundancy, active/passive mode .............................. 780
RADIUS attributes polices, creating ............................... 192 registry setting checks, configuring .............................. 505
RADIUS attributes policies, about ............................... 190 regmatch............................................................................. 861
RADIUS attributes policies, precautions before remediation
configuring ................................................................................ 191 overview...................................................................... 535
RADIUS attributes, using to avoid disconnecting remediation, antivirus Host Checker rule ................... 500
OAC concurrent connections remediation, Host Checker firewall rule ....................... 502
OAC, avoiding disconnecting concurrent remediation, user experience ....................................... 536
connections............................................................ 198 Remote Desktop Protocol
RADIUS authentication and accounting, time 802.1X and machine authentication..................... 69
limits ............................................................................................ 176 remote IMV server, configuring ....................................... 521
RADIUS client dictionary files replicas, configuring ........................................................... 465
dictionary files .............................................................. 186 replicas, federation.............................................................. 463
RADIUS client dictionary, duplicating and Reply-Message RADIUS attribute .................................. 379
modifying.................................................................................. 187 resource access policies with EX Series switch
RADIUS client dictionary, uploading.............................. 187 EX Series switch, resource access policy
RADIUS client, configuring................................................185 limitations.............................................................. 161
RADIUS client, overview..................................................... 183 resource access policies, about ..................................... 145
RADIUS client, precautions before configuring ........ 184 resource access policies, configuring ............................147
RADIUS client, sending disconnect requests to NADs resource access policies, deny message .......................145
dynamic authorization support ............................ 184 resource policies
RADIUS proxy Host Enforcer ............................................................... 251
and role restrictions ................................................ 263 server........................................................................... 249
RADIUS proxy, about ........................................................ 174 role
RADIUS proxy, use cases .................................................... 174 administrator ............................................................... 806
RADIUS request attribute policies, about .................. 194 defined....................................................................233, 261
RADIUS request attribute policy, configuring .............195 evaluating ...................................................................... 262
RADIUS request attributes, specifying for a mapping...................................233, 264, 425, 432, 433
realm ................................................................................247 merging ...................................................................... 264
RADIUS server ................................................................... 372 options, managing.......................................................267
RADIUS sub-protocols and authentication restrictions................................................................. 268
servers ............................................................................ 475 settings, managing ......................................................267

sign-in restrictions session scripts, configuring ..............................................274

by Host Checker policy .................................. 532 session time-outs, configuring ....................................... 233
user session options, specifying .......................... 268 session-export policies, advanced
role restrictions, with RADIUS proxy ............................ 268 configuration................................................................. 459
role-based policies, IDP ................................................. 825 session-export policies, configuring ............................. 458
role-mapping ..................................................................... 432 session-import and session-export policies
route mode, ScreenOS Enforcer .....................................102 overview.......................................................................... 455
rule, configuring for role-mapping............................... 433 session-import policies, advanced .............................. 460
session-import policies, configuring ............................ 460
S session-import, session-export policies,
SCP, system snapshot ...................................................... 589 advanced ........................................................................ 457
ScreenOS Enforcer as a RADIUS Client of IC Series session-import, session-export policies,
for 802.1X ........................................................................... 202 conventions ................................................................... 456
ScreenOS Enforcer releases.................................................. 92 session-import, session-export policies, default
ScreenOS Enforcer, configuring ....................................... 100 action .............................................................................. 457
ScreenOS Enforcer, connecting ........................................ 101 session-import, session-export policies,
ScreenOS IDP, activating .................................................. 820 modifying ....................................................................... 461
ScreenOS ISG-IDP ............................................................ 819 session-timeout attribute
scripts, configuring start and end ................................. 274 RADIUS attributes........................................................ 193
security administrator........................................................ 806 Session-Timeout RADIUS attribute.............................. 379
security certificates, with Pulse.......................................... 35 sessions, federation client ............................................. 462
security officer password, changing (FIPS sessions, federation server ............................................ 463
device) ............................................................................ 839 SHA (Host Checker) ........................................................ 527
security officer, name and password restrictions SHV (Host Checker) ........................................................ 527
(FIPS device) ............................................................ 836 sign-in
security zone.....................................................................83, 99 management tasks, delegating ............................ 805
sensor policies for IDP, configuring............................... 820 options, user restrictions.................................243, 532
serial console, using for system tasks.......................... 589 policies
serial console, using to configure cluster changing order ................................................ 481
properties ....................................................................... 797 configuring .......................................................... 480
server ........................................................................................... 12 defined ............................................................... 471
catalog, configuring.................................................... 435 evaluating .............................................................. 481
resource policies ...................................................... 249 sign-in notifications
See also authentication server agentless .................................................................... 484
server settings, IF-MAP federation ................................ 453 Junos Pulse.................................................................... 484
server, IF-MAP federation.................................................. 453 localized ....................................................................484
Service-Type RADIUS attribute ..................................... 379 sign-in notifications, about ........................................... 482
session sign-in pages, configuring ................................................ 485
options, specifying .................................................. 268 sign-in policies, administrator .......................................... 474
role, defined .............................................................. 262 sign-in policies, before configuring ................................479
timeout, maximum length .................................... 268 sign-in policies, configuring....................................473, 480
session extension with reauthentication, role single sign-on ...................................................................... 70
configuration .......................................................................... 269 single sign-on using Kerberos, configuring ................ 303
session migration ............................................................ 255 SiteMinder Server ............................................................... 396
and authentication server support ..................... 258 SMS (System Management Server) ............................ 514
and session timeout ................................................ 257 snapshots, creating ........................................................... 589
configuring ......................................................................... 260 SNMP agent............................................................................ 719
task summary .......................................................... 259 snmp, using to monitor cluster ....................................... 793
with Pulse ...................................................................... 233 SOH (statement of health) .............................................. 527

Index
SOH, in Host Checker policy .......................................... 527 trusted CA certificate, See certificate, trusted CA
source interface polices, configuring ............................. 135 certificate
source interface policies trusted client CAs
transparent mode, source interface CA certificate ............................................................... 608
policies .................................................................... 135 Trusted Network Connect (TNC) ................................. 490
source IP enforcement, about ....................................... 149 trusted server for OAC, initial configuration .................. 24
source IP restrictions on Policy Secure gateway ....... 233 Tunnel-Assignment-ID RADIUS attribute .................. 379
speed/duplex, configuring.............................548, 553, 557 Tunnel-Client-Auth-ID RADIUS attribute .................. 379
SPNEGO, about ................................................................. 217 Tunnel-Client-Endpoint RADIUS attribute ................ 379
SQL Server.............................................................................. 416 Tunnel-Link-Reject RADIUS attribute ......................... 380
SQUID proxy.............................................................................110 Tunnel-Link-Start RADIUS attribute ............................. 380
SSO, See Kerberos single sign-on Tunnel-Link-Stop RADIUS attribute............................. 380
State RADIUS attribute ...................................................379 Tunnel-Medium-Type RADIUS attribute .................... 380
state synchronization ..................................................... 784 Tunnel-Password RADIUS attribute ............................. 380
statement of health, configuring Host Checker Tunnel-Preference RADIUS attribute .......................... 380
policy ............................................................................... 529 Tunnel-Private-Group-ID RADIUS attribute ............... 380
statement of health, Microsoft...................................... 527 Tunnel-Reject RADIUS attribute .................................... 380
sub-protocols, RADIUS...................................................475 Tunnel-Server-Auth-ID RADIUS attribute ................... 380
super administrator account, creating........................ 589 Tunnel-Server-Endpoint RADIUS attribute ................ 380
support, technical See technical support Tunnel-Start RADIUS attribute....................................... 380
suspend a connection .......................................................... 42 Tunnel-Stop RADIUS attribute ........................................ 380
switches, configuring access with non-tunneled Tunnel-Type RADIUS attribute ....................................... 380
protocols ............................................................................ 206
system U
administrator ................................................................ 806 UAC agent, description of ................................................... 3
management tasks, delegating ............................ 805 UAC Enforer interoperability policies ........................... 144
state data described.................................................. 784 UI views, customizing ......................................................... 440
system archiving .............................................................. 658 Pulse Policy Secure solution agentless
system management server (SMS) with Host access
Checker policy ............................................................... 514 enabling on role ..................................................274
deploying to users.......................................................16
T Kerberos single sign-on, configuring ................... 303
tcp_in and tcp_out, for Host Enforcer policies ......... 249 overview of ..................................................................... 3
technical support summary of steps for configuring ............................ 11
contacting PSGSC ........................................................... xxxvii upgrading
Telephone-number RADIUS attribute.......................... 379 Endpoint Security Assessment Plug-In ............. 538
Termination-Action RADIUS attribute.......................... 379 upgrading, Host Checker................................................ 492
text conventions ............................................................. xxxv URLs sign-in URLs, defining ........................................... 480
third-party IMVs, configuring ...........................................520 user
time-out, ..............................................................................233 accounts
See also session time-outs creating .................................................................. 265
time-to-live, DNS ................................................................ 51 attributes, configuring............................................... 433
timeout, maximum session .......................................... 268 role............................................................................... 261
timing, federation ................................................................ 449 defined ............................................................... 261
traceroute command ..................................................... 589 See also role
transient data, defined ................................................... 784 session data.................................................................. 784
transparent mode, ScreenOS Enforcer........................ 106 sign-in restrictions
troubleshooting, IF-MAP federation .............................462 by browser .............................................................243

user access control

specifying resources for ............................................ 249
user role firewall policies, about ................................... 215
User role policies, with Junos Enforcer .........................148
user roles, configuring for Pulse ....................................... 36
user statistics ......................................................................... 748
user-after-desktop
authentication ............................................................. 65
User-Name RADIUS attribute...............................380, 381
User-Password RADIUS attribute ................................ 380
V
valid roles, defined.....................................................264, 432
variables, in Host Checker rules........................................ 511
Vendor-Specific RADIUS attribute............................... 380
version monitoring virus signatures and firewall
...................................................................................... 515
viewing ScreenOS Enforcer configuration .................. 108
VIP, failing over ..................................................................... 782
virtual port, defining ........................................................... 566
virus signature version monitoring .................................. 515
virus signatures
checking age ................................................................ 505
VLAN assignment, heterogeneous
environment ................................................................... 197
VLAN, enabling endpoints to connect......................... 207
vsys, ScreenOS Enforcer ...................................................... 116
overlapping IP addresses ........................................... 117
W
web user password, changing (FIPS device) ........... 839
Windows authentication, ................................................ 290
WINS, configuring ................................................................ 574
wireless settings, OAC, initial configuration of ............ 23
wireless suppression ..........................................................41
X
xml files, modifying ........................................................ 680
xml operation attributes .................................................. 686
xml use case ......................................................................... 688
xml, working with ........................................................... 680

Pan Os 50 Cli Reference Guide

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Pan Os 50 Cli Reference Guide

Enviado por

Direitos autorais:

Formatos disponíveis

Pulse Policy Secure

Product Release 5.0

Document Revision 1.0

© 2015 by Pulse Secure, LLC. All rights reserved.

Pulse Policy Secure Administration Guide

END USER LICENSE AGREEMENT

© 2015 by Pulse Secure, LLC. All rights reserved

ii © 2015 by Pulse Secure, LLC. All rights reserved.

Part 1 Getting Started

Part 2 Access Management Framework

Part 3 Endpoint Defense

Part 4 System Management

© 2015 by Pulse Secure, LLC. All rights reserved. iii

Chapter 25 Deployments with IDP ................................................................................................. 813

iv © 2015 by Pulse Secure, LLC. All rights reserved.

Part 1 Getting Started

© 2015 by Pulse Secure, LLC. All rights reserved. v

Provisioning Detailed Configuration Profiles for Macintosh OAC Endpoints ............. 34

vi © 2015 by Pulse Secure, LLC. All rights reserved.

Chapter 3 Deployments with ScreenOS and Junos OS Infranet Enforcers ......................... 77

© 2015 by Pulse Secure, LLC. All rights reserved. vii

Deployment Example ............................................................................................................ 118

viii © 2015 by Pulse Secure, LLC. All rights reserved.

Chapter 4 Deployments with EX Series Ethernet Switches .................................................... 157

© 2015 by Pulse Secure, LLC. All rights reserved. ix

Use Case 4: Configuring VLAN Assignment in a Heterogeneous

Part 2 Access Management Framework

x © 2015 by Pulse Secure, LLC. All rights reserved.

Accessing User Roles ........................................................................................................... 233

© 2015 by Pulse Secure, LLC. All rights reserved. xi

Chapter 10 AAA Servers ............................................................................................................................279

xii © 2015 by Pulse Secure, LLC. All rights reserved.

Using the Certificate Server ........................................................................................................312

© 2015 by Pulse Secure, LLC. All rights reserved. xiii

Configuring the RADIUS Framework ...................................................................... 357

xiv © 2015 by Pulse Secure, LLC. All rights reserved.

Chapter 11 Authentication Realms ........................................................................................................ 425

© 2015 by Pulse Secure, LLC. All rights reserved. xv

Chapter 13 Sign-in Policies .................................................................................................................. 471

Part 3 Endpoint Defense

xvi © 2015 by Pulse Secure, LLC. All rights reserved.

Configuring a Remote IMV Server ..............................................................................................521

Part 4 System Management

© 2015 by Pulse Secure, LLC. All rights reserved. xvii

Chapter 16 Certificate Security Administration ............................................................................. 593

xviii © 2015 by Pulse Secure, LLC. All rights reserved.

Using TCP Dump to View Cipher Information ................................................................644

© 2015 by Pulse Secure, LLC. All rights reserved. xix

Restarting, Rebooting, and Shutting Down the System..................................................... 711

xx © 2015 by Pulse Secure, LLC. All rights reserved.

Adding Multiple Cluster Nodes ........................................................................................... 788

© 2015 by Pulse Secure, LLC. All rights reserved. xxi

Identifying and Managing Quarantined Users Manually ............................................. 824

xxii © 2015 by Pulse Secure, LLC. All rights reserved.

Part 2 Access Management Framework

© 2015 by Pulse Secure, LLC. All rights reserved. xxiii

Chapter 9 User Roles ............................................................................................................................... 261

xxiv © 2015 by Pulse Secure, LLC. All rights reserved.

Figure 71: User Role General Configuration .......................................................................... 353

Part 3 Endpoint Defense

© 2015 by Pulse Secure, LLC. All rights reserved. xxv

Part 4 System Management

xxvi © 2015 by Pulse Secure, LLC. All rights reserved.