Junos Pulse Access Control Service
Junos SRX Enforcer Feature Guide
Release
5.0
Published: 2014-02-10
Copyright © 2014, Juniper Networks, Inc.
Juniper Networks, Inc.1194 North Mathilda AvenueSunnyvale, California 94089USA408-745-2000www.juniper.net
Copyright © 2014, Juniper Networks, Inc. All rights reserved.
Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the UnitedStates and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All othertrademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.
Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify,transfer, or otherwise revise this publication without notice.
Junos Pulse Access Control Service Junos SRX Enforcer Feature GuideRelease 5.0Copyright © 2014, Juniper Networks, Inc.All rights reserved.
The information in this document is current as of the date on the title page.
YEAR 2000 NOTICE
Juniper Networks hardware and software products are Year 2000 compliant. Junos OS has no known time-related limitations through theyear 2038. However, the NTP application is known to have some difficulty in the year 2036.
ENDUSER LICENSE AGREEMENT
The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with) Juniper Networkssoftware. Use of such software is subject to the terms and conditions of the End User License Agreement (“EULA”) posted athttp://www.juniper.net/support/eula.html. By downloading, installing or using such software, you agree to the terms and conditions ofthat EULA.
Copyright © 2014, Juniper Networks, Inc.ii
Table of Contents
About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Documentation and Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Supported Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Self-Help Online Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Part 1 Overview
Chapter 1 Deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Understanding Deployments with Junos Infranet Enforcers . . . . . . . . . . . . . . . . . . 3
Communication Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Configuration Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Version Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Using Certificate-Based Security with Junos Enforcer Deployments . . . . . . . . . . . . 6
Chapter 2 Infranet Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Infranet Enforcer Policies Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Using the Infranet Enforcer as a Policy Enforcement Point . . . . . . . . . . . . . . . . . . 10
Understanding Infranet Enforcer Source IP Security Policies . . . . . . . . . . . . . . . . . . 11
Source IP Security Policy Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
ScreenOS Infranet Enforcer Configuration Summary . . . . . . . . . . . . . . . . . . . 12
Junos Infranet Enforcer Configuration Summary . . . . . . . . . . . . . . . . . . . . . . . 13
Chapter 3 Captive Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Understanding the Infranet Enforcer Captive Portal Feature . . . . . . . . . . . . . . . . . 15
Before Configuring Captive Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Chapter 4 User-Role-Based Firewall Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
User-Role Firewall Policies Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Terminology for Active Directory SPNEGO Authentication with User Role
Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
User Authentication Sequence for Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . 21
Active Directory Integration Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Sample Active Directory Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
User Log Messages on the MAG Series Device . . . . . . . . . . . . . . . . . . . . . . . . 24
Supported Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
iiiCopyright © 2014, Juniper Networks, Inc.
Chapter 5 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
IPsec and the Junos Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
IPsec Policies on the Junos Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Using IPsec with the Junos Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
IPsec Enforcement on the Junos Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Before Configuring IPsec on the Junos Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
IPsec Routing Policies for the Junos Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Before Configuring IPsec Routing Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Using IP Address Pool Policies for IPsec in a NAT Environment . . . . . . . . . . . . . . . 29
Understanding IP Address Pool Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Chapter 6 Resource Access Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
About Resource Access Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Using the Juniper Networks EX Series Ethernet Switch as an Enforcer with
a Resource Access Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Specifying Resources for User Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Chapter 7 User Role Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
User Role Policies on the Junos Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Chapter 8 Auth Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Understanding Infranet Enforcer Auth Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Understanding Dynamic Auth Table Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Part 2 Configuration
Chapter 9 Junos Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Configuring the Junos Enforcer to Communicate with the Access Control
Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Setting Up the Junos Enforcer to Work with the Access Control Service . . . . . . . 46
Chapter 10 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Configuring Junos Enforcer IPsec Routing Policies . . . . . . . . . . . . . . . . . . . . . . . . . 49
Configuration Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Configuring an IPsec Routing Policy for the Junos Enforcer . . . . . . . . . . . . . . . . . . 53
Configuring an IP Address Pool Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Chapter 11 Resource Access Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Configuring Resource Access Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Chapter 12 Auth Tables and Mapping Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Configuring Dynamic Auth Table Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Configuring Auth Table Mapping Policies for Source IP Enforcement . . . . . . . . . . 59
Configuring Auth Table Mapping Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Copyright © 2014, Juniper Networks, Inc.iv
Junos SRX Enforcer Feature Guide
Chapter 13 User-Role-Based Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Configuration Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Configure an Active Directory Instance on Junos Pulse Access Control
Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Configuring SPNEGO Authentication in Browsers . . . . . . . . . . . . . . . . . . . . . . . . . 65
Browser Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Create the Keytab File and Enable Single Sign-on . . . . . . . . . . . . . . . . . . . . . . . . . 66
Part 3 Administration
Chapter 14 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Binding an Interface to a Security Zone on a Junos Enforcer . . . . . . . . . . . . . . . . . . 71
Binding the Physical Interface on the Junos Enforcer . . . . . . . . . . . . . . . . . . . . . . . 73
Chapter 15 Junos Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Setting Up the Junos Enforcer toWork with Junos Pulse Access Control
Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Connecting with the Junos Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Chapter 16 Redirect Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Creating a Redirect Policy on the Infranet Enforcer . . . . . . . . . . . . . . . . . . . . . . . . 79
Creating a Redirect Policy on the Junos Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Chapter 17 Captive Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Overriding the Default Redirection Destination for Captive Portal . . . . . . . . . . . . 83
vCopyright © 2014, Juniper Networks, Inc.
Table of Contents
Copyright © 2014, Juniper Networks, Inc.vi
Junos SRX Enforcer Feature Guide
List of Figures
Part 1 Overview
Chapter 2 Infranet Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figure 1: Policy Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Chapter 3 Captive Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Figure 2: Captive Portal Event Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Chapter 4 User-Role-Based Firewall Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Figure 3: Example Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Chapter 5 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 4: Using an IP Address Pool in a NAT Environment . . . . . . . . . . . . . . . . . . . 30
Part 2 Configuration
Chapter 12 Auth Tables and Mapping Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Figure 5: Using Auth Table Mapping Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Part 3 Administration
Chapter 14 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Figure 6: Binding the Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
viiCopyright © 2014, Juniper Networks, Inc.
Copyright © 2014, Juniper Networks, Inc.viii
Junos SRX Enforcer Feature Guide
List of Tables
About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Table 1: Notice Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Table 2: Text and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Part 1 Overview
Chapter 1 Deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Table 3: Junos Enforcer Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Chapter 4 User-Role-Based Firewall Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Table 4: Understanding Log Messages Related to Active Directory and
SPNEGO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Chapter 6 Resource Access Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Table 5: DNS Hostname Special Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Table 6: Port Possible Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Part 2 Configuration
Chapter 10 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Table 7: Syntax for IP Address Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
ixCopyright © 2014, Juniper Networks, Inc.
Copyright © 2014, Juniper Networks, Inc.x
Junos SRX Enforcer Feature Guide
About the Documentation
• Documentation and Release Notes on page xi
• Supported Platforms on page xi
• Documentation Conventions on page xi
• Documentation Feedback on page xiii
• Requesting Technical Support on page xiii
Documentation and Release Notes
To obtain the most current version of all Juniper Networks®technical documentation,
see the product documentation page on the Juniper Networks website at
http://www.juniper.net/techpubs/.
If the information in the latest release notes differs from the information in the
documentation, follow the product Release Notes.
Juniper Networks Books publishes books by Juniper Networks engineers and subject
matter experts. These books go beyond the technical documentation to explore the
nuances of network architecture, deployment, and administration. The current list can
be viewed at http://www.juniper.net/books.
Supported Platforms
For the features described in this document, the following platforms are supported:
• IC4500
• IC6500 FIPS
• IC6500
• MAG Series
Documentation Conventions
Table 1 on page xii defines notice icons used in this guide.
xiCopyright © 2014, Juniper Networks, Inc.
Table 1: Notice Icons
DescriptionMeaningIcon
Indicates important features or instructions.Informational note
Indicates a situation that might result in loss of data or hardware damage.Caution
Alerts you to the risk of personal injury or death.Warning
Alerts you to the risk of personal injury from a laser.Laser warning
Table 2 on page xii defines the text and syntax conventions used in this guide.
Table 2: Text and Syntax Conventions
ExamplesDescriptionConvention
To enter configuration mode, type theconfigure command:
user@host> configure
Represents text that you type.Bold text like this
user@host> show chassis alarms
No alarms currently active
Represents output that appears on theterminal screen.
Fixed-width text like this
• A policy term is a named structurethat defines match conditions andactions.
• Junos OS CLI User Guide
• RFC 1997,BGPCommunities Attribute
• Introduces or emphasizes importantnew terms.
• Identifies guide names.
• Identifies RFC and Internet draft titles.
Italic text like this
Configure themachine’s domain name:
[edit]root@# set system domain-namedomain-name
Represents variables (options for whichyou substitute a value) in commands orconfiguration statements.
Italic text like this
• To configure a stub area, include thestub statement at the [edit protocolsospf area area-id] hierarchy level.
• Theconsoleport is labeledCONSOLE.
Represents names of configurationstatements, commands, files, anddirectories; configurationhierarchy levels;or labels on routing platformcomponents.
Text like this
stub <default-metricmetric>;Encloses optional keywords or variables.< > (angle brackets)
Copyright © 2014, Juniper Networks, Inc.xii
Junos SRX Enforcer Feature Guide
Table 2: Text and Syntax Conventions (continued)
ExamplesDescriptionConvention
broadcast | multicast
(string1 | string2 | string3)
Indicates a choice between themutuallyexclusive keywords or variables on eitherside of the symbol. The set of choices isoften enclosed in parentheses for clarity.
| (pipe symbol)
rsvp { # Required for dynamicMPLS onlyIndicates a comment specified on thesame lineas theconfiguration statementto which it applies.
# (pound sign)
community namemembers [community-ids ]
Encloses a variable for which you cansubstitute one or more values.
[ ] (square brackets)
[edit]routing-options {static {route default {nexthop address;retain;
}}
}
Identifies a level in the configurationhierarchy.
Indention and braces ( { } )
Identifies a leaf statement at aconfiguration hierarchy level.
; (semicolon)
GUI Conventions
• In the Logical Interfaces box, selectAll Interfaces.
• To cancel the configuration, clickCancel.
Representsgraphicaluser interface(GUI)items you click or select.
Bold text like this
In the configuration editor hierarchy,select Protocols>Ospf.
Separates levels in a hierarchy of menuselections.
> (bold right angle bracket)
Documentation Feedback
We encourage you to provide feedback, comments, and suggestions so that we can
improve the documentation. You can send your comments to
[email protected], or fill out the documentation feedback form at
https://www.juniper.net/cgi-bin/docbugreport/. If you are using e-mail, be sure to include
the following information with your comments:
• Document or topic name
• URL or page number
• Software release version (if applicable)
Requesting Technical Support
Technical product support is available through the JuniperNetworksTechnicalAssistance
Center (JTAC). If you are a customer with an active J-Care or JNASC support contract,
xiiiCopyright © 2014, Juniper Networks, Inc.
About the Documentation
or are covered under warranty, and need post-sales technical support, you can access
our tools and resources online or open a case with JTAC.
• JTAC policies—For a complete understanding of our JTAC procedures and policies,
review the JTAC User Guide located at
http://www.juniper.net/us/en/local/pdf/resource-guides/7100059-en.pdf.
• Product warranties—For product warranty information, visit
http://www.juniper.net/support/warranty/.
• JTAC hours of operation—The JTAC centers have resources available 24 hours a day,
7 days a week, 365 days a year.
Self-Help Online Tools and Resources
For quick and easy problem resolution, Juniper Networks has designed an online
self-service portal called the Customer Support Center (CSC) that provides youwith the
following features:
• Find CSC offerings: http://www.juniper.net/customers/support/
• Search for known bugs: http://www2.juniper.net/kb/
• Find product documentation: http://www.juniper.net/techpubs/
• Find solutions and answer questions using our Knowledge Base: http://kb.juniper.net/
• Download the latest versions of software and review release notes:
http://www.juniper.net/customers/csc/software/
• Search technical bulletins for relevant hardware and software notifications:
https://www.juniper.net/alerts/
• Join and participate in the Juniper Networks Community Forum:
http://www.juniper.net/company/communities/
• Open a case online in the CSC Case Management tool: http://www.juniper.net/cm/
Toverify serviceentitlementbyproduct serial number, useourSerialNumberEntitlement
(SNE) Tool: https://tools.juniper.net/SerialNumberEntitlementSearch/
Opening a Casewith JTAC
You can open a case with JTAC on theWeb or by telephone.
• Use the Case Management tool in the CSC at http://www.juniper.net/cm/.
• Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico).
For international or direct-dial options in countries without toll-free numbers, see
http://www.juniper.net/support/requesting-support.html.
Copyright © 2014, Juniper Networks, Inc.xiv
Junos SRX Enforcer Feature Guide
PART 1
Overview
• Deployments on page 3
• Infranet Enforcer on page 9
• Captive Portal on page 15
• User-Role-Based Firewall Policies on page 19
• IPsec on page 25
• Resource Access Policies on page 33
• User Role Policies on page 37
• Auth Tables on page 39
1Copyright © 2014, Juniper Networks, Inc.
Copyright © 2014, Juniper Networks, Inc.2
Junos SRX Enforcer Feature Guide
CHAPTER 1
Deployments
• Understanding Deployments with Junos Infranet Enforcers on page 3
• Using Certificate-Based Security with Junos Enforcer Deployments on page 6
Understanding Deployments with Junos Infranet Enforcers
This topic provides an overview of Junos Pulse Access Control Service deploymentswith
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
following information:
• Communication Summary on page 3
• Configuration Summary on page 4
• Version Requirements on page 5
Communication Summary
This section describes the communication between the Access Control Service and the
Infranet Enforcer.
• At startup, the Junos Enforcer contacts the Access Control Service. The Junos Enforcer
uses the proprietary Junos Infranet Enforcer Protocol over an SSL connection.
• The Junos Enforcer runs on top of SSL andmakes a direct connection with the Access
ControlService.Optionally, theAccessControlServiceauthenticates the JunosEnforcer
bymeansofaclient certificateobtainedduring theSSLhandshake.All communications
between the Access Control Service and the Junos Enforcer are through the Junos
Enforcer Protocol over SSL.
• With the Junos Enforcer, you can configure the Access Control Service 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
KeyExchange (IKE)withanEnforcer policy. TheVPNtunnel and the IPsecpolicy enable
the user's endpoint (OAC or Pulse) to use an IPsec tunnel to the Junos Enforcer and
access protected resources. The Access Control Service sends the necessary setup
information to the client.
3Copyright © 2014, Juniper Networks, Inc.
• Whenthe JunosEnforcerdetects traffic fromanendpoint thatmatchesa JunosEnforcer
policy, it uses the endpoint’s auth table entry to determine the role(s) associated with
that user.
• The Junos Enforcer thenmatches 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 Access Control Service 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 Access Control Service, when you
change the configuration of a user’s role, or when you disable all user accounts on the
Access Control Service in response to a security problem (such as a virus on the
network).
If you have a cluster of Junos Pulse Access Control Service 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 Junos Pulse Access Control Service devices to another,
or fromone non-clustered device to another, you candefinemultiple 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 Junos Pulse Access Control Service 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 canuse the JunosEnforcer as apolicy enforcementpoint for anynumber ofAccess
Control Service or Instant Virtual Extranet (IVE) Secure Access devices in a federated
network.
Configuration Summary
Youmust perform the following basic tasks to use the Access Control Service with a
Junos Enforcer:
• Configure the Access Control Service and the Junos Enforcer to communicate over a
secure connection.
• Configureuser authenticationandauthorizationby settingupuser roles, authentication
and authorization servers, and authentication realms.
• Configure resource access policies 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
Copyright © 2014, Juniper Networks, Inc.4
Junos SRX Enforcer Feature Guide
• 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 supportedwith current and future releases of UAC and Junos.
A JSeriesdeviceasaLayer 3 enforcementpoint is supportedwith futureUACreleases, 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 enforcementpoint.
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 3 on page 5
Table 3: Junos Enforcer Features
Supported/Not SupportedFeature
SupportedDynamic auth table allocation
SupportedResource access policies
SupportedAuth table mapping
SupportedSource IP
Supported with Release 10.0IPsec
SupportedHigh availability
SupportedDenymessage to users
Supported with Release 10.0Coordinated Threat Control (CTC – equivalent to SSGIDP)
Not supportedSupport for vsys
Supported with Release 10.2Captive Portal
5Copyright © 2014, Juniper Networks, Inc.
Chapter 1: Deployments
NOTE:
RelatedDocumentation
Using Certificate-Based Security with Junos Enforcer Deployments on page 6•
• Binding an Interface to a Security Zone on a Junos Enforcer on page 71
• Configuring the Junos Enforcer to Communicate with the Access Control Service on
page 45
Using Certificate-Based Security with Junos Enforcer Deployments
The Access Control Service and the Junos Enforcer communicate over a secure channel.
Optionally, you can use digital security certificates as an enhancedmechanism 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 Access Control Service, the devices
exchange security information to verify secure communication.
• In Junos implementations, the Junos Enforcer presents its password to the Access
Control Service, and theAccessControl Service optionally verifies thepasswordbefore
further communication is initiated. Once verified, the Access Control Service 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 Access Control Service
and the JunosEnforcer is secure, youcreateacertificatehierarchy for this trust relationship,
and then upload the appropriate certificates into the devices.
Copyright © 2014, Juniper Networks, Inc.6
Junos SRX Enforcer Feature Guide
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 Access Control Service certificate that the Junos
Enforcer must match during communication, use the following statement:
set unified-access-control infranet-controller <Access Control Service name> ca-profile<specify ca-profile configured at security pki ca-profile>
See Certificate Security Administration for details about configuring certificate trust
between the Junos Enforcer and the Access Control Service.
RelatedDocumentation
• Connecting with the Junos Enforcer on page 76
7Copyright © 2014, Juniper Networks, Inc.
Chapter 1: Deployments
Copyright © 2014, Juniper Networks, Inc.8
Junos SRX Enforcer Feature Guide
CHAPTER 2
Infranet Enforcer
• Infranet Enforcer Policies Overview on page 9
• Using the Infranet Enforcer as a Policy Enforcement Point on page 10
• Understanding Infranet Enforcer Source IP Security Policies on page 11
Infranet Enforcer Policies Overview
After you set up user roles, authentication servers, realmsand sign-in policies, youdeploy
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
Access Control Service.
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 youwant to allow or deny by choosing
roles for each resource access policy.
• Source IPpolicy—This is an infranet auth policy the onScreenOSEnforcer or a securitypolicy 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 Access Control Service and push the policy to the
Infranet Enforcer, or you can set up the policy using ScreenOSWebUI or the command
line.
• Auth tablemapping policy—Specifies which Infranet Enforcer device an endpoint
must use to access resourceswhen 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,
youdonotneed toconfigureauth tablemappingpolicies. Instead, youcanusedynamic
auth table provisioning.
NOTE: You can use a usernamewith spaces, a usernamewith quotationmarks, a usernamewithUTF-8characters, or ausernamewithabackslash(\). Each of these conventions is accepted by the firewall with a validcorresponding auth table entry.
9Copyright © 2014, Juniper Networks, Inc.
Figure 1 on page 10 demonstrates how policies on the Infranet Enforcer and the Access
Control Service interact when a user has an auth table entry on the Infranet Enforcer.
Figure 1: 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.
RelatedDocumentation
About Resource Access Policies on page 33•
• Understanding Infranet Enforcer Source IP Security Policies on page 11
• Configuring Auth Table Mapping Policies for Source IP Enforcement on page 59
Using the Infranet Enforcer as a Policy Enforcement Point
TheAccess Control Service is the Layer 2 or Layer 3 policy decision point that determines
whichusersandendpoints canaccessprotected resources. Youcanuse JuniperNetworks
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
theAccessControlServicewith theScreenOSEnforcer and the JunosEnforcer. For version
compatibility, see Unified Access Control Supported Platforms.
The Access Control Service authenticates users, ensures that endpoints meet security
policies, and serves resource access policy information to Juniper Networks security
devices.
After you configure the Access Control Service and the Infranet Enforcer to successfully
communicate, you set up trust and untrust zones to define network boundaries. You
Copyright © 2014, Juniper Networks, Inc.10
Junos SRX Enforcer Feature Guide
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 Access Control Service andthe Infranet Enforcer is 300 seconds.
NOTE: With Junos Pulse Access Control Service Release 4.2 and JunosOSRelease 12.2, the Juniper Networks EX Series Ethernet switch can be used asan Infranet Enforcer. You can add an EX Series Ethernet switch in an 802.1Xdeployment as an Infranet Enforcer, and then create resource accesspoliciesto control access as the policy enforcement point.
Understanding Infranet Enforcer Source IP Security Policies
This topic provides an overviewof Infranet Enforcer source IP security policies. It includes
the following information:
• Source IP Security Policy Overview on page 11
• ScreenOS Infranet Enforcer Configuration Summary on page 12
• Junos Infranet Enforcer Configuration Summary on page 13
Source IP Security Policy Overview
Source IP enforcement permits users to access resources that are protected by the
InfranetEnforcer. IPsecprovidesanencrypted tunnel forbidirectional traffic,while source
IPenforcementallowsunencrypted(clear text) trafficbetweenendpointsand 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 UAC policies. On a ScreenOS Enforcer, a
UAC policy is an infranet auth policy (a policy that includes an infranet-auth statement).
On a Junos Enforcer, a UAC policy is a uac-policy security policy (a security policy that
includes an application-services uac-policy statement, andmay ormay not also include
amatch source-identity statement for user-role firewall functionality).
UAC policies control which zones use Infranet Enforcer resource access policies to allow
ordeny traffic. Bydefault, traffic is denied through the InfranetEnforcer.WithUACpolicies,
you control the traffic that is permitted to pass.
When you first set up the Infranet Enforcer and the Access Control Service, you bind
zones to interfaces. UAC policies control the traffic flow between zones. For example,
you can configure a UAC policy on the ScreenOS Enforcer to enforce traffic from the
Untrust zone to the Trust zone. Then, you configure resource access policies and specify
11Copyright © 2014, Juniper Networks, Inc.
Chapter 2: Infranet Enforcer
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 IPenforcementdoesnotwork if there isaNATdevicebetweenthe endpoint and the Access Control Service.
In a case where the endpoint is behind a NAT device and the Access Control Service and
the Infranet Enforcer are both on the other side of the NAT device, only one configuration
is supported. Source IP enforcement works only with agentless access, and only if it is
“one-to-one” NAT, since the Access Control Service and the Infranet Enforcer both see
the external (translated) address, and there will be only one user session per IP address.
Source IPenforcementwithagentlessaccessmightappear towork, butdoesnotoperate
properly, if an 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 as 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 shows that their session was terminated, the same as if
an Access Control Service administrator deleted their session from the active user table.
If the endpoint is behind a NAT device, Source IP enforcement with Junos Pulse or OAC
agent 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 will be provisioned to the firewall, since the Access
Control Service detects that the endpoint is behind a NAT.
To provide access for Junos Pulse or OAC users behind a NAT device, youmust use the
IPsec policy feature. The IPsec enforcement section provides instructions on how to
accommodate users in this use case.
ScreenOS Infranet Enforcer Configuration Summary
You can configure Source IP security policies in either of the following ways:
• YoucanconfigurebasicSource IPpolicies (sourceanddestination zone)on theAccess
Control Service and then push the policies to the ScreenOS Enforcer to add additional
policy details. (Recommended)
• You can configure the policies directly on the ScreenOS Enforcer (using the ScreenOS
Web UI or CLI).
Copyright © 2014, Juniper Networks, Inc.12
Junos SRX Enforcer Feature Guide
NOTE: To use ScreenOS global policies as infranet auth policies, youmustconfigure them directly on the ScreenOS Enforcer. ScreenOS global policiesdonot includesourceanddestinationzones,andpoliciespushed fromAccessControl Servicemust include source and destination zones, so the infranetauth policy pushed by Access Control Service is not useful when configuringScreenOS global policies.
TIP: On ScreenOS, you create a policy using address book entries for thedestination and source addresses, as well as policy wildcards, such as Any.
The following example sets an infranet auth policy and adds it to the top of the list of
policies controlling traffic from the Untrust zone to the Trust zone. The policy applies to
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 theAccessControl
Service.
set policy top from untrust to trust any any any permit infranet-auth
The following example sets two address book entries and a policy for anyone in the
10.64.0.0/16 range to reach the 10.65.0.0/16 range, subject to resource access policies.
set address Trust “10.64 Range” 10.64.0.0 255.255.0.0set 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, youmust define the addresses for each of the zone’s address books. A zone’s
addressbookmust contain entries for theaddressablenetworksandendhostsbelonging
to the zone.
Each security policy that you create must contain at a minimummatch criteria and an
action. You can specify additional policy options as required.
You can create security polices on the Junos Enforcer from the JunosWeb interface, or
from the CLI.
The followingexample setsauac-policy securitypolicy controlling traffic fromtheUntrust
zone to theTrust zone. Thepolicy applies toall traffic of any type fromanyhost toanother
host. The policy allows traffic according to the Infranet Enforcer resource access policies
that you configure on the Access Control Service.
setsecuritypolicies from-zoneUntrust to-zoneTrustpolicyENFORCE_ALLmatchsource-addressany
13Copyright © 2014, Juniper Networks, Inc.
Chapter 2: Infranet Enforcer
set security policies from-zone Untrust to-zone Trust policy ENFORCE_ALLmatchdestination-address anyset security policies from-zone Untrust to-zone Trust policy ENFORCE_ALLmatch applicationanyset security policies from-zone Untrust to-zone Trust policy ENFORCE_ALL then permitapplication-services uac-policy
The following example sets two address book entries and a policy for anyone in the
10.64.0.0/16 range to reach the 10.65.0.0/16 range, subject to resource access policies.
set security zones security-zone Trust address-book address 10.64_Range 10.64.0.0/16set security zones security-zone Untrust address-book address 10.65_Range 10.65.0.0/16setsecuritypolicies from-zoneTrust to-zoneUntrustpolicyENFORCE_ALLmatchsource-address10.64_Rangeset security policies from-zone Trust to-zone Untrust policy ENFORCE_ALLmatchdestination-address 10.65_Rangeset security policies from-zone Trust to-zone Untrust policy ENFORCE_ALLmatch applicationanyset security policies from-zone Trust to-zone Untrust policy ENFORCE_ALL then permitapplication-services uac-policy
RelatedDocumentation
• Concepts & Examples ScreenOS Reference Guide: Part 2, “Fundamentals”
• Concepts & Examples ScreenOS Reference Guide: Part 9, “User Authentication” Chapter 3,
“Infranet Enforcer”
• Junos OS: Infranet Authentication Feature Guide for Security Devices
Copyright © 2014, Juniper Networks, Inc.14
Junos SRX Enforcer Feature Guide
CHAPTER 3
Captive Portal
• Understanding the Infranet Enforcer Captive Portal Feature on page 15
• Before Configuring Captive Portal on page 16
Understanding the Infranet Enforcer Captive Portal Feature
When you deploy the Access Control Service and Infranet Enforcer, users may not know
that theymust first sign into the Access Control Service for authentication and endpoint
security checkingbefore theycanaccessaprotected resourcebehind the InfranetEnforcer.
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 Access Control Service. This feature
is called captive portal.When the sign-in page for theAccessControl Service is displayed,
the user signs in and Host Checker for OAC or Pulse or agentless Host Checker examines
theendpoint for compliancewith security policies, and if theendpoint passes the security
check, access is granted to the protected resource.
Captive portal is supported on both the ScreenOS Enforcer and the Junos Enforcer.
Youcanconfigurecaptiveportal for endpoint clients thatuseeither source IPenforcement
or IPsec enforcement, or a combination of both methods.
“Captive Portal” on page 15 illustrates the sequence of events when a user attempts to
access protected resources with captive portal configured.
15Copyright © 2014, Juniper Networks, Inc.
Figure 2: 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.
RelatedDocumentation
Before Configuring Captive Portal on page 16•
• Creating a Redirect Policy on the Infranet Enforcer on page 79
• Overriding the Default Redirection Destination for Captive Portal on page 83
Before Configuring Captive Portal
DetailsTopic
Thecaptiveportal feature requiresScreenOSRelease5.4or later runningon the ScreenOS Enforcer.
ScreenOS version
To use captive portal with the Junos Enforcer, Release 10.2 is required.Junos version
You can configure the ScreenOS Enforcer to redirect HTTP traffic to anexternalWeb server instead of the Access Control Service. For example,you can redirect HTTP traffic to aWeb page that explains to users therequirement to sign into the Access Control Service before they canaccess the protected resource. You can also explain the security policyand include a link to the Access Control Service on thatWeb page tohelp users sign in.
External Web server
Thecaptiveportal feature redirectsHTTPtrafficonly. If theuserattemptsto access a protected resource using HTTPS or another protocol suchas SMTP, the Infranet Enforcer does not redirect the user’s traffic.Whenusing HTTPS or another application, the user must manually sign intothe Access Control Service first before attempting to access protectedresources.
HTTP vs. HTTPS
If there is anHTTPproxybetween theendpointand the InfranetEnforcer,the Infranet Enforcer might not redirect the HTTP traffic.
HTTP proxy
Copyright © 2014, Juniper Networks, Inc.16
Junos SRX Enforcer Feature Guide
DetailsTopic
In standard configurations, ScreenOS uses default HTTP ports as theredirect destination port for traffic. In addition to default HTTP ports,nonstandard HTTP port 3128 is defined for HTTP-EXT traffic toaccommodate the SQUID proxy.
The Junos Enforcer, supports only port 80.
Default port
17Copyright © 2014, Juniper Networks, Inc.
Chapter 3: Captive Portal
Copyright © 2014, Juniper Networks, Inc.18
Junos SRX Enforcer Feature Guide
CHAPTER 4
User-Role-Based Firewall Policies
• User-Role Firewall Policies Overview on page 19
• Terminology for Active Directory SPNEGO Authentication with User Role
Policies on page 20
• User Authentication Sequence for Active Directory on page 21
• Active Directory Integration Notes on page 22
• Supported Versions on page 24
User-Role Firewall Policies Overview
In a standard Junos Pulse Access Control Service (UAC) deployment, users authenticate
to theMAGSeries JunosPulseGatewaydevice (MAGSeries)oranAccessControlService
through a sign-in page, and typically download a client, or are provisionedwith agentless
access through a browser.
In the user-role firewall policy solution, you can use the SRX Series device and the MAG
Series device or the Access Control Service to authorize users at Layer 7 using a Kerberos
ticket.
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 resourceswithout passing through Junos Pulse Access Control
Service for reauthentication.
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
Seriesdevicematchuserswith resources. For example, apolicy could state that engineers
from a particular group, or role, have access to a specific set of servers.
RelatedDocumentation
UAC Solution Guide for SRX Series Services Gateways•
• Supported Versions on page 24
19Copyright © 2014, Juniper Networks, Inc.
Terminology for Active Directory SPNEGOAuthentication with User Role Policies
This sectiondetails terminology that is applicable for usingActiveDirectorywith theMAG
Series device to permit single sign-on for users.
NOTE: Only Internet Explorer, Firefox (Windows andMacOS), and GoogleChrome browsers are supported with SPNEGO.
DescriptionTerm
TheGSS-API is agenericAPI for performingclient-server authentication.Every security system has a unique API, and the effort involved withadding different security systems to applications is extremely difficultwith thevariationbetweensecurityAPIs.WithacommonAPI, enterprisescan write to the generic API, and work with any number of securitysystems.
TheGSS-API is includedwithmostKerberos5distributions. If aparticularapplication or protocol supports GSS-API, then Kerberos is supported.
Generic Security Service Application ProgramInterface (GSS-API)
AsecuritymechanismthatenablesGSS-APIpeers todeterminewhethertheir credentials supportacommonsetofoneormoreGSS-API securitymechanisms. If so, it invokes the normal security context establishmentfor a selected common security mechanism. This is most useful forapplications that depend on GSS-API implementations and sharemultiple mechanisms between the peers.
Youmust enable SPNEGO for supported browsers.
Simple and Protected GSS-API Negotiation(SPNEGO)
Akeytab isa file that containspairsofKerberosprincipalsandencryptedkeys (derived from the Kerberos password). You use this file to log in toa Kerberos systemwithout being prompted for a password.
Youupload the keytab filewhen you create theActiveDirectory instanceon the Junos Pulse Access Service device and enable SPNEGO.
Keytab
Part of a system intended to reduce the risk of exchanging keys. A KDCconsistsofaanauthenticationserverandaTicketGrantingServer (TGS).
Key Distribution Center (KDC)
An SPN is the name by which a client uniquely identifies an instance ofa service, in this case a Junos Pulse Access Control Service. If you installmultiple instances of a service on computers throughout a forest, eachinstancemust have its own SPN. A given service instance can havemultiple SPNs if there are multiple names that clients might use forauthentication.AnSPN includes thehostnameof the JunosPulseAccessControl device.
Service Principal Name (SPN)
Copyright © 2014, Juniper Networks, Inc.20
Junos SRX Enforcer Feature Guide
NOTE:
• A running domain controller is required for this solution.
• Youmust create amachine account or user account on
• Youmust create aKTPass (keytab) token and import it into theMagSeriesdevice.
RelatedDocumentation
Configuration Summary on page 63•
User Authentication Sequence for Active Directory
Figure 3: Example Configuration
The sequence that permits users to access protected resources is as follows:
• The Junos Pulse Access Control device connects to the SRX Series device and pushes
all of the configured roles to the firewall.
• Theuserendpointconnects to thedomainbyauthenticationwith theDomainController.
• 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 Junos Pulse Access Control device, 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 Junos Pulse Access Control device
for authentication.
• The Junos Pulse Access Control device 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) thatmatches the Junos Pulse Access Control device hostname.
21Copyright © 2014, Juniper Networks, Inc.
Chapter 4: User-Role-Based Firewall Policies
• Theendpoint resubmitsanHTTPGET request to the JunosPulseAccessControl device
with a SPNEGO authentication token.
• After successfulSPNEGOauthentication, a session is createdon the JunosPulseAccess
Control device, and an auth table entry is pushed to the SRX Series device.
NOTE: The Junos Pulse Access Control device permits single sign on byimplementing the Kerberos protocol and SPNEGO.
• The Junos Pulse Access Control device 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 theprotected resources.
This service enhances integration with Active Directory. When the Junos Pulse Access
Control Service challenges the endpointwith a 401 error for SPNEGOauthentication, the
endpoint requests a ticket from Active Directory.
The SPN used for the ticket is the Junos Pulse Access Control Service hostname. The
SPN used by the browser is in the form http/hostname. For this transaction to be
successful, the SPNmust be registered with Active Directory as an HTTP service using
the hostname (FQDN).
NOTE: TheMAG Series device hostnamemust be used for the SPN.
The SPN created on the Junos Pulse Access Control Service is composed as
service/<FQDN>@<REALM>.
A sample SPN: HTTP/[email protected].
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.
Active Directory Integration Notes
On Active Directory, there are two steps that must be performed:
• Create a dedicated user for the SPN.
NOTE: Youmust set a password for the user. Usermust change password
on next logon should not be enabled, and Password never expires should be
enabled.
Copyright © 2014, Juniper Networks, Inc.22
Junos SRX Enforcer Feature Guide
• Add the SPN to this user using 'ktpass.exe' (this will generate the keytab).
NOTE:• The SPNmust be added in this format: HTTP/hostname@REALM. TheSPN is case sensitive.Note theorder of upper case, lower caseanduppercase.
• For Active Directory 2008, the commands 'ktpass' and 'setspn' arealready installed. For Active Directory 2003, an add-on pack is required.
Before adding the SPN, it's a good idea tomake sure it doesn't alreadyexist. This will help avoid ticket decryption issues on Junos Pulse AccessControl Service.
On the endpoint, the MAG Series devicemust be added as a trusted host(with Internet Explorer or Firefox). This can also be done with an ActiveDirectory group policy. Without this, the browser will not participate inSPNEGO.
On the MAG Series device, youmust upload the keytab file and verify thatthediode turnsgreen(indicatingasuccessful join).SPNEGOdoesnotworkunless 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 ticketsmustbepurged fromtheendpoint if SPNsareupdatedorpasswords
are changed (assuming the endpoint still has a cached copy of the ticket from a prior
SPNEGOrequest to theMAGSeriesdevice.During testing, you shouldpurge ticketsbefore
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 fromMicrosoft's site.
23Copyright © 2014, Juniper Networks, Inc.
Chapter 4: User-Role-Based Firewall Policies
When troubleshooting, Juniper Network recommends that you restart the browser
between auth requests to avoid cache issues.
If Internet Explorer pops-up aWindows dialog box during authentication, this signifies
that the IC isn't trusted for SPNEGO. You should add theMAGSeries 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 LogMessages on theMAG Series Device
Table 4: Understanding LogMessages Related to Active Directory and SPNEGO
Possible Causes:The SPN does not exist on ActiveDirectory.Note thesmall numberofbytes sent (56). Thisvalue is normally closer to 2K bytes.
LogMessage: AUT30832 2012-01-30 08:41:15 - asgic15 -[10.64.105.112]System(Users)[] -Kerberos ticket decode failure (Anunsupportedmechanismwas requested)
AUT30845 2012-01-30 08:41:15 - asgic15 - [10.64.105.112]System(Users)[] - SPNEGOSSO: received 56bytes in HTTPheader'Authorization' from 10.64.105.112
Possible Causes:This log indicates that the Junos PulseAccess Control Service requested from the browser wasnot found in the keytab.
LogMessage:AUT30831 2012-01-30 08:44:45 - asgic15 -[10.64.105.112] System(Users)[] - Cannot load SPN'HTTP/[email protected]' fromkeytab file (Noprincipalin keytabmatches desired name)
Possible Causes:This log may indicate that the SPNwasupdated on Active Directory, but Junos Pulse AccessControl Service is still using an older keytab.
LogMessage:AUT30832 2012-01-30 09:52:15 - asgic15 -[10.64.105.112] System(Users)[] - Kerberos ticket decode failure(Unknown code FF 163)
Possible Causes:The Active Directory user's passwordassociated with the SPN has changed. Junos PulseAccessControlService cannot join thedomain; thediodemust be green (if you are usingWindows 2008).
LogMessage:AUT30832 2012-01-30 08:34:58 - asgic15 -[10.64.105.112] System(Users)[] - Kerberos ticket decode failure(Unknown code FF 161)
RelatedDocumentation
•
Supported Versions
The Junos Enforcer is an SRX Series device. The Junos Pulse Access Control Service runs
on the MAG Series device or the Access Control Service.
To use the SRX Series device with the Junos Pulse Access Control device for Layer 7
protection, the SRX Series device must have JunosOS Release 12.1 or greater, and the
Junos Pulse Access Control Service must have Release 4.2 or greater.
RelatedDocumentation
•
Copyright © 2014, Juniper Networks, Inc.24
Junos SRX Enforcer Feature Guide
CHAPTER 5
IPsec
• IPsec and the Junos Enforcer on page 25
• IPsec Policies on the Junos Enforcer on page 26
• Using IPsec with the Junos Enforcer on page 27
• IPsec Enforcement on the Junos Enforcer on page 27
• Before Configuring IPsec on the Junos Enforcer on page 27
• IPsec Routing Policies for the Junos Enforcer on page 28
• Before Configuring IPsec Routing Policies on page 28
• Using IP Address Pool Policies for IPsec in a NAT Environment on page 29
• Understanding IP Address Pool Policies on page 31
IPsec and the Junos Enforcer
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;
the tunnel extends directly to the client itself.
Odyssey Access Client and Junos 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 IC Series device by the respective
device.
When a user with Odyssey Access Client or Junos Pulse signs in to the IC Series device,
these configuration details are passed on to the client to establish an IPsec tunnel with
the Infranet Enforcer.
25Copyright © 2014, Juniper Networks, Inc.
IPsec is supported on the Junos Enforcer beginning in version 10.0 . You configure IPsec
routingpolicies and IPaddresspool policies on the ICSeriesdevice. Youconfigure security
policies on the Junos Enforcer.
IPsec policies allow you to specify the parameters for SAs between endpoints and the
Infranet Enforcer.
To set up IPsec for endpoints with Odyssey Access Client or Junos Pulse, you configure
policies on the IC Series device, and on the security device.
The IC Series device pushes the required IPsec configuration parameters to the client
when the client first attempts to connect to a protected resource behind and IC Series
device for which IPsec has been configured.
RelatedDocumentation
IPsec Policies on the Junos Enforcer on page 26•
• Using IPsec with the Junos Enforcer on page 27
• IPsec Enforcement on the Junos Enforcer on page 27
• Before Configuring IPsec on the Junos Enforcer on page 27
• IPsec Routing Policies for the Junos Enforcer on page 28
IPsec Policies on the Junos Enforcer
This section details the policies that you configure in association with using IPsec on the
Infranet Enforcer.
• IPsecRoutingPolicy—This typeofpolicy specifieswhich InfranetEnforcer anendpointmust use toaccess a resource. This policy also specifieswhether 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 IC
Series device.
• IP Address Pools Policy—This type of policy specifies a pool of virtual IP addresses
that you want the IC Series device to automatically assign to endpoints in NAT
environments that use IPsec tunnels to the Infranet Enforcer. You configure IP address
pools policies on the IC Series device.
• 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 JunosEnforcer. You cannot configure security policies
on the IC Series device.
RelatedDocumentation
Using IPsec with the Junos Enforcer on page 27•
• IPsec Enforcement on the Junos Enforcer on page 27
• IPsec Routing Policies for the Junos Enforcer on page 28
• Using IP Address Pool Policies for IPsec in a NAT Environment on page 29
Copyright © 2014, Juniper Networks, Inc.26
Junos SRX Enforcer Feature Guide
Using IPsec with the Junos Enforcer
On supported endpoints that use Odyssey Access Client or Junos Pulse, you can use
IPsec enforcement to encrypt the traffic between an endpoint and the Junos Enforcer,
adding an additional layer of protection for network assets.
IPsec is not supportedonagentlessor Javaagent endpoints, or onendpoints that connect
with non-UAC software. Instead, youmust use source IP enforcement for these clients.
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 IC Series device. For IPsec with the Junos Enforcer, you create security
policies on the device.
For IPsec with the Junos Enforcer you use the CLI to create security policies.
With the Junos Enforcer, the IC Series device uses the destination zone to match the
IPsec Routing policies configured on the IC Series device.
RelatedDocumentation
IPsec and the Junos Enforcer on page 25•
• IPsec Enforcement on the Junos Enforcer on page 27
IPsec Enforcement on the Junos Enforcer
The ICSeriesdevice is thepolicydecisionpoint thatdetermineswhichusersandendpoints
can access protected resources.
You can use Juniper Networks firewalls to serve as the enforcement point to provide the
ultimate protection to ensure that your network assets are secured.
You can use a ScreenOS Enforcer or a Junos Enforcer with the UAC solution. A Junos
Enforcer is an SRX Series Services Gateway configured as a Layer 3 enforcement point.
See the 4.2R1 Supported Platforms for version compatibility.
RelatedDocumentation
Before Configuring IPsec on the Junos Enforcer on page 27•
• Using IPsec with the Junos Enforcer on page 27
Before Configuring IPsec on the Junos Enforcer
DetailsTopic
The InfranetEnforcerand the ICSeriesdevicemustbeconnectedbeforeyou use the IC Series device to set up IPsec enforcement on the InfranetEnforcer.
Connection
27Copyright © 2014, Juniper Networks, Inc.
Chapter 5: IPsec
If you configure IPsec enforcement for an Infranet Enforcer that hasmultiple interfaces in the source zone, the IC Series device configures aunique IKE gateway, VPN, and tunnel policy for each interface. Todistinguish between the tunnel policies, the IC Series device displaysthe name of the vpn for each tunnel policy in the VPN column on theUAC > Infranet Enforcer > Enforcer Policies page after you click SaveChanges.
Multiple interfaces
To include the CLI commands that the IC Series device sends to theInfranet Enforcer in the IC Series device event logs, select the EnforcerCommand Trace option on the System > Log/Monitoring > Events >Settings page.
CLI commands
On the Junos Enforcer, only one IPsec vpn tunnel per “from-zone” to“to-zone” is supported.
Junos Enforcer zone limitation
To troubleshoot your IPsec configuration, you can view the Event logson the IC Series device. You can also view IPsec information on theendpointbychoosingTools>Diagnostics> IPsecDiagnostics inOdysseyAccess Client.
Troubleshooting
RelatedDocumentation
IPsec and the Junos Enforcer on page 25•
• IPsec Policies on the Junos Enforcer on page 26
• IPsec Enforcement on the Junos Enforcer on page 27
IPsec Routing Policies for the Junos Enforcer
An IPsec routing policy specifies which Infranet Enforcer device endpoints must use to
access resourceswhenusing IPsec. The IPsec routingpolicy also specifies that endpoints
must use an IPsec tunnel to the Infranet Enforcer to access resources.
For example, youmight create an IPsec routing policy that uses IPsec for 0.0.0.0/0 (the
entire network). In the same policy, you could specify the resources that are exceptions
anddonotuse IPsec, suchas 172.24.80.30(the ICSeriesdevice), 172.24.80.31 (the Infranet
Enforcer), and 172.24.144/21 (a wireless network).
RelatedDocumentation
Before Configuring IPsec Routing Policies on page 28•
• Configuring an IPsec Routing Policy for the Junos Enforcer on page 53
Before Configuring IPsec Routing Policies
DetailsTopic
Do not use IPsec for the IC Series device, the Infranet Enforcer, and networks where your endpoints arelocated. 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 forthe IP addresses assigned to IC Series device, Infranet Enforcer, and the endpoints.
IP addressexceptions
Copyright © 2014, Juniper Networks, Inc.28
Junos SRX Enforcer Feature Guide
For maximum interoperability with other third-party IPsec clients, select both Always use UDPencapsulation and Always use a virtual adapter.When both options are selected, NAT is simulated evenif a NAT device is not present. Juniper Networks recommends that you select both options or neitheroption. For example, if an endpoint contains two network interfaces, such as a wired and a wirelessinterface, andaNATdevice is notpresentbetween theendpoint and the InfranetEnforcer. If theendpointdoesn't access a protected resource by using the interface that is connected to the network where theInfranet Enforcer is installed, then the user will not be able to access the protected resource througheither interface without a virtual adapter. Because the IC Series device does not automatically install avirtual adapter unless a NAT device is detected, enable the Always use a virtual adapter option tosimulate NAT and force the use of a virtual adapter for this use case.
UDP encapsulationand virtual adapters
RelatedDocumentation
IPsec Routing Policies for the Junos Enforcer on page 28•
• Configuring an IPsec Routing Policy for the Junos Enforcer on page 53
Using IP Address Pool Policies for IPsec in a NAT Environment
The Access Control Service 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 Access Control Service can
automatically assign to endpoints by creating IP address pool policies. An IP address
pool is a contiguous range of IP addresseswhich 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.
• Youselected theAlwaysuseavirtual adapteroption inan IPsec routingpolicy toenable
interoperability with other third-party IPsec clients running simultaneously on the
endpoint, such as Juniper Networks 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 Access Control Service 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 Access Control Service and Infranet Enforcer.
• If there is a NAT device between the endpoint and the Access Control Service, but not
between the endpoint and the Infranet Enforcer, source IP enforcement does notwork.
This is also true if there is aNATdevicebetween theendpoint and the Infranet Enforcer,
but not between the endpoint and the Access Control Service.
If NAT is not detected, the client uses the endpoint’s physical IP address when creating
the IPsec tunnel to the Infranet Enforcer. The Access Control Service does not allocate
an IP address from the pool.
29Copyright © 2014, Juniper Networks, Inc.
Chapter 5: IPsec
Figure 4 on page 30 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 Access Control Service to assign a unique, routable, virtual IP address
to each endpoint.
Figure 4: Using an IP Address Pool in a NAT Environment
The following sequence of events occur when the Access Control Service and a Juniper
client (OAC or Pulse) use an IPsec tunnel through a NAT device:
• When the client connects to the Access Control Service and authenticates the user,
the client returns the endpoint’s source IP address that is used to access the Infranet
Enforcer to the Access Control Service. The Access Control Service 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 Access Control Service.
• The Access Control Service 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 Access Control Service determines that there is a NAT device between the
endpointand the InfranetEnforcer. TheAccessControlServiceautomaticallyprovisions
an IP address from an IP address pool policy that you configured (for example,
10.11.0.10-100). The Access Control Service assigns the IP address to the endpoint
based on the IP address pool policy that applies to the user’s role. The Access Control
Service 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.
Copyright © 2014, Juniper Networks, Inc.30
Junos SRX Enforcer Feature Guide
• 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 setsupdynamic routes for each IPaddress. Theuser cannowuse theendpoint
to access protected resources.
The Access Control Service allocates one IP address for the duration of each client
session,which lasts as long as the client is connected to theAccessControl Service. After
a session ends, theAccessControl Service can reuse the allocated address for a different
endpoint.
When theAccessControlServicemustprovidean inner IPaddress for anew IPsec tunnel,
it attempts to reuseanexisting inner IPaddressassigned to theendpointbeforeallocating
anewone.TheAccessControlServicechecksall of the inner IPsallocated from IPaddress
pools for the endpoint. For each IP address, the Access Control Service determines
whether the policy fromwhich 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.
RelatedDocumentation
Understanding IP Address Pool Policies on page 31•
• Configuring an IP Address Pool Policy on page 54
Understanding IP Address Pool Policies
DetailsTopic
If you are usingmultiple Infranet Enforcers across a LAN,make sure thatthe IP address pool contains addresses that are valid for each InfranetEnforcer.
Multiple Infranet Enforcers
If you are using multiple unclustered Access Control Service serversacross a LAN, make sure that the IP address pool contains addressesthat are unique for each host. The endpoint is assigned an virtual IPaddress for each unclustered server to which OAC connects.
Multiple unclustered Access Control Service servers
Make sure that the IP pool addresses do not conflict with addresses ofhosts that the endpoint might access.
IP address conflicts
If you change or delete the IP addresses in an IP address pool, youmustdelete all user sessions in order to stop using those addresses. To deleteall user sessions, select System > Status > Active Users and click DeleteAll.
Deleting IP addresses in an IP pool
Be sure to specify a sufficient number of addresses in the IP addresspool for all of the endpoints in your deployment. When all of theaddresses in the pool are assigned to endpoints, additional endpointscannot obtain a virtual IP address and are blocked from accessingprotected resources. The Access Control Service logs amessage in theEvent log when an IP address cannot be assigned to an endpoint.
Number of available IP addresses
31Copyright © 2014, Juniper Networks, Inc.
Chapter 5: IPsec
RelatedDocumentation
• Using IP Address Pool Policies for IPsec in a NAT Environment on page 29
• Configuring an IP Address Pool Policy on page 54
Copyright © 2014, Juniper Networks, Inc.32
Junos SRX Enforcer Feature Guide
CHAPTER 6
Resource Access Policies
• About Resource Access Policies on page 33
• Specifying Resources for User Access Control on page 34
About Resource Access Policies
A resource access policy specifies which users are allowed or denied access to a set of
protected resources.
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 froma rolewith a security policy enabled is comparedwith
a policy and amatching entry is detected, the Infranet Enforcer applies the appropriate
policy action.
For example, a resource access policy can specify that a usermust 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.
TheAccessControl Service pushes thepolicies to the Infranet Enforcerwhen the Infranet
Enforcer first connects to the Access Control Service and any time youmake 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 areaccessing resources through resourceaccesspolicies are temporarily interrupted.
With ScreenOS Release 6.2 or later, the Access Control Service 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.
33Copyright © 2014, Juniper Networks, Inc.
If you are using ScreenOSRelease 6.2 or later or on the Junos Enforcer, you can configure
customizedmessages 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
Youcanuse thesevariablesalongwith yourowntext tocompose thedeny/rejectmessage
that you send toOACorPulse users.When themessage is sent to theuser, 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 AccessPolicy
With Junos Pulse Access Control Service 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 Junos Pulse Access Control Service and EX Series Switch Configuration Task
Summary
In addition to existing resource options, you can add MAC addresses as a resource.
RelatedDocumentation
Configuring Resource Access Policies on page 57•
• Infranet Enforcer Policies Overview on page 9
Specifying Resources for User Access Control
When you create Host Enforcer policies (for OAC only) and Infranet Enforcer resource
access policies, youmust specify the resources to which the policy applies.
Policy evaluation 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 system compares the request with the
resources specified in thecorrespondingpolicies, startingwith the first policy in thepolicy
list.When the systemmatches 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 casesmay be to deny
access by taking no action.
Copyright © 2014, Juniper Networks, Inc.34
Junos SRX Enforcer Feature Guide
When specifying server resources for 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 5: DNSHostname Special Characters
Matches all characters.*
Matches any character except dot (.).%
Matches exactly one character.?
• Ports (optional)—Possible values:
Table 6: Port Possible Values
Matches all ports; no other special characters are allowed.*
A comma-delimited list of single ports. Valid port numbers are 1- 65535.port[,port]*
A range of ports, from port1 through port2, inclusive.[port1]-[port2]
You canmix 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
35Copyright © 2014, Juniper Networks, Inc.
Chapter 6: Resource Access Policies
tcp://10.11.0.10:80
udp://10.11.0.10:*
RelatedDocumentation
• About Resource Access Policies on page 33
• Configuring Resource Access Policies on page 57
• Using Host Enforcer Policies
Copyright © 2014, Juniper Networks, Inc.36
Junos SRX Enforcer Feature Guide
CHAPTER 7
User Role Policies
• User Role Policies on the Junos Enforcer on page 37
User Role Policies on the Junos Enforcer
With Junos OS Release 12.1 or greater, and Junos Pulse Access Control Service Release
4.2 or greater, you can use Junos security policies to control user access to protected
resources.
You configure user roles on the Access Control Service 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 Access Control Service device. See the Junos
OS Initial Configuration Guide for Security Devices.
User rolepolicies canbeused inplaceof resourceaccesspolicies, or inaddition to resource
access policies.
RelatedDocumentation
• About Resource Access Policies on page 33
37Copyright © 2014, Juniper Networks, Inc.
Copyright © 2014, Juniper Networks, Inc.38
Junos SRX Enforcer Feature Guide
CHAPTER 8
Auth Tables
• Understanding Infranet Enforcer Auth Tables on page 39
• Understanding Dynamic Auth Table Allocation on page 39
Understanding Infranet Enforcer Auth Tables
The Infranet Enforcer holds auth tables for valid sessions on the Access Control Service.
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.
Whenauserwithausernamecontaining spacesor quotesauthenticateswith theAccess
Control Service, 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
usersareauthenticated, or youcanconfiguredynamicauth tableallocation.Withdynamic
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.
RelatedDocumentation
Understanding Dynamic Auth Table Allocation on page 39•
• Configuring Dynamic Auth Table Allocation on page 59
• Configuring Auth Table Mapping Policies for Source IP Enforcement on page 59
• Configuring Auth Table Mapping Policies on page 61
Understanding Dynamic Auth Table Allocation
You can use the dynamic auth table allocation feature to push auth table entries to the
Infranet Enforcer only when a user attempts to access a protected resource. This ismore
efficient than the Auth Table Mapping Policies option, which requires administrators to
provisionauth tableentries for authenticateduserswhether theyareaccessing resources
39Copyright © 2014, Juniper Networks, Inc.
or not. 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.
When dynamic auth table allocation is used and a user attempts to access a protected
resource, the Infranet Enforcer does not yet have an auth table entry for the user, so it
sends a drop notification to theAccess Control Service to prompt it to send an auth table
entry. Unlike captive portal redirect, which only occurs when the user sends HTTP traffic,
drop notifications are triggered by any type of traffic for which the destination is a
protected resource.
After the user disconnects, the Infranet Enforcer automatically expires the auth table
entry.
NOTE: On the Junos Enforcer, whenever traffic matches a security policythat includes an application-services uac-policy statement, then the firewall
sends a drop notification to the Access Control Service if there is no authtable entry associatedwith that traffic. This applies in the captive portal usecase, and for all policies that include the application-services uac-policy
statement.
However, this behavior changes if user role firewall is configured. When amatch source-identity statement is included in any policy within a zone pair
(sourcezone+destinationzone), userand role informationmustbe retrievedbefore policy lookup can proceed. (If all policies in the zone pair are set tomatch source-identity any, or have nomatch source-identity state, user and
role information is not required and the five standardmatch criteria are usedfor policy lookup.) Therefore, for any zone pair in which a security policy isconfigured thatcontainsamatchsource-identitystatement, the firewall sends
a drop notification for all traffic matching that source and destination zone,whether or not the trafficmatches the specific security policy containing thematch source-identity statement. This can result in an unexpected number
of drop notifications if a single zone contains amix of protected andunprotected resources.
In most deployments, Juniper Networks recommends that you use dynamic auth table
allocation. The benefits of dynamic auth table allocation are based onmany factors
within thenetworkdeployment: thenumberof InfranetEnforcers, theanticipatednumber
of sessions, and the persistence of user sessions.
The following requirements and limitations apply:
• Dynamic auth table allocation is supported for all deployments with Junos Enforcer
and with ScreenOS Enforcers running ScreenOS 6.1 or later.
• Dynamic auth table allocation does not work with HTTP traffic if the captive portal
feature is configured to redirect user traffic to an external web server other than the
Access Control Service. The Access Control Service must be aware of a user
login/session before it can provision an auth table entry.
Copyright © 2014, Juniper Networks, Inc.40
Junos SRX Enforcer Feature Guide
• If you configure dynamic auth table allocation on the Access Control Service, and the
DNSserver for thenetwork isbehind the InfranetEnforcer, endpointsmightoccasionally
experience DNS time-out issues before resources are provisioned.
• Dynamic auth table allocation is required to use IF-MAP Federation.
One scenario in which static auth tables are more practical is a deployment that forces
every endpoint to go through a single Infranet Enforcer for all access. In this case, static
auth tables can reduceoverall traffic betweenAccessControlService servers 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 nomore than 100 connected
Infranet Enforcers. For deployment scenarios with more than 100 Infranet Enforcers, we
recommend a deployment strategy using dynamic auth table allocation.
Testinghasshownthatwith5,000active sessions, performance is impactedsignificantly
when dynamic auth table allocation is not configured and 100 connected firewalls are
deployed.
Performancemetrics vary for each UAC release. For current performance information,
refer to Juniper Networks or your strategic partner for.
RelatedDocumentation
• Configuring Dynamic Auth Table Allocation on page 59
41Copyright © 2014, Juniper Networks, Inc.
Chapter 8: Auth Tables
Copyright © 2014, Juniper Networks, Inc.42
Junos SRX Enforcer Feature Guide
PART 2
Configuration
• Junos Enforcer on page 45
• IPsec on page 49
• Resource Access Policies on page 57
• Auth Tables and Mapping Policies on page 59
• User-Role-Based Firewall on page 63
43Copyright © 2014, Juniper Networks, Inc.
Copyright © 2014, Juniper Networks, Inc.44
Junos SRX Enforcer Feature Guide
CHAPTER 9
Junos Enforcer
• Configuring the Junos Enforcer to Communicate with the Access Control
Service on page 45
• Setting Up the Junos Enforcer toWork with the Access Control Service on page 46
Configuring the Junos Enforcer to Communicate with the Access Control Service
The Junos Enforcer works with the Access Control Service for Layer 3 connectivity. Users
can connect with source IP or IPsec (JunosOS Release 10.0 or later).
For the initial setup, youmust specify the Access Control Service name, IP address, port
number over which the Junos Enforcer and Access Control Service will connect, the
interface, the password (the same password as entered on the Access Control Service),
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 Access Control Service and endpoints can reside on different physical
interfaces of the Junos Enforcer (using both interfaces on the Access Control Service)
or on the same interface.
Access Control Service 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 Access Control Service, the Access Control Service populates the
Junos Enforcer with themapping 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 youareusing theExporteditionof Junos, youmustset theencryptionstrength on the Access Control Service to use 40-bit ciphers on theConfiguration>Securitypage of the admin console. Domestic editions do not
have this requirement.
45Copyright © 2014, Juniper Networks, Inc.
RelatedDocumentation
Setting Up the Junos Enforcer toWork with Junos Pulse Access Control Service on
page 75
•
• Connecting with the Junos Enforcer on page 76
Setting Up the Junos Enforcer toWork with the Access Control Service
This example details a configuration with the IC Series device on the untrusted interface
side (the same side as endpoints). Formore information, see the Junos Software Security
Configuration Guide and Junos Software 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 IC Series device.
2. Ensure that the DHCP server is disabled or enabled as required for the deployment.
3. Create an instance of the IC Series device on the Junos security device, and provide
thenetwork information required for connectingusing theCLI. This information includes
the IC Series device host name, the IP address, and the interface to which the device
will connect. The default port for communication with the IC Series device is 11123,
you cannot change the port. Youmust also specify a password, that matches the
password configured on the IC Series device.
For complete CLI instructions and syntax, see the Junos Software CLI Reference.
a. Specify the IC Series device’s hostname:
user@host# set services unified-access-control infranet-controller hostname
b. Specify the IC Series device’s IP address:
user@host# set services unified-access-control infranet-controller hostname addressip-address
c. Specify the Junos interface to which the IC Series device should connect:
user@host# set services unified-access-control infranet-controller hostname interfaceinterface-name
d. Specify the password that the SRX Series or J Series device should use to initiate
secure communications with the IC Series device:
user@host# set services unified-access-control infranet-controller hostname passwordpassword
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 IC Series device if no communication is received. The
interval specifies how often the IC Series device sends a heartbeat to the Junos
Enforcer.
5. (Optional) Verify that the certificate of theCA that signed the ICSeries device’s server
certificate is loaded in the Junos Enforcer and that the path to the certificate is
specified.
Copyright © 2014, Juniper Networks, Inc.46
Junos SRX Enforcer Feature Guide
NOTE: Althoughcertificateverification isoptional, thereare threedifferentcertificateoptionson the JunosEnforcer thatwill producedifferent results.
If certificate-verification is set to required, it is required that the deviceverify any IC Series device server certificate. If any IC Series device'sca-profile is not configured, the commit check fails.
If certificate-verification is set to warning (the default), and the IC Seriesdevice ca-profile is not configured, the commit check displays a warningabout 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 ICSeries device certificate.
6. Verify routing from the IC Series device to the untrusted interface.
7. Ensure that both the Junos Enforcer and the IC Series device 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 IC Series device instance, the Junos Enforcer can initiate
the connection with the IC Series device. The Junos Enforcer optionally validates the IC
Series device server certificate if so configured. The device sends the serial number to
authenticate with the IC Series device.
For the JunosEnforcer toestablishcommunication, youmust configure the JunosEnforcer
on the IC Series device.
RelatedDocumentation
• Connecting with the Junos Enforcer on page 76
47Copyright © 2014, Juniper Networks, Inc.
Chapter 9: Junos Enforcer
Copyright © 2014, Juniper Networks, Inc.48
Junos SRX Enforcer Feature Guide
CHAPTER 10
IPsec
• Configuring Junos Enforcer IPsec Routing Policies on page 49
• Configuring an IPsec Routing Policy for the Junos Enforcer on page 53
• Configuring an IP Address Pool Policy on page 54
Configuring Junos Enforcer IPsec Routing Policies
This topic describes how to configure Junos Enforcer IPsec routing policies. It includes
the following information:
• Configuration Summary on page 49
• Configuration Example on page 50
Configuration Summary
You use the JunosOSCLI to configure IPsec routing policies on the Junos Enforcer. Unlike
the ScreenOS Enforcer, you cannot create policies on the Access Control Service 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 IKEgateways.
• Dynamic IPsec is not supported on the Junos Enforcer.
To configure IPsec on the Junos Enforcer, you must perform three primary tasks:
• Configure the Access Control Service as a RADIUS server for the Junos Enforcer client
to enable XAUTH. Youmust use the internal interface on the Access Control Service,
the external interface does not support XAUTH.
• Configure IKE and IPsec parameters to specify security restrictions for SAs.
49Copyright © 2014, Juniper Networks, Inc.
• Configure security policies to route traffic between the security gateway and the
interface for endpoints.
TheAccessControl Servicepolls the JunosEnforcer to retrieve the following configuration
information:
• The IKE gateway interface
• The destination zone
• Identity
• The pre-shared seed
• The RADIUS shared secret
The Access Control Service pushes these details to the client to allow establishment of
a dial-up VPN tunnel.
Configuration Example
The followingexampledescribesa sampleconfiguration for settingup IPsecon the Junos
Enforcer.
To use IPsec with the ScreenOS Enforcer, you can configure basic IPsec security policies
on the Access Control Service 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
routingpolicies andoptional IPaddresspool policies havebeenconfiguredon theAccess
Control Service.
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 Access Control Service as a RADIUS server for the Junos Enforcer client.
In this example, you create an instance of the Access Control Service 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 Access Control Service to accept RADIUS
packets from the device. Enter the following commands:
user@host# set access profile dev1086 authentication-order radiususer@host# setaccessprofiledev1086radius-server 192.168.100.5secretsome-shared-secret
If you are configuring Access Control Service nodes in an active/active cluster, you
must configure all IP addresses for individual cluster nodes. The shared secret must
be the same, as in the following example:
user@host# set access profile dev1086 authentication-order radius
Copyright © 2014, Juniper Networks, Inc.50
Junos SRX Enforcer Feature Guide
user@host# setaccessprofiledev1086radius-server 192.168.100.5secretsome-shared-secretuser@host# setaccessprofiledev1086radius-server 192.168.100.6secretsome-shared-secret
If youare configuringandactive/passive cluster, configure theAccessControl Service’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 aggressivemode and Encapsulation Security Payload (ESP).
• In aggressivemode, phase 1 security proposals are negotiatedwith twoexchanges and a total of threemessages:
• Firstmessage—The initiatorproposes theSA, initiatesaDiffie-Hellmanexchange, and sends a pseudorandom number and the IKE identity.
• Secondmessage—The recipient accepts the SA; authenticates theinitiator; and sends a pseudorandom number, the IKE identity, and, ifusing certificates, the recipient's certificate.
• Thirdmessage—The initiator authenticates the recipient, confirmstheexchange, and, if usingcertificates, sends the initiator's certificate.
Because the participants' identities are exchanged in the clear (in thefirst twomessages), Aggressivemode does not provide identityprotection.
• ESP protects the inner IP packet, while the outer header remainsunprotected.
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.
Setupaphase 1 IKEproposalnamedprop,usingDiffie-HellmanGroup2,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
Theclient supportsdes-cbc,3des-dbc,aes-128-cbc,aes-192-cbc,andaes-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.
51Copyright © 2014, Juniper Networks, Inc.
Chapter 10: IPsec
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, IKEpolicypol1 configuredabove, andXAUTH
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 (maximum5,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 Access Control Service and the client support only group-ike-id.
Configurean IPsecphase2proposal namedprop1withESPprotocol,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 namepol1with 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 theclient.
e. user@host# set security ike gateway gateway1 xauth access-profile name
3. Create the security policy.
Copyright © 2014, Juniper Networks, Inc.52
Junos SRX Enforcer Feature Guide
• 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 matchsource-address any
NOTE: Always specify anywith the following command.
user@host# set security policies from-zone untrust to-zone trust policy pol1 matchdestination-address anyuser@host# set security policies from-zone untrust to-zone trust policy pol1 matchapplication anyuser@host# set security policies from-zone untrust to-zone trust policy pol1 then permittunnel ipsec-vpn vpn1user@host# set security policies from-zone untrust to-zone trust policy pol1 then permitapplication-services uac-policy
RelatedDocumentation
Understanding Access Control Service Support for IPsec Routing Policies•
• Understanding IPsec Routing Policy Configuration Options
Configuring an IPsec Routing Policy for the Junos Enforcer
To configure an IPsec routing policy:
1. In the IC Series device admin console, select UAC > Infranet Enforcer > IPsec Routing.
2. Click NewPolicy.
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. 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. Youmust specify an IP
address.
5. 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.
6. 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
7. Select these options to configure IPsec interoperability and tunnel persistence:
53Copyright © 2014, Juniper Networks, Inc.
Chapter 10: IPsec
• Always use UDP encapsulation—This option allows the client and the InfranetEnforcer 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 ICSeries device uses port
4500 for UDP encapsulation in compliance with RFC 3948.
• Always use a virtual adapter—This option forces the use of a virtual adapter onthe endpoint. If you select this option, youmust also set up IP address pools even
if a NAT device is not present.
• Persistent Tunnel Mode—This option allows you to determine whether or not a
tunnel is established when a user first connects to the IC Series device. 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.
8. From the Enforcer drop-down list, choose the Infranet Enforcer to which endpoints
connect to access the resources specified in this IPsec routing policy.
9. In the Roles section, specify:
• Policy applies to ALL roles—Choose this option to apply this IPsec routing policy
to all users.
• Policy applies to SELECTED roles—Choose this option 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.
• Policyapplies toall rolesOTHERTHANthoseselectedbelow—Choose thisoption
to apply this IPsec routing policy to all users except for those whomap to the roles
in the Selected roles list. Be sure to add roles to this list from the Available roles list.
10. Click Save Changes.
RelatedDocumentation
IPsec Routing Policies for the Junos Enforcer on page 28•
• Before Configuring IPsec Routing Policies on page 28
Configuring an IP Address Pool Policy
To configure an IP address pool policy:
1. Select UAC > Infranet Enforcer > IP Address Pools.
2. Click NewPolicy.
3. On the New Policy page:
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 to assign to
endpoints. The IP address range can be specified as shown in Table 15 where the last
Copyright © 2014, Juniper Networks, Inc.54
Junos SRX Enforcer Feature Guide
component of the IP address is a range delimited by a hyphen (-). Special characters
are not allowed.
Table 7: Syntax for IP Address Pools
DescriptionIP Address Range
A single IP addressa.b.c.d
All IP addresses from the first address to the last address, inclusivea.b.c.d-e.f.g.h
An abbreviated form that specifies the range a.b.c.d through a.f.g.ha.b.c.d-f.g.h
An abbreviated form that specifies the range a.b.c.d through a.b.g.ha.b.c.d-g.h
An abbreviated form that specifies the range a.b.c.d through a.b.c.ha.b.c.d-h
All addresses in a networka.b.c.d/mask
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
notaddany InfranetEnforcers, and leave thedefault setting (all) listed in theSelected
Enforcers list.
6. In the Roles section, specify:
• 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
who are mapped to roles in the Selected roles list. Be sure to add roles to this list
from the Available roles list.
• Policyapplies toall rolesOTHERTHANthoseselectedbelow—Toapply this IPaddress
pool policy to all users except for those whomap to the roles in the Selected roles
list. Be sure to add roles to this list from the Available roles list.
7. Click Save Changes.
If the IP addresses you specify in the IP address pool policies (that is, the virtual IP
addresses)arenot routable fromthenetworkwhere yourprotected resourcesare 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.
55Copyright © 2014, Juniper Networks, Inc.
Chapter 10: IPsec
3. Click Advanced.
4. Select Source Translation and clickOK.
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
.
RelatedDocumentation
• Using IP Address Pool Policies for IPsec in a NAT Environment on page 29
• Understanding IP Address Pool Policies on page 31
Copyright © 2014, Juniper Networks, Inc.56
Junos SRX Enforcer Feature Guide
CHAPTER 11
Resource Access Policies
• Configuring Resource Access Policies on page 57
Configuring Resource Access Policies
To configure Infranet Enforcer resource access policies:
1. Select UAC > Enforcer > Resource Access Policy.
2. Click NewPolicy.
3. On the New Policy page:
a. For Name, enter a name to label this Infranet Enforcer resource access policy.
b. (Optional) For Description, enter a description.
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 policyto all users.
• Policy applies to SELECTED roles—To apply this Infranet Enforcer resource accesspolicy 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 whomap 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.
57Copyright © 2014, Juniper Networks, Inc.
If you select deny, a text box is displayed that allows you to customize adenymessage
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 longperiodof timewhilewaiting
for connection initiations that the firewall is blocking.With thedenyaction, theEnforcer
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. To enforce the policies, youmust create
corresponding policies on the ScreenOS Enforcer. If the Access Control Service 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. Themain UAC > Infranet Enforcer > Resource Access
Policy page displays the Enforcers and/or vsys that are associated with each policy.
10. Click Save Changes.
RelatedDocumentation
• About Resource Access Policies on page 33
Copyright © 2014, Juniper Networks, Inc.58
Junos SRX Enforcer Feature Guide
CHAPTER 12
Auth Tables and Mapping Policies
• Configuring Dynamic Auth Table Allocation on page 59
• Configuring Auth Table Mapping Policies for Source IP Enforcement on page 59
• Configuring Auth Table Mapping Policies on page 61
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
DefaultPolicyor specify anEnforcer forwhich youdonotwant to configure this feature.
2. Click Save Changes.
3. Configure a source IP policy for all traffic, whether source IP or IPsec.
RelatedDocumentation
Understanding Dynamic Auth Table Allocation on page 39•
Configuring Auth Table Mapping Policies for Source IP Enforcement
NOTE: If you are using the Junos Enforcer or ScreenOS Release 6.1 or lateron the ScreenOS Enforcer, and you have permitted dynamic auth tableallocation, you do not need to configure auth table mapping policies. Youcan use dynamic auth table allocation.
TheAccessControlService configuration includesonedefault auth tablemappingpolicy.
When the default auth table mapping policy is enabled, the Access Control Service
pushes one auth table entry for each authenticated user to all Infranet Enforcer devices
connected to theAccessControl Service. An auth table entry consists of the user’s name,
a set of roles, and the IP address of thewired adapter, wireless adapter, or virtual adapter
in the user’s computer. If your deployment includes amixture 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.
59Copyright © 2014, Juniper Networks, Inc.
Figure5onpage60 illustratesanexampleofadeployment that includesahigher-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
deploymentsbydeleting thedefault auth tablemappingpolicy andcreatingnewpolicies.
An auth table mapping policy specifies which Infranet Enforcer device each user role is
allowed to usewhen the endpoint is using source IP enforcement. These policies prevent
theAccessControl Service fromcreatingunnecessaryauth table entriesonall 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 theSSG5inBranchOffice2.Similarly, theauth tableentries for usersassigned
the HQ-Role are mapped to the ISG 2000 in HQOffice only, and auth table entries for
users assigned the Branch2- Role are mapped to the SSG 5 in Branch Office 2 only.
Figure 5: 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 yourdeploymentdoesnotuse source IPenforcement, or if youhaveconfigureddynamic
provisioning of auth tables, you do not need to create auth table mapping policies. For
IPsec enforcement with the ScreenOS Enforcer, the Access Control Service 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
Copyright © 2014, Juniper Networks, Inc.60
Junos SRX Enforcer Feature Guide
need to create auth table mapping policies for the endpoints that use source IP
enforcement.
With ScreenOS Release 6.2 or later, the Access Control Service supports Virtual systems
vsys. Vsys do not inherit auth table mapping policies from the root-vsyv. If you have an
auth tablemappingpolicyconfigured foranexistingScreenOSEnforcer, andsubsequently
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.
RelatedDocumentation
Understanding Infranet Enforcer Auth Tables on page 39•
Configuring Auth Table Mapping Policies
To configure auth table mapping policies:
1. Select UAC > Enforcer > Auth Table Mapping.
2. Select the default auth table mapping policy called Default Policy and click Delete.
3. On the New Policy page:
a. For Name, enter a name to label this auth table mapping policy.
b. (Optional) For Description, enter a description.
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 whomap 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.
61Copyright © 2014, Juniper Networks, Inc.
Chapter 12: Auth Tables and Mapping Policies
• 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
mappingpolicies. TheAccessControlService includes this default auth tablemapping
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 .
6. Click Save Changes.
RelatedDocumentation
• Understanding Infranet Enforcer Auth Tables on page 39
• Understanding Dynamic Auth Table Allocation on page 39
Copyright © 2014, Juniper Networks, Inc.62
Junos SRX Enforcer Feature Guide
CHAPTER 13
User-Role-Based Firewall
• Configuration Summary on page 63
• ConfigureanActiveDirectory Instanceon JunosPulseAccessControlServiceonpage64
• Configuring SPNEGO Authentication in Browsers on page 65
• Create the Keytab File and Enable Single Sign-on on page 66
Configuration Summary
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
andSPNthatmatch theMAGSeriesdevicehostname.Donot select "Usermustchange
password at next logon.
• 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 Access Control Service” on page 45.
• Configure an Active Directory instance on the MAG Series device. See Using Active
Directory.
• 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.
63Copyright © 2014, Juniper Networks, Inc.
NOTE: Task Guidance, on the Junos Pulse Access Control Service adminconsole can guide you through the basic configuration steps. Refer to thereferenced 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.
• Configure Roles on the MAG Series device. See Understanding User Roles.
• Configure Realms on the MAG Series device. See Specifying Role Mapping Rules for an
Authentication Realm.
• 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 15.
RelatedDocumentation
User Authentication Sequence for Active Directory on page 21•
Configure an Active Directory Instance on Junos Pulse Access Control Service
To define an Active Directory server:
1. Specify a Name to identify the server instance.
2. Enter theDomain. This is theNetBIOSdomainnamefor theorganization.TheNetBIOS
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 theContainerName. This is thenameof the container in activedirectory inwhich
to create the machine name.
8. Enter the Computer Name. The computer name field is where you specify the name
that the Access Control Service uses to join the specified Active Directory domain as
acomputer.Otherwise, leave thedefault identifier that uniquely identifies your system.
Youmay 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 Access Control Service. With unique name (either the one provided by default or
one of your choice) you canmore easily identify your systems in the Active Directory.
For example, the name csan be something like vc0000a1018dF2.
Copyright © 2014, Juniper Networks, Inc.64
Junos SRX Enforcer Feature Guide
In a clustered environment with the same Active Directory authentication server, this
name is also unique among all cluster nodes. The Access Control Service 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 themost securemethodand is required forKerberosSingleSign-on
authentication.
• Enable NTLM protocol - (This is required for passwordmanagement.) Kerberos
authentication is attempted first. Select oneof the followingoptions 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 theNestedGroupSearchDepth field, enter themaximumnumber of levels to search
throughwhen flattening nested groupmemberships. Note that the higher the number
you use here the more impacted performancemay be.
13. In the SPNEGO Single Sign On section, select the Enable SPNEGO check box to use
the JunosPulseAccessControlServiceuser role firewall policy feature. EnableSPNEGO
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.
15. Click Save Changes.
16. Verify that you havemade a successful connection with the Active Directory server
by clicking the Test Configuration button.
Configuring SPNEGOAuthentication in Browsers
SPNEGO provides single sign-on capability for users when protected resources are
accessed using a supported browser. SPNEGO performs the server side (Junos Pulse
Access Control Service) 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 Junos Pulse Access Control Service 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.
65Copyright © 2014, Juniper Networks, Inc.
Chapter 13: User-Role-Based Firewall
The Junos Pulse Access Control Service supports Kerberos sent in SPNEGO tokens.
NOTE: Internet Explorer, Firefox (Windows andMacintosh), and Chromebrowsers 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 Junos Pulse Access Control Service URL.
ActiveDirectory supports theconceptofGroupPolicies topushconfiguration toendpoints
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 JunosPulseAccessControl
as a trusted site.
InActiveDirectory 2008, theexecutable ‘gpms.msc’ canbeused to createaGroupPolicy.
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 trustedURL is added in Internet Explorer, Chromeworkswith SPNEGO. Chromedoes
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.
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 Junos Pulse Access Control Service, and the shared key
used between the Active Directory server and Junos Pulse Access Control Service. 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:
Copyright © 2014, Juniper Networks, Inc.66
Junos SRX Enforcer Feature Guide
ktpass -out<filename> -mapuser(username>@<DOMAIN> -princ HTTP/<server
FQDN>@<DOMAIN> -pass<password>
For example, if the FQDN name of Junos Pulse Access Control Service is
ic6000.ucdc.com, Users belong to the UCDC.COM domain, and the account created
above, the command is:
ktpass -out ic.ktpass -mapuser [email protected] - princ
HTTP/[email protected] - pass Juniper
This creates a file named ic.ktkpass.
2. Upload the ic.ktpass to the Junos Pulse Access Control device when you enable
SPNEGO in the Active Directory server instance.
3. Navigate to the realm(s) that you have created atUsers >User Realms and select the
Enable SSO check box.
67Copyright © 2014, Juniper Networks, Inc.
Chapter 13: User-Role-Based Firewall
Copyright © 2014, Juniper Networks, Inc.68
Junos SRX Enforcer Feature Guide
PART 3
Administration
• Interfaces on page 71
• Junos Enforcer on page 75
• Redirect Policy on page 79
• Captive Portal on page 83
69Copyright © 2014, Juniper Networks, Inc.
Copyright © 2014, Juniper Networks, Inc.70
Junos SRX Enforcer Feature Guide
CHAPTER 14
Interfaces
• Binding an Interface to a Security Zone on a Junos Enforcer on page 71
• Binding the Physical Interface on the Junos Enforcer on page 73
Binding an Interface to a Security Zone on a Junos Enforcer
Interfacesareadoorway throughwhich traffic entersandexitsa JuniperNetworksdevice.
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 definemultiple security
zones based on network requirements.
You can configuremultiple security zones bydividing the network into segments towhich
you can then apply various security options to satisfy the needs of each segment. At a
minimum, youmustdefine twosecurity zones, basically toprotectoneareaof thenetwork
from the other. On some security platforms, you candefinemany security zones, bringing
finer granularity to the network security design without deploying multiple security
appliances to do so.
Fromtheperspectiveof security policies, traffic entersone security zoneandexits 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.
Youmight need to bind the physical interfaces on a Juniper security device to security
zones or youmight need to change a binding to accommodate your deployment.
71Copyright © 2014, Juniper Networks, Inc.
NOTE: Slot numbering varies by platform, and interface numbering variesbymodule type. For numbering information, see the user guide thataccompanied thedevice for slot and interface numbering information or visitwww.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 onPhysical InterfaceModules (PIMs) that you can install in slots on the device.In addition, eachdevice has four built-inGigabit Ethernet ports in slot0. Eachphysical port can havemany logical interfaces configured with propertiesdifferent from the port's other logical units.
Endpoints must reside in a different security zone from your protected resources. The
Access Control Service can reside in any security zone. If you place the Access Control
Service in a different security zone from the one that contains endpoints, youmust set
a policy allowing traffic from the endpoints to the Access Control Service.
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 anothermust use. Because you can bindmultiple 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
RelatedDocumentation
Binding the Physical Interface on the Junos Enforcer on page 73•
• Junos OS Documentation
Copyright © 2014, Juniper Networks, Inc.72
Junos SRX Enforcer Feature Guide
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
statement in Edit mode:
73Copyright © 2014, Juniper Networks, Inc.
Chapter 14: Interfaces
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
statement in Edit mode:
user@host# set security zones security-zone untrust interfaces interface
NOTE: To use IPsec with the Junos Enforcer, youmust enable IKE servicesfor the gateway. If you havemultiple IPsec tunnels withmultiple gateways,the hostname for each gatewaymust be unique.
RelatedDocumentation
• Binding an Interface to a Security Zone on a Junos Enforcer on page 71
Copyright © 2014, Juniper Networks, Inc.74
Junos SRX Enforcer Feature Guide
CHAPTER 15
Junos Enforcer
• Setting Up the Junos Enforcer toWork with Junos Pulse Access Control
Service on page 75
• Connecting with the Junos Enforcer on page 76
Setting Up the Junos Enforcer toWork with Junos Pulse Access Control Service
This example details a configuration with the Access Control Service on the untrusted
interface side (the same side as endpoints).
NOTE: SRX communication to the Access Control Service is not supportedon an interface that is in a routing instance or VRF instance.
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 Access Control Service.
2. Ensure that the DHCP server is disabled or enabled as required for the deployment.
3. Create an Access Control Service configuration on the Junos security device, and
provide thenetwork information required for connectingusing theCLI. This information
includes the Access Control Service host name, the IP address, and the interface to
which the device will connect. The default port for communication with the Access
ControlService is 11123, youcannotchange theport. Youmustalsospecifyapassword,
that matches the password configured on the Access Control Service.
a. Specify the Access Control Service hostname:
user@host# set services unified-access-control infranet-controller hostname
b. Specify the Access Control Service IP address:
user@host# set services unified-access-control infranet-controller hostname addressip-address
c. Specify the Junos interface to which the Access Control Service should connect:
user@host# set services unified-access-control infranet-controller hostname interfaceinterface-name
d. Specify the password that the SRX Series or J Series device should use to initiate
secure communications with the Access Control Service:
75Copyright © 2014, Juniper Networks, Inc.
user@host# set services unified-access-control infranet-controller hostname passwordpassword
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 reconnectwith theAccessControlService if nocommunication is received.
The interval specifies how often the Access Control Service sends a heartbeat to the
Junos Enforcer.
5. (Optional)Verify that thecertificateof theCA that signed theAccessControlService’s
server certificate is loaded in the Junos Enforcer and that the path to the certificate
is specified.
NOTE: Althoughcertificateverification isoptional, thereare threedifferentcertificateoptionson the JunosEnforcer thatwill producedifferent results.
If certificate-verification is set to required, it is required that the deviceverify any Access Control Service server certificate. If any Access ControlService ca-profile is not configured, the commit check fails.
If certificate-verification is set to warning (the default), and the AccessControl Service ca-profile is not configured, the commit check displays awarning about the security risk with a similar warning in the syslog.
If certificate-verification is set to optional, there is no warning.
JuniperNetworkshighly recommends that youchoose toverify theAccessControl Service certificate.
6. Verify routing from the Access Control Service to the untrusted interface.
7. Ensure that both the Junos Enforcer and the Access Control Service 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 Access Control Service instance, the Junos Enforcer can
initiate the connection with the Access Control Service. The Junos Enforcer optionally
validates the Access Control Service server certificate if so configured. The device sends
the serial number to authenticate with the Access Control Service.
For the JunosEnforcer toestablishcommunication, youmust configure the JunosEnforcer
on the Access Control Service.
RelatedDocumentation
Junos OS: Infranet Authentication Feature Guide for Security Devices•
• Connecting with the Junos Enforcer on page 76
Connecting with the Junos Enforcer
The JunosEnforcer connectswith the InfranetEnforcer over anSSLconnection. To initiate
the connection between the two devices, youmust specify the password and serial
number of the Junos Enforcer.
Copyright © 2014, Juniper Networks, Inc.76
Junos SRX Enforcer Feature Guide
The Junos Enforcer initiates the connection to the Access Control Service. The Access
Control Service 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 Access Control Service must comply.
The Junos Enforcer and the Access Control Service performmutual authentication with
theproprietary JUEP-MAUTHchallenge-responseauthenticationbasedon thepassword
configured. For security reasons, the password is not included in themessage sent to the
Access Control Service.
After theSSLhandshake, all further communication between theAccessControl Service
and the Junos Enforcer occurs over the SSL connection. The Junos Enforcer is the client
and the Access Control Service is the server.
To configure the Access Control Service to accept a connection from the Junos Enforcer:
1. 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 Access Control Service is configured for the
interface to which the Junos Enforcer is connecting.
8. Click Save Changes.
After you the devices to communicate, youmust create security policies on the Junos
Enforcer for traffic enforcement.
RelatedDocumentation
• Understanding Infranet Enforcer Source IP Security Policies on page 11
• Setting Up the Junos Enforcer toWork with Junos Pulse Access Control Service on
page 75
77Copyright © 2014, Juniper Networks, Inc.
Chapter 15: Junos Enforcer
Copyright © 2014, Juniper Networks, Inc.78
Junos SRX Enforcer Feature Guide
CHAPTER 16
Redirect Policy
• Creating a Redirect Policy on the Infranet Enforcer on page 79
• Creating a Redirect Policy on the Junos Enforcer on page 81
Creating a Redirect Policy on the Infranet Enforcer
To configure the captive portal feature, youmust 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 theWeb 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 Access Control Service, or to
an IP address or domain name that you specify in a redirect URL.
After a user signs in to the Access Control Service and the user’s endpoint system
meets the requirements of the Access Control Service’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 thisoption if yourdeploymentuses IPseconly. The InfranetEnforcer redirects
all clear-text traffic to the currently connected Access Control Service, or to an IP
address or domain name that you specify in a redirect URL.
After a user signs in to the Access Control Service, OAC or Pulse creates a VPN tunnel
between theuser and the Infranet Enforcer. The Infranet Enforcer thenapplies theVPN
policy that allows the user’s encrypted traffic to pass through. This option does not
allowclear text traffic topass through the Infranet Enforcer,whichprotects thenetwork
from IP spoofing.
From the Junos CLI
79Copyright © 2014, Juniper Networks, Inc.
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 ScreenOSWebUI
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. ClickNew. The advanced Policy Settings page is displayed.
5. Enter the policy configuration information such as source and destination addresses.
Formoreaboutpolicy configurationoptions, see theScreenOSEnforcerWebUIonline
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. ClickOK.
11. ClickOK again.
You can permit more versatile redirect support on a per-policy basis. If your Infranet
Enforcer connects to different Access Control Services (though only one at a time can
communicate), you can configure the URL for each redirect policy. If a policy-based URL
isdefinedand redirect is enabled in thepolicy, unauthenticatedHTTP traffic thatmatches
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-authredirect-unauthenticated
Copyright © 2014, Juniper Networks, Inc.80
Junos SRX Enforcer Feature Guide
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
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
Bydefault, after you configure a captive portal policy, the JUNOSEnforcer redirectsHTTP
traffic to the currently connected Access Control Service by using HTTPS. To perform
the redirection, the JUNOSEnforceruses the IPaddressordomainnamethat youspecified
when you configured the Access Control Service instance on the JUNOS Enforcer.
You specify the redirect url in a JunosEnforcer security policy using the followinghierarchy:
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 charactersinstead 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.
RelatedDocumentation
• Understanding the Infranet Enforcer Captive Portal Feature on page 15
• Before Configuring Captive Portal on page 16
81Copyright © 2014, Juniper Networks, Inc.
Chapter 16: Redirect Policy
Copyright © 2014, Juniper Networks, Inc.82
Junos SRX Enforcer Feature Guide
CHAPTER 17
Captive Portal
• Overriding the Default Redirection Destination for Captive Portal on page 83
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 Access Control Service using
HTTPS. To perform the redirection, the Infranet Enforcer uses the IP address or domain
name that you specified when you configured the Access Control Service 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 Access Control Services
inacluster, and thecurrentAccessControlServicebecomesdisconnected, theScreenOS
Enforcer automatically redirects HTTP traffic to the next active Access Control Service
in its configuration list. TheScreenOSEnforcer redirects traffic to only oneAccessControl
Service at a time.
The Access Control Service domain name that you specify when configuring the Access
ControlService instance in theScreenOSEnforcermustmatch theAccessControlService
domain name in theWeb 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, and the ScreenOS Enforcer is configured to connect
to the Access Control Service’s physical IP addresses.
• You want to redirect traffic to aWeb server instead of to the Access Control Service.
• If, because of split DNS or IP routing restrictions at your site, the ScreenOS Enforcer
usesadifferentaddress for theAccessControlService thanendpoints, youmust specify
the domain name or IP address that endpointsmust use to access the Access Control
Service.
83Copyright © 2014, Juniper Networks, Inc.
By default, the ScreenOS Enforcer also encodes and forwards to the Access Control
Service the protected resource URL that the user entered. The Access Control Service
uses the protected resource URL to help users navigate to the protected resource. The
manner in which the Access Control Service 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 Access Control Service 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 Access Control Service 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, youmust 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 theWeb UI
or the CLI.
Copyright © 2014, Juniper Networks, Inc.84
Junos SRX Enforcer Feature Guide