Junos Pulse Access Control Service Junos SRX Enforcer Feature … · 2014. 2. 10. · Author:...

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

http://www.juniper.net/support/eula.html

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


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


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

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


Figure 3: Example Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Chapter 5 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Figure 4: Using an IP Address Pool in a NAT Environment . . . . . . . . . . . . . . . . . . . 30


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.

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


Table 4: Understanding Log Messages Related to Active Directory and

SPNEGO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24


Table 5: DNS Hostname Special Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Table 6: Port Possible Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35


Chapter 10 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Table 7: Syntax for IP Address Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

ixCopyright © 2014, Juniper Networks, Inc.

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.

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

http://www.juniper.net/books

http://www.juniper.net/techpubs/en_US/release-independent/uac/information-products/pathway-pages/unified-access-control/product/



http://www.juniper.net/techpubs/en_US/release-independent/mag/information-products/pathway-pages/mag-series/product/

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


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

mailto:[email protected]

https://www.juniper.net/cgi-bin/docbugreport/

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


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

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

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

http://www2.juniper.net/kb/


http://kb.juniper.net/

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

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

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

http://www.juniper.net/cm/

https://tools.juniper.net/SerialNumberEntitlementSearch/

http://www.juniper.net/cm/

http://www.juniper.net/support/requesting-support.html

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.

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.


• 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



• 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


Chapter 1: Deployments

https://www.juniper.net/techpubs/software/uac/4.3xrelnotes/j-ic-uac-4.3r1-supportedplatforms.pdf

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.



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.


• Connecting with the Junos Enforcer on page 76


Chapter 1: Deployments

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.


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.


About Resource Access Policies on page 33•


• 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



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


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



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


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


• 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



http://www.juniper.net/techpubs/software/screenos/screenos6.3.0/630_ce_fundamentals.pdf

http://www.juniper.net/techpubs/software/screenos/screenos6.3.0/630_ce_UserAuth.pdf

http://www.juniper.net/techpubs/software/screenos/screenos6.3.0/630_ce_UserAuth.pdf

https://www.juniper.net/techpubs/en_US/junos12.1x46/information-products/pathway-pages/security/security-authentication-infranet.html

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.


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.


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



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


Chapter 3: Captive Portal

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.


UAC Solution Guide for SRX Series Services Gateways•

• Supported Versions on page 24


http://www.juniper.net/techpubs/en_US/release-independent/uac/information-products/topic-collections/srx-series/uac/index.html

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)



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.


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.


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.



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


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)


•

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.


•



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.


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.


IPsec Policies on the Junos Enforcer on page 26•



• Before Configuring IPsec on the Junos Enforcer on page 27


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.


Using IPsec with the Junos Enforcer on page 27•






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.


IPsec and the Junos Enforcer on page 25•


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.


Before Configuring IPsec on 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


Chapter 5: IPsec

https://www.juniper.net/techpubs/software/uac/4.2xrelnotes/j-ic-uac-4.2r1-supportedplatforms.pdf

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


IPsec and the Junos Enforcer on page 25•

• IPsec Policies on the Junos Enforcer on page 26


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


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



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


IPsec Routing Policies for the Junos Enforcer on page 28•


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.


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.



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


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


Chapter 5: IPsec

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.


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.


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.



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


Chapter 6: Resource Access Policies

tcp://10.11.0.10:80

udp://10.11.0.10:*



• Configuring Resource Access Policies on page 57

• Using Host Enforcer Policies



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.




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.


Understanding Dynamic Auth Table Allocation on page 39•

• Configuring Dynamic Auth Table Allocation 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


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.



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




Chapter 8: Auth Tables

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


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.



Setting Up the Junos Enforcer toWork with Junos Pulse Access Control Service on

page 75

•


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.



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.




Chapter 9: Junos Enforcer

CHAPTER 10

IPsec

• Configuring Junos Enforcer IPsec Routing Policies on page 49



Configuring Junos Enforcer IPsec Routing Policies

This topic describes how to configure Junos Enforcer IPsec routing policies. It includes

the following information:


• Configuration Example on page 50


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.


• 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



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.


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.



• 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


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:


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.


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.


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



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.


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.


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

.



• Understanding IP Address Pool Policies on page 31



http://www.juniper.net/techpubs/en_US/release-independent/screenos/information-products/pathway-pages/screenos/product/index.html

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.


a. For Name, enter a name to label this Infranet Enforcer resource access policy.


4. For Resources, specify the protocol, IP address, network mask, and port of each

resource (or range of addresses) for which this Infranet Enforcer resource access

policy applies, one per line. Do not insert any spaces in your entries, or the policy may

not be applied correctly.

You cannot specify a host name in a resource access policy. You can specify only an

IP address. You can use TCP, UDP, or ICMP.

5. Under Infranet Enforcer, specify the Infranet Enforcer to which this policy applies by

using Add.

6. Specify one of the following in the Roles section:

• Policy applies to ALL roles—To apply this Infranet Enforcer resource access 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.


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.






CHAPTER 12

Auth Tables and Mapping Policies



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


3. Configure a source IP policy for all traffic, whether source IP or IPsec.


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.


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



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.


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.


a. For Name, enter a name to label this auth table mapping policy.


c. In the Enforcer section, specify the Infranet Enforcer device(s) to which you want

to apply this auth table mapping policy.

d. In the Roles section, specify:

• Policy applies to ALL roles—To apply this auth table mapping policy to all users.

• Policy applies to SELECTED roles—To apply this auth table mapping policy only

to users who are mapped to roles in the Selected roles list. Be sure to add roles

to this list from the Available roles list.

• Policy applies to all roles OTHER THAN those selected below—To apply this

auth table mapping policy to all users except for those 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.


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 .



• Understanding Infranet Enforcer Auth Tables on page 39

• Understanding Dynamic Auth Table Allocation on page 39



CHAPTER 13

User-Role-Based Firewall


• ConfigureanActiveDirectory Instanceon JunosPulseAccessControlServiceonpage64

• Configuring SPNEGO Authentication in Browsers on page 65

• Create the Keytab File and Enable Single Sign-on on page 66


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.


http://www.juniper.net/techpubs

http://www.juniper.net/support/products/mag/

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.


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.



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.


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.


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:





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.


Chapter 13: User-Role-Based Firewall

PART 3

Administration

• Interfaces on page 71

• Junos Enforcer on page 75

• Redirect Policy on page 79

• Captive Portal on page 83


CHAPTER 14

Interfaces


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


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


Binding the Physical Interface on the Junos Enforcer on page 73•

• Junos OS Documentation




http://www.juniper.net/techpubs/en_US/release-independent/junos/information-products/pathway-pages/junos/product/

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



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


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.





CHAPTER 15

Junos Enforcer

• Setting Up the Junos Enforcer toWork with Junos Pulse Access Control

Service on page 75


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:


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.


Junos OS: Infranet Authentication Feature Guide for Security Devices•


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.



https://www.juniper.net/techpubs/en_US/junos12.1x46/information-products/pathway-pages/security/security-authentication-infranet.html

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.


After you the devices to communicate, youmust create security policies on the Junos

Enforcer for traffic enforcement.



• Setting Up the Junos Enforcer toWork with Junos Pulse Access Control Service on

page 75


Chapter 15: Junos Enforcer

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


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



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.


• Understanding the Infranet Enforcer Captive Portal Feature on page 15

• Before Configuring Captive Portal on page 16


Chapter 16: Redirect Policy

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.


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.



Junos Pulse Access Control Service Junos SRX Enforcer Feature … · 2014. 2. 10. · Author:...

Documents

Transcript of Junos Pulse Access Control Service Junos SRX Enforcer Feature … · 2014. 2. 10. · Author:...