Pulse Policy Secure - Juniper Networks...© 2015 by Pulse Secure, LLC. All rights reserved vii List...

© 2015 by Pulse Secure, LLC. All rights reserved

Pulse Policy Secure Layer 2 and the Pulse Policy Secure Series RADIUS Server

Product Release 5.1

Document Revision 1.0

Published: 2015-02-10

Pulse Secure, LLC 2700 Zanker Road, Suite 200 San Jose, CA 95134 http://www.pulsesecure.net


Pulse Secure and the Pulse Secure logo are trademarks of Pulse Secure, LLC in the United States. All other trademarks, service marks, registered

trademarks, or registered service marks are the property of their respective owners.

Pulse Secure, LLC assumes no responsibility for any inaccuracies in this document. Pulse Secure, LLC reserves the right to change, modify, transfer,

or otherwise revise this publication without notice. Layer 2 and the Pulse Policy Secure Series RADIUS Server

The information in this document is current as of the date on the title page.

END USER LICENSE AGREEMENT

The Pulse Secure product that is the subject of this technical documentation consists of (or is intended for use with) Pulse Secure software. Use of

such software is subject to the terms and conditions of the End User License Agreement (“EULA”) posted at http://www.pulsesecure.net/support/eula.

By downloading, installing or using such software, you agree to the terms and conditions of that EULA.”

http://www.pulsesecure.net/

http://www.pulsesecure.net/support/eula


iii

Abbreviated Table of Contents

About This Guide .................................................................................................... xi

Part 1 Pulse Policy Secure and RADIUS

Chapter 1 RADIUS Authentication ............................................................................................ 3

Chapter 2 Using the Pulse Policy Secure for 802.1X Network Access ............................... 17

Part 2 Using the Pulse Policy Secure Controller RADIUS Server

Chapter 3 RADIUS Examples and Use Cases ........................................................................ 39

Part 3 Configuring the Pulse Policy Secure Controller to Work with VLANs

Chapter 4 VLANs ...................................................................................................................... 61

Part 4 Index

Index ........................................................................................................................ 67

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

Layer 2 and the Pulse Policy Secure Series RADIUS Server


v

Table of Contents


Objectives .............................................................................................................................. xi

Audience ................................................................................................................................ xi

Documentation Conventions ....................................................................................... xi

Documentation.............................................................................................................. xiii

Obtaining Documentation........................................................................................... xiii

Documentation Feedback .......................................................................................... xiii

Requesting Technical Support ................................................................................... xiii

Self-Help Online Tools and Resources ............................................................... xiv

Opening a Case with PSGSC ............................................................................................ xiv

Part 1 UAC and RADIUS


Using the Access Control Service RADIUS Server ...................................................................... 3

Understanding Access Control Service RADIUS Server Features ................................... 4

Understanding Access Control Service Authentication Protocols ................................... 5

Using Access Control Service Authentication Protocol Sets ............................................ 7

Using an 802.1X IP Phone with the Pulse Policy Secure Series .......................... 10

Configuring Authentication Protocol Sets ...................................................................... 10

Using RADIUS Proxy ............................................................................................................................ 11

Understanding RADIUS Authentication and Accounting Time Limits .......................... 13


Understanding 802.1X Network Access Control Deployments ........................................... 17

Task Summary: Configuring the Pulse Policy Secure Series Device as a RADIUS Server for an

802.1X Network Access Device ..................................................................................... 20

Using Location Groups with Network Access Devices ............................................... 20

Configuring Pulse Policy Secure a Location Group ...................................................... 22

Understanding the RADIUS Client Configuration .............................................................. 23

RADIUS Client Configuration Overview ................................................................... 23

Sending Disconnect Requests to NADs (Dynamic Authorization Support)

Using a RADIUS Client Policy ............................................................................... 24

Before Configuring a RADIUS Client................................................................................ 24

Configuring a RADIUS Client ............................................................................................ 25

Using RADIUS Client Dictionary Files .................................................................................. 26

Uploading a New RADIUS Client Dictionary ................................................................... 27

Creating a RADIUS Dictionary Based on an Existing Model ........................................ 27

Creating RADIUS Dictionary Files ......................................................................................... 28

Understanding RADIUS Attributes Policies ........................................................................ 30

RADIUS Attributes Policy Configuration Guidelines ............................................................. 31

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


Creating a RADIUS Attributes Policy ..................................................................................... 32

Understanding RADIUS Request Attribute Policies .......................................................... 34

Configuring a RADIUS Request Attribute Policy ................................................................ 35

Understanding RADIUS Attribute Logging ...................................................................... 35

Configuring RADIUS Attribute Logging ............................................................................ 36

Part 2 Using the Pulse Policy Secure RADIUS Server

Chapter 3 RADIUS Examples and Use Cases ........................................................................ 39

Using RADIUS Attributes in Access Policies ....................................................................... 39

Use Case 1: Configuring VLAN Assignment by Returning RADIUS Tunnel

Attributes .............................................................................................................................. 39

Use Case 2: Configuring VLAN Assignment Along with Other Attributes . . . 40

Use Case 3: Configuring VLAN Assignment or Policies by using the Filter-ID

Return Attribute ............................................................................................. 40

Use Case 4: Configuring VLAN Assignment in a Heterogeneous

Environment ................................................................................................... 40

Use Case 5: Using RADIUS Attributes with OAC to Avoid Disconnecting

Concurrent Network Connections ..................................................................... 41

Use Case: Using an EX Series Ethernet Switch as a RADIUS Client........................... 42

Associating an Infranet Enforcer with the Access Control Service RADIUS

Server .................................................................................................................................... 45

Use Case: Using a Non-Pulse Secure 802.1X Supplicant ............................................ 46

Before Configuring a Non- Non-Pulse Secure Supplicant ............................................ 47

Configuring a Non- Pulse Secure Networks Supplicant for 802.1X ....................... 48

Configuring Access to Switches and Access Points from a Browser ............................. 49

Authenticating Users with Non-Tunneled Protocols ................................................... 49

Using a MAC Authentication Server .............................................................................. 50

About Unmanageable Devices ...................................................................................... 50

Configuring MAC Authentication ....................................................................................... 51

Third-Party Solutions ................................................................................................... 52

Use Case: Using an External LDAP Server for MAC Address Authentication ............ 53

Configuring Network Access Policies for Unmanageable Devices ................................. 55

Creating a MAC Address Realm .................................................................................... 55

Configuring a Location Group for MAC Address Authentication ...................... 56

Configuring a RADIUS Client for MAC Address Authentication ............................ 57

Configuring RADIUS Attributes for MAC Address Authentication ........................ 57

Part 3 Configuring the Pulse Policy Secure to Work with VLANs

Chapter 4 VLANs ...................................................................................................................... 61

Using VLANs with the Pulse Policy Secure Series .......................................................... 61

Enabling Endpoints to Connect to VLANs behind the Pulse Policy Secure Series Device ............................................................................................................................................ 62

Part 4 Index

Index ....................................................................................................................................... 67

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

List of Figures


Chapter 2 Using the Pulse Policy Secure for 802.1X Network Access ................................ 17

Figure 1: Pulse Policy Secure Series Device as a RADIUS Server for an 802.1X Network Access

Device ............................................................................................................................................. 19

Figure 2: Using Location Groups to Group Network Access Devices ........................... 22

Part 2 Using the Pulse Policy Secure RADIUS Server

Chapter 3 RADIUS Examples and Use Cases ......................................................................... 39

Figure 3: 802.1X Deployment with the EX4200 Switch .............................................. 44

Figure 4: Example MAC Authentication Configuration .....................................................51

Part 3 Configuring the Pulse Policy Secure to Work with VLANs

Chapter 4 VLANs ....................................................................................................................... 61

Figure 5: Using a RADIUS Attributes Policy to Specify VLANs for Endpoints .......... 63

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

List of Tables


Table 1: Notice Icons .................................................................................................................... xii

Table 2: Text Conventions ................................................................................................... xii



Table 3: Authentication Protocols ...................................................................................... 8

Table 4: Authentication Protocol Set Configuration Guidelines ................................... 9

Table 5: RADIUS Event Time Limits ......................................................................................... 14


Table 6: Valid Data Types...................................................................................................... 28


xi

About This Guide

Objectives on page xi

Audience on page xi

Documentation Conventions on page xi

Documentation on page xiii

Obtaining Documentation on page xiii

Documentation Feedback on page xiii

Requesting Technical Support on page xiii

Objectives

This guide describes basic configuration procedures for Pulse Policy Secure.

Audience

This guide is designed for network administrators who are configuring and maintaining

a Pulse Policy Secure. To use this guide, you need a broad understanding of networks

in general and the Internet in particular, networking principles, and network

configuration. Any detailed discussion of these concepts is beyond the scope of this

guide.

Documentation Conventions

Table 1 on page xii defines the notice icons used in this guide. Table 2 on page xii defines

text conventions used throughout this documentation.

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


Table 1: Notice Icons

Informational note Indicates important features or instructions.

Warning Alerts you to the risk of personal injury or death.

Table 2: Text Conventions

Convention Description Examples

Bold text like this Represents text that the user must type.

user@host# set cache-entry-age

cache-entry-age

Regular sans serif typeface Represents configuration statements.

Indicates SRC CLI commands and options

in text.

Represents examples in procedures.

system ldap server{

stand-alone;

Use the request sae modify device failover

command with the force option

user@host# . . .

Angle brackets In text descriptions, indicate optional

keywords or variables.

Another runtime variable is <gfwif>.

Key name Indicates the name of a key on the keyboard. Press Enter.

Italic sans serif typeface Represents variables in SRC CLI commands. user@host# set local-address

local-address

Fixed-width text like this Represents information as displayed on your nic-locators {

terminal’s screen, such as CLI commands in login {

output displays. resolution {

resolver-name /realms/

login/A1;

key-type LoginName;

value-type SaeId;

}

Bold text like this Represents keywords, scripts, and tools in

text.

Represents a GUI element that the user

selects, clicks, checks, or clears.

Specify the keyword exp-msg.

Run the install.sh script.

Use the pkgadd tool.

To cancel the configuration, click Cancel.

Laser warning Alerts you to the risk of personal injury from a laser.

Caution Indicates a situation that might result in loss of data or hardware damage.

Icon Meaning Description

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

About This Guide

Table 2: Text Conventions (continued)

Key names linked with a plus sign

(+)

Indicates that you must press two or more

keys simultaneously.

Press Ctrl + b.

Backslash At the end of a line, indicates that the text

wraps to the next line.

Plugin.radiusAcct-1.class=\

net.juniper.smgt.sae.plugin\

RadiusTrackingPluginEvent

Documentation

For a list of related Pulse Policy Secure documentation, see

http://www.pulsesecure.net/support. If the information in the latest Pulse Policy Secure Release

Notes differs from the information in the documentation, follow the Pulse Policy Secure

Release Notes.

Obtaining Documentation

To obtain the most current version of all Pulse Secure technical documentation, see the

products documentation page at http://www.pulsesecure.net/support.

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

Requesting Technical Support

Technical product support is available through the Pulse Secure Global Support Center (PSGSC).

If you have a support contract, then file a ticket with PSGSC.

Product warranties—For product warranty information, visit http://www.pulsesecure.net

Words separated by the | symbol Represent a choice to select one keyword or diagnostic | line

variable to the left or right of this symbol.

(The keyword or variable may be either

optional or required.)

Italic typeface Emphasizes words.

Identifies book names.

Identifies distinguished names.

Identifies files, directories, and paths in

text but not in command examples.

There are two levels of access: user and

privileged.

SRC-PE Getting Started Guide.

o=Users, o=UMC

The /etc/default.properties file.

mailto:[email protected]

http://www.pulsesecure.net/

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


Self-Help Online Tools and Resources

For quick and easy problem resolution, Pulse Secure, LLC has designed an online

self-service portal called the Customer Support Center (CSC) that provides you with

the following features:

Find CSC offerings: http://www.pulsesecure.net/support

Search for known bugs: http://www.pulsesecure.net/support

Find product documentation: http://www.juniper.net/techpubs/

Find solutions and answer questions using our Knowledge Base:

http://www.pulsesecure.net/support

Download the latest versions of software and review release notes:


Search technical bulletins for relevant hardware and software notifications:


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


Open a case online in the CSC Case Management tool:

http://www.pulsesecure.net/support To verify service entitlement by product serial number, use our Serial Number Entitlement (SNE) Tool: http://www.pulsesecure.net/support

Opening a Case with PSGSC

You can open a case with PSGSC on the Web or by telephone

Use the Case Management tool in the PSGSC at http://www.pulsesecure.net/support

Call 1-888-314-5822 (toll-free in the USA, Canada, and Mexico)

For international or direct-dial options in countries without toll-free numbers, see

http://www.pulsesecure.net/support.



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









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

PART 1

Pulse Policy Secure and RADIUS

RADIUS Authentication on page 3

Using the Pulse Policy Secure for 802.1X Network Access on page 17


CHAPTER 1

RADIUS Authentication

Using the Access Control Service RADIUS Server on page 3

Understanding Access Control Service RADIUS Server Features on page 4

Understanding Access Control Service Authentication Protocols on page 5

Using Access Control Service Authentication Protocol Sets on page 7

Configuring Authentication Protocol Sets on page 10

Using RADIUS Proxy on page 11

Understanding RADIUS Authentication and Accounting Time Limits on page 13

Using the Access Control Service RADIUS Server

A Network Access Device (NAD) or Ethernet switch is the client for the Pulse Policy

Secure Series Unified Access Control. The NAD passes user connection requests

(supported supplicant endpoints include OAC, Pulse, and non-appliance Pulse

Secure supplicants) to the Pulse Policy Secure Series Appliance, and then acts upon

the response received from the Pulse Policy Secure Series device.

NOTE: The Pulse 802.1X access method interacts with the native wired

and wireless 802.1X supplicant on the client PC.

The Pulse Policy Secure Series appliance receives the endpoint connection request,

authenticates the user, and then returns the configuration parameters required to

provision the connection using RADIUS attributes. The Pulse Policy Secure Series

appliance can also serve as a proxy client to external RADIUS servers to offload

authentication requests.

All transactions between the NAD and the Pulse Policy Secure Series device utilize a

shared secret, which is configured on each device. Additionally, passwords are

encrypted between the NAD and the Pulse Policy Secure series device.

The Pulse Policy Secure Series supports a variety of authentication protocols that can

be configured to permit a number of different authentication types for authentication of

a variety of devices and endpoints.

Using the Pulse Policy Secure Series internal RADIUS server, you can provision

802.1X authentication for endpoints. Layer 2 authentication and enforcement is used

to control network access policies at the edge of the network using an 802.1X

enabled switch or access point such as a Juniper Networks EX Series switch.



The user’s identity and the endpoint health assessment are used to determine which

VLAN to use for the switch port that the endpoint is connected to. Typically, if the

endpoint does not meet minimum criteria for health assessment as defined by the

administrator, the endpoint will be placed on a restricted VLAN which allows access to

servers which can aid in remediating the endpoint.

You define VLAN policies for endpoints that access switches via 802.1X. After an

authenticated endpoint has been mapped to a set of roles, the VLAN policies are

evaluated and the VLAN information is communicated to the switch through RADIUS

attributes. RADIUS attributes vary by make and model of switch. You specify the

make and model when configuring a RADIUS client on the Pulse Policy Secure

Series device.

In addition to authenticating endpoints with 802.1X the Pulse Policy Secure Series

device’s RADIUS server can be used to authenticate 802.1X IP phones, switches,

and the Pulse Policy Secure Series device can perform non-802.1X MAC Address

based authentication for unmanageable devices.

The Pulse Policy Secure ScreenOS Enforcer and the Junos Enforcer use the Pulse

Policy Secure Series device’s RADIUS server for IPsec XAUTH authentication.

Related

Documentation



Configuring Authentication Protocol Sets on page 10

Using RADIUS Proxy on page 11

Understanding Access Control Service RADIUS Server Features

In addition to performing 802.1X port-based authentication, you can configure the

Pulse Policy Secure Series internal RADIUS server for various authentication

methods using a variety of authentication protocols including Extensible

Authentication Protocol (EAP) EAP inner and outer authentication, non-tunneled web

authentication without EAP, and MAC address authentication. EAP provides for

extensibility and is a standard for communication between NADs and servers, and

EAP is also used for Statement of Health (SOH) Host Checker policies.

EAP allows specialized knowledge about authentication protocols to be taken out of

the NAD so that it acts solely as a conduit between the authentication server and the

client. With EAP, new types of authentication can be supported by adding the

appropriate functionality to the server and client without any changes to the NAD or

the protocol. The use of EAP can facilitate 802.1X access as well as traditional

RADIUS authentication for non 802.1X access.

The Pulse Policy Secure Series device supports a variety of authentication protocols.

In addition to Tunneled Transport Layer Security (EAP-TTLS) and Protected EAP

(EAP-PEAP), which the Pulse Policy Secure Series device uses for OAC and Pulse

802.1X connectivity, the Pulse Policy Secure Series device RADIUS server supports

non-tunneled protocols that permit different methods of authentication. For example,

MAC address authentication, 802.1X connectivity with non-Pulse Secure supplicants

and Challenge Handshake Authentication Protocol (CHAP) authentication (to allow

Web access to switches) can be configured on the Pulse Policy Secure Series

device.


Chapter 1: RADIUS Authentication

Using the Pulse Policy Secure Series device RADIUS server and the supported EAP

protocols, you can configure a NAD to support any combination of the following uses:

Unmanageable device authentication

Switch authentication using traditional RADIUS

Non-Pulse Secure 802.1X supplicant authentication

OAC or Pulse 802.1X authentication

802.1X IP phone authentication

The NAD’s location group and sign-in policy govern which users are allowed. The

following sections present a broader view of the configurable parameters on the Pulse

Policy Secure Series device.

Related

Documentation




Understanding Access Control Service Authentication Protocols

The Pulse Policy Secure Series device supports a variety of EAP and non-EAP

authentication methods to allow you to determine how endpoints authenticate.

Authentication methods can have different purposes. For example, you can use the

default EAP methods with OAC and Pulse, or you can use different methods to permit

authentication with different endpoints, such as non-Pulse Secure 802.1X supplicants

and IP phones.

For Pulse Policy Secure agents (OAC, Pulse, the Java agent, and Host Checker

agentless access), authentication is supported via EAP-TTLS and EAP-PEAP as the

outer protocols and EAP-JUAC (a proprietary protocol) by default.

EAP-TTLS first authenticates the server and sets up an encrypted Transport Layer

Security (TLS) tunnel for secure transport of authentication information. Within the

TLS tunnel, a second authentication protocol is used to authenticate the user. EAP-

TTLS is the “outer” authentication, while the second protocol is the “inner”

authentication.

EAP-TTLS consists of two phases. In the first phase, the the X.509 digital certificate

of the authentication server is used by the supplicant to verify its identity, and to

validate the network’s authenticity.

The authentication server is required to present a digital certificate. This digital

certificate is used in the outer authentication to establish the TLS tunnel from the

supplicant to a AAA Server. If there are certificate restrictions, or if the inner protocol

is EAP-TLS, a user certificate is also used.

EAP-PEAP is similar to EAP-TTLS, with a difference being that the inner

authentication must be another EAP exchange. PEAP can only use EAP-compatible

authentication methods. PEAP starts the TLS tunnel, then uses EAP again,

encapsulated inside the tunnel to perform the authentication.



EAP-TTLS and EAP-PEAP authenticate the user and the network, and produce

dynamic keys that can be used to encrypt communications between the endpoint and

access point. With mutual authentication, not only does the network authenticate the

user credentials, but the supplicant also authenticates the authentication server.

Requiring mutual authentication is an important security precaution with wireless

networking. Verifying the identity of the authentication server ensures that you

connect to your intended network, and not to an access point that is pretending to be

the network.

You can authenticate with OAC or a third-party 802.1X supplicant when you configure

the endpoint to validate the certificate of the authentication server. If the certificate

identifies a server that you trust, and if the authentication server can prove that it is

the owner of that certificate, then you can safely connect to the network.

For Pulse with 802.1X you select a certificate when you create a Pulse connection

set. The user can accept or reject the certificate.

EAP-TLS, EAP-TTLS, and EAP-PEAP all employ TLS, the successor of Secure

Socket Layer (SSL). TLS is the protocol used to secure communications between

Web browsers and secure Web servers. In general, the outer protocol ensures that

the client or agent is communicating with a valid, trusted server, and the inner protocol

proves your identity to the Pulse Policy Secure Series device.

The EAP-JUAC inner protocol allows OAC and Pulse to take advantage of the full set

of Pulse Policy Secure Series device features, including Host Checker, firewall

provisioning and IP address restrictions.

In addition to EAP-TTLS and EAP-PEAP, the following standard protocols are

supported for inter-activation with RADIUS clients other than OAC and Pulse:

Password Authentication Protocol (PAP) with plain-text passwords

EAP Generic Token Card (EAP-GTC)

CHAP and the CHAP family, including MS-CHAP, MS-CHAP-V2, EAP-MD5-

Challenge, and EAP-MS-CHAP-V2

EAP Transport Layer Security (EAP-TLS)—The Pulse Policy Secure Series

device supports EAP-TLS to allow non-Pulse Secure 802.1X supplicants to

authenticate via a certificate authentication server.

EAP State of Health (EAP-SOH)

The Pulse Policy Secure Series device supports these authentication protocols as

non-tunneled authentication methods as well as inner authentication methods, subject

to the policies that you configure. You can configure protocol sets with or without

EAP, with the exception of MD5, EAP-GTC, EAP-TLS, and EAP-SOH, which are

supported only for EAP.

EAP-SOH is a special protocol used only with Windows Vista and Windows XP

Service Pack 3 802.1X supplicants in a Statement of Health Host Checker policy. The

EAP-SOH protocol allows the endpoint to exchange state of health messages with

the Pulse Policy Secure Series device to assess endpoint qualification for passing

Statement of Health rules in a Host Checker policy. To use EAP-SOH, you must use

EAP-PEAP as an outer authentication protocol. If you use a protocol set with inner

and outer authentication, both protocols must match the inner and outer protocol that

is configured for the endpoint.



Using Access Control Service Authentication Protocol Sets

You can access the Pulse Policy Secure Series device in several ways. The method

and the protocols you select determine the realm(s) through which endpoints are

authenticated. Any authentication methods that are incompatible with the

authentication server being used are not even attempted. You associate realms with

authentication protocols when you configure a sign-in policy. For information about

configuring realms and sign-in policies, see Access Management Framework.

You can configure any combination of authentication protocols on the Pulse Policy

Secure Series device for use with non-Pulse Secure 802.1X supplicants, or

compatible IP phones, or for non-tunneled access (for example, Web access to a

switch).

There are two default preconfigured protocol sets on the Pulse Policy Secure Series

device. The 802.1X protocol set is used by default with Pulse Policy Secure agents.

802.1X-Phones protocol set is used for authenticating 802.1X IP phones. When you

configure a new sign-in policy, you must associate realms that you have configured

with authentication protocol sets. You can select a protocol set you have created, or

you can use one of the default protocol sets, depending on the endpoint. Endpoints

can access only realms that are configured with compatible authentication protocol

sets.

You can select several authentication protocols for each protocol set. If you select

more than one protocol for inner and outer authentication, the order in which you list

the protocols is important. The EAP protocols are evaluated in order by the Pulse

Policy Secure Series device, with selections at the top of the list considered first for

each connection attempt. If you select EAP-TTLS or EAP-PEAP as primary

authentication protocols, you must select separate inner authentication protocols.

You can duplicate an existing protocol set and make changes, and you can delete

protocol sets you have created. You cannot delete the default 802.1X protocol set, but

you can delete the 802.1X-Phone protocol set.

When an endpoint requests authentication, realm selection is based on which

authentication protocols match. For example, if a client and the Pulse Policy Secure

Series device do not agree on using a selected protocol set, the realm not

considered. Clients that connect to the Pulse Policy Secure Series device include

OAC, Pulse, non- Pulse Secure 802.1X supplicants, 802.1X IP phones, and switches.

The Pulse Policy Secure Series device can accept authentication requests from all of

these endpoints from a single Network Access Server and route the traffic depending

on authentication protocols that are configured for individual realms. Table 3 on page

8 lists the available authentication protocol combinations and provides usage

recommendations for various combinations.



Table 3: Authentication Protocols

PAP [1] n/a Password Local auth server, Active Directory,

LDAP [2] Cisco switch authentication

EAP-MD5-

Challenge [1]

n/a Password Captive portal or authentication of

switch administrators, some IP

phones

MS-CHAP-V2 [1] n/a Password -

EAP-GTC [1] n/a Token -

EAP-PEAP Non-Pulse Secure 802.1X supplicant

EAP-GTC Token

802.1 X supplicant

EAP-JUAC Various OAC

EAP-TTLS OAC, Pulse, other supplicant

CHAP -

MS-CHAP -

EAP-MD5-Challenge -

PAP LDAP authentication server

EAP-SOH Password Windows supplicant with Statement

of Health Host Checker policy

EAP-TLS User Certificate -

EAP-MS-CHAP-V2 Password Local or Active Directory server

EAP-TLS n/a User Certificate 802.1X supplicant, some IP phones

EAP-MS-CHAP-V2 n/a

[1]

Password -

MS-CHAP [1] n/a Password -

CHAP [1] n/a Password Captive portal or authentication of

switch administrators for HP

ProCurve switch

Outer Inner Basis Usage recommendation



Table 3: Authentication Protocols (continued)

EAP-MS-CHAP-V2 Local or Active Directory server

EAP-JUAC OAC, Pulse

NOTE: Pulse always uses EAP-TTLS/EAP-JUAC.

If the supplicant or client supports EAP-TTLS or EAP-PEAP, we recommend

putting this protocol into one of those tunnels for added security.

With LDAP, there are 3 protocol possibilities:

If the LDAP server is also an Active Directory server, configure the server on the

Pulse Policy Secure Series device as an Active Directory server, not as an LDAP

server. On the Pulse Policy Secure Series device, PEAP-MS-CHAP-V2 is enabled

by default. You can also enable MS-CHAP and MS-CHAP-V2 if necessary.

If passwords in the LDAP server are stored irreversibly hashed, CHAP family

protocols will not work, only PAP and TTLS-PAP will work. On the Pulse Policy

Secure Series device TTLS-PAP is enabled by default. You can enable PAP if

required, but this is the least secure protocol.

Some LDAP servers allow you to store the passwords in cleartext or

reversibly encrypted. In this situation, all of the CHAP family protocols will

work.

The following table summarizes additional usage guidelines.

Table 4: Authentication Protocol Set Configuration Guidelines

Password Changing The protocols that support password changing on the Pulse Policy

Secure Series device include JUAC, MS-CHAP-V2 (only within a TTLS

tunnel),

EAP-MS-CHAP-V2 (only within a PEAP or TTLS tunnel), and EAP-GTC.

If you use CHAP, PAP or MS-CHAP for a Layer 2 connection (for example,

with an Active Directory Server), password changing is not supported

through the Pulse Policy Secure Series device.

Password restrictions Password restrictions (for example, password length) cannot be

enforced if you use the CHAP family protocols for authentication.

Expired passwords You can direct users with expired passwords to a Web interface to access

a default VLAN to allow users to log in with a cleartext password and

change their password.

Topic Details

EAP-GTC 802.1X supplicant

Outer Inner Basis Usage recommendation

MS-CHAP-V2 -



Table 4: Authentication Protocol Set Configuration Guidelines (continued)

Using an 802.1X IP Phone with the Pulse Policy Secure Series

IP telephones that support 802.1X support EAP, either as EAP-MD-5-Challenge or

EAP-TLS, depending on the manufacturer. You can associate a realm with the default

802.1X-Phones protocol, and then use role-mapping to assign phones to a role within

the realm. The Pulse Policy Secure Series device automatically directs phones that

attempt to authenticate using the 802.1X-Phones protocol to the associated realm.

See Access Management Framework for information about configuring sign-in

policies.

If you are planning to use 802.1X IP phones on a network segment that also

accommodates switches using Web-based authentication, you will assign role-

mapping rules to ensure that phones are recognized, since a switch using MD-5

Challenge would automatically be authenticated through the same realm. For

example, Avaya phones can be recognized by the expression [0-9afA-F]*. You can

create a role-mapping rule that specifies if user = [0-9afA-F]*, then assign to a role

specific to IP phones.

Related

Documentation

Understanding 802.1X Network Access Control Deployments on page 17

Configuring Authentication Protocol Sets

You configure authentication protocols sets from the sign-in pages.

To configure an authentication protocol set:

1. In the Pulse Policy Secure Series device admin console, select Authentication >

Signing In > Authentication Protocols.

NOTE: The default 802.1X protocol set is configured to work with

EAP-TTLS or EAP-PEAP as primary (outer) authentication protocols, and with EAP-JUAC or with EAP-MSCHAP- V2 for inner authentication (if EAP-PEAP is used) and EAP-JUAC, PAP, MSCHAP- V2, EAP-MS-CHAP-V2, or EAP-GenericTokenCard (if EAP-TTLS is used).

2. To create a new protocol set, click New Authentication Protocol, or select the

check box beside the existing 802.1X protocol set and click Duplicate.

3. Enter a name, and optionally al description for the new authentication protocol

set. You select the protocol set by name when you create a sign-in policy.

4. Under Authentication Protocol, select authentication protocol(s) from the

Available Protocol list. Click Add.

Topic Details

Default protocols for OAC and Pulse The 802.1X protocol set is used by default for endpoints that connects

with OAC or Pulse. If you disable the JUAC protocol (a proprietary

protocol) on OAC or Pulse or on the Pulse Policy Secure Series device,

OAC and Pulse have only the features of a standard non-Pulse Secure

supplicant.



5. If you select EAP-PEAP as the main authentication protocol, under PEAP

select an inner authentication protocol from the Available Protocol list. Click

Add.

NOTE: If you are configuring a protocol set to work with the Windows

client and a Host Checker Statement of Health policy, you must select

the EAP-SOH protocol as the inner authentication method within a PEAP

tunnel.

6. If you select EAP-TTLS as the main authentication protocol, under TTLS select

an inner authentication protocol from the Available Protocol list. Click Add.

7. If you are using inner RADIUS proxy, do not select an inner protocol with EAP-

PEAP or EAP-TTLS.

8. Click Save Changes to save your selections. When you configure a sign-in policy,

you associate this authentication protocol set with an authentication realm. See

Access Management Framework for information about configuring realms.

Related

Documentation


Using RADIUS Proxy

In environments with many distributed users, it can be difficult or impossible to

maintain a centralized database of users. With RADIUS proxy, the Pulse Policy

Secure Series device RADIUS server can forward authentication requests from a

network access device (NAD) to an external RADIUS server. The proxy target

receives the request, performs the authentication and returns the results. The Pulse

Policy Secure Series device RADIUS server then passes the results to the NAD.

You can configure the Pulse Policy Secure Series device to proxy RADIUS inner or

outer authentication to an external RADIUS server. Proxying inner or outer

authentication gives you the flexibility to direct requests for authentication through

whatever realm is most appropriate for each user. Whether you proxy inner or outer

RADIUS authentication depends on where you want the authentication tunnel to

terminate.

RADIUS proxy can permit greater flexibility in network design and can accommodate

existing topologies. In many networks, authentication data for different workgroups is

grouped in different ways. For example, authentication groups might be configured by

department, by subsidiary, or by acquired company. You can configure the local NAD

to use the Pulse Policy Secure Series device for authentication of local endpoints,

and you can use second-tier RADIUS servers (proxy targets) to handle the different

groups.

One advantage of this setup is in the simplified configuration. The NADs and each

RADIUS server must share a secret passcode. The Pulse Policy Secure Series

device does not require NADs to communicate directly with each RADIUS server, and

second-tier RADIUS servers do not have to share a secret with every NAD in the

company. The Pulse Policy Secure Series device handles the shared secrets.



If the network components (Pulse Policy Secure Series device, authentication server,

NAD, and RADIUS server) are managed by different individuals, the local

administrators can configure authentication servers to communicate with local

RADIUS servers without the overhead of connecting each authentication server to

Pulse Policy Secure Series devices or Pulse Policy Secure Series device clusters

throughout the company.

With RADIUS proxy you can easily transition using a RADIUS-based AAA service,

eliminating the need to enter users on the Pulse Policy Secure Series device. Using

your existing RADIUS server gives you access to powerful RADIUS features that are

not supported on the Pulse Policy Secure Series device RADIUS server.

With inner proxy, the proxy target specializes in authentication, and the Pulse Policy

Secure Series device specializes in access control.

The Pulse Policy Secure Series device has local knowledge that is critical to

controlling user access to the network. The Pulse Policy Secure Series device can be

configured to determine what VLAN numbers and ACL identifiers are relevant at each

site. This data could differ on remote sites.

With outer proxy, you can use outer protocols that are not supported on the Pulse

Policy Secure Series device (for example, EAP-PEAPv1 or EAP POTP).

If the proxy target has capabilities that the Pulse Policy Secure Series device does not

(such as communicate with SQL), the Pulse Policy Secure Series device can offload

to a proxy server that can communicate with SQL.

NOTE: When RADIUS proxy is used, realm or role restrictions cannot be

enforced. Host Checker policies, Source IP restrictions, and any other

assigned limits are bypassed. Use RADIUS proxy only if no restrictions

have been applied. The exception is that session limitations can be

enforced for inner proxy. With outer proxy, no session is established.

You configure RADIUS proxy at the realm level. If the authentication server for the

realm is a RADIUS server, you can select inner proxy, outer proxy or do not proxy. Do

not proxy is selected by default. If the authentication server is not a RADIUS server,

the proxy option buttons are hidden. If an incoming RADIUS authentication or

accounting request is assigned to a realm that uses RADIUS proxy, the Pulse Policy

Secure Series device proxies the request to the external RADIUS server.

With outer proxy, all RADIUS attributes are passed from the Pulse Policy Secure

Series device RADIUS server to the NAD.

NOTE: The Pulse Policy Secure RADIUS server provides a variety of

differentiated services. For example, these services include enforcing

concurrent user session limits at the realm level. If a realm specifies user

session limits, and outer proxy is used for the realm, these limits will not be

enforced. The Pulse Policy Secure Series device does not monitor user

sessions when outer proxy is used.



With inner proxy, the NAD sends tunneled authentication requests and the Pulse

Policy Secure Series device decrypts the TLS traffic and forwards the inner traffic to

another RADIUS server, the proxy target. The Pulse Policy Secure Series device

receives the responses from the second RADIUS server, encrypts the responses

using TLS, and sends the response back to the NAD inside the tunnel. If you use

inner proxy, traffic between the Pulse Policy Secure Series device and the external

RADIUS server should be well-protected with physical security or some other means.

With a tunneled request, inner proxy allows the Pulse Policy Secure Series device to

inspect the inner traffic to obtain the username and RADIUS return attributes.

With outer proxy, the NAD sends tunneled or bare authentication requests, and the

Pulse Policy Secure Series device forwards the requests without TLS processing.

With outer proxy, the Pulse Policy Secure Series device acts as a conduit between

the NAD and the proxy target.

You cannot use outer proxy if a role-mapping rule based on usernames is being used,

because the Pulse Policy Secure Series device cannot see the username and a

session cannot be created.

If the authentication server selected for a realm is a RADIUS server, the Proxy Outer

Authentication option button controls whether outer authentication is proxied. The

Proxy Inner Authentication option button controls whether inner authentication is

proxied.

You can also select the Do not proxy option button if you do not want inner or outer

authentication to be proxied. In this case, the Pulse Policy Secure Series device

handles both inner and outer authentication. You must enable the JUAC protocol for

this option.

There are special considerations for RADIUS proxy with respect to realm selection.

See Access Management Framework for information about configuring sign-in

policies.

Related

Documentation

Task Summary: Configuring the Pulse Policy Secure Series Device as a RADIUS

Server for an 802.1X Network Access Device on page 20

Understanding RADIUS Authentication and Accounting Time Limits

All requests for authentication have a time limit. Depending on the endpoint, the

authentication protocols used, the NAD (NAD) settings, and the Host Checker policies

configured at the role and realm level, RADIUS time limits could affect the success or

failure of authentication and the performance and memory allocation of the RADIUS

server.

Table 5 on page 14 displays network events and the device or endpoint response

when the timeout is exceeded. You can use this information along with the RADIUS

Diagnostic Log and User Log as a guide for troubleshooting the Pulse Policy Secure

Series device. See Monitoring and Troubleshooting for information about using logs.



Table 5: RADIUS Event Time Limits

When the NAD

sends a single

RADIUS request to

the Pulse Policy

Secure Series device

When the NAD

receives the

RADIUS response

NAD: Sometimes

5 seconds, usually

configurable

NAD resends an

exact copy of the

RADIUS request (if

configured to do so).

RADIUS Diagnostic

Log indicates that a

duplicate was

received.

When NAD forwards

an EAP request from

the Pulse Policy


to an endpoint

When the NAD

receives an EAP

response from the

endpoint

NAD: (this may be

limited by a

configuration setting

on the NAD, or the

NAD may honor the

Session Timeout

attribute that the

Pulse Policy Secure

Series device included

in the

Access-Challenge

packet - see next row)

The Pulse Policy


user log reports

timeout while waiting

for a RADIUS

continuation request.

” “ NAD: Some NADs “

limit this. The limit is

not always

configurable

When the IC Series

device sends the first

EAP message of an

EAP exchange to the

NAD for forwarding to

the endpoint

When the IC Series

device receives the

last EAP response

IC Series device: This The IC Series device

limit was two minutes User Log reports

and has been timeout while waiting

increased to 4 for a RADIUS

minutes continuation request.

When the NAD sends When the NAD NAD: (the timeout The NAD assumes a

the first copy of a receives the RADIUS interval above) x (the communication

RADIUS request to the response maximum number of failure with the

IC Series device. retries +1) The RADIUS server. It

maximum number of might record the

retries is typically 2 or event in the log and

3 and is usually report it to the

configurable endpoint. The IC

Series device RADIUS

diagnostic log shows

turnaround times

longer than the NAD’s

limit.

Interval Starts: Interval Ends: Limited by: Effect of Timeout



Table 5: RADIUS Event Time Limits (continued)

When the Pulse

Policy Secure

Series device

finishes

authenticating OAC

using EAP-JUAC.

OAC automatically

initiates

reauthentication.

OAC: the Pulse

Policy Secure Series

device sends a time

limit equal to the

session timeout fixed

by the roles assigned

to the user minus 2

minutes

OAC automatically

initiates

reauthentication. User

intervention is

typically needed for a

SecureID card only. If

reauthentication

succeeds, the

endpoint retains

network access.

Related

Documentation




Interval Starts: Interval Ends: Limited by: Effect of Timeout

When the IC Series The NAD takes the

device sends a endpoint off the

RADIUS network unless it has

Access-Accept packet been reauthenticated.

to the NAD and the

NAD lets the endpoint

onto the network.

NAD: This may be

fixed in the NADs

configuration or

controlled by the

Session Timeout

attributes that the IC

Series device sends as

part of the

Access-Accept

packet. The

Session-Timeout

attribute is set by the

roles assigned to the

user, or by the RADIUS

attributes policy.

Endpoint loses

network connectivity.

NAD sends a RADIUS

Accounting-Stop

packet (if configured

to do so). The IC

Series device records

in the user log.


CHAPTER 2

Using the Pulse Policy Secure for 802.1X Network Access




Using Location Groups with Network Access Devices on page 20

Configuring a Location Group on page 22

Understanding the RADIUS Client Configuration on page 23

Before Configuring a RADIUS Client on page 24

Configuring a RADIUS Client on page 25

Using RADIUS Client Dictionary Files on page 26

Uploading a New RADIUS Client Dictionary on page 27

Creating a RADIUS Dictionary Based on an Existing Model on page 27

Creating RADIUS Dictionary Files on page 28

Understanding RADIUS Attributes Policies on page 30

RADIUS Attributes Policy Configuration Guidelines on page 31

Creating a RADIUS Attributes Policy on page 32

Understanding RADIUS Request Attribute Policies on page 34

Configuring a RADIUS Request Attribute Policy on page 35

Understanding RADIUS Attribute Logging on page 35

Configuring RADIUS Attribute Logging on page 36

Understanding 802.1X Network Access Control Deployments

The IEEE 802.1X protocol provides authenticated access to a LAN. This standard

applies to both wireless and wired networks. In a wireless network, the 802.1X

authentication occurs after the client has associated to an access point using an

802.11 association method. Wired networks use the 802.1X standard without any

802.11 association by connecting to a port on an 802.1X enabled switch.



With 802.1X, the user is authenticated to the network by means of user credentials,

such as a password, certificate, or a token card. The keys used for data encryption

are generated dynamically. The authentication is not performed by the NAD, but

rather by the Pulse Policy Secure Series device as the RADIUS server.

The 802.1X method uses EAP messages to perform authentication. Newer EAP

protocols can dynamically generate the WEP, TKIP, or AES keys that encrypt data

between the client and the wireless access point. Dynamically created keys are more

difficult to break than preconfigured keys because their lifetime is much shorter.

Known cryptographic attacks against WEP can be thwarted by reducing the length of

time that an encryption key remains in use. Furthermore, encryption keys generated

using EAP protocols are generated on a per-user and per-session basis. The keys

are not shared among users, as they must be with preconfigured keys or preshared

passphrases.

NOTE: 802.1X authentication is supported on OAC, Pulse, and endpoints

running non-Pulse Secure 802.1X supplicants. With non-Pulse Secure

supplicants, you cannot use an Infranet Enforcer in the configuration.

The Pulse Policy Secure Series device RADIUS server can fulfill RADIUS

authentication requests from RADIUS clients that support 802.1X. (If you are using an

external RADIUS server for authentication, you can use the Pulse Policy Secure

Series device RADIUS proxy feature.

A RADIUS client, the NAD, accepts EAPOL (EAP over LAN) connection requests

from 802.1X supplicants.

The NAD, which can be a wired switch or a wireless access point, uses the RADIUS

protocol to communicate with the Pulse Policy Secure Series device to authenticate

and authorize endpoints before allowing them access to the network.

The Pulse Policy Secure Series device RADIUS server receives requests for

authentication from the NAD and authenticates the endpoint. The Pulse Policy Secure

Series device then sends the response back to the NAD The NAD and the Pulse

Policy Secure Series device exchange messages in a series of request/response

transactions.

The NAD sends a request and expects a response from the Pulse Policy Secure

Series device. If the response does not arrive, the NAD can retry the request

periodically.

Figure 1 on page 19 illustrates how the Pulse Policy Secure Series device functions as

a RADIUS server for an 802.1X NAD within the Pulse Policy Secure solution with

OAC.


Chapter 2: Using the Pulse Policy Secure for 802.1X Network Access

Figure 1: Pulse Policy Secure Series Device as a RADIUS Server for an

802.1X Network Access Device

The endpoint connects to an 802.1X NAD. The endpoint and the Pulse Policy Secure

Series device exchange EAP messages by means of 802.1X and RADIUS through the

NAD. The EAP messages contain information about user credentials and the health of

the endpoint.

The Pulse Policy Secure Series device uses its local server or an external

authentication server to verify the user’s identity.

If the Pulse Policy Secure Series device successfully authenticates the user, the Pulse

Policy Secure Series device sends a message to the NAD to allow the endpoint

access to the network. The type of access granted depends on the user’s identity and

the health of the endpoint. For example, if the endpoint meets the requirements of all

Host Checker policies, the user can have full network access. If the endpoint does not

meet some security requirements, the user can be granted access to a remediation

server. If the endpoint is using OAC or Pulse as its 802.1X supplicant, the Pulse Policy

Secure Series device and the endpoint exchange messages as necessary throughout

a session (for example, to monitor the endpoint’s security compliance). If the endpoint

is using a non-Pulse Secure supplicant, Host Checker is not supported.

If the endpoint is using Pulse Policy Secure, and the endpoint meets the requirements

of all Host Checker policies when the user attempts to access a protected resource,

the Pulse Policy Secure Series device sends auth table entries to the Infranet Enforcer

to allow the user access to the protected resources. If the endpoint is using a non-

Pulse Secure supplicant, the Pulse Policy Secure Series device opens the network

port.

Related

Documentation





Task Summary: Configuring the Pulse Policy Secure Series Device as a RADIUS Server for an 802.1X Network Access Device

To configure the Pulse Policy Secure Series device as a RADIUS server for an

802.1X NAD, perform these tasks:

1. Create a location group by selecting UAC > Network Access > Location Group in

the admin console. A location group associates a sign-in policy with a group of

NADs.

2. Create a RADIUS client by selecting UAC > Network Access > RADIUS Client in

the admin console. A RADIUS client specifies NAD parameters such as the IP

address that enables the Pulse Policy Secure Series device to respond to the

device.

3. Optionally, create a RADIUS attribute policy by selecting UAC > Network Access >

RADIUS Attributes in the admin console. A RADIUS attribute policy associates

RADIUS return attributes such as VLAN tunnel assignment with user roles.

RADIUS return attributes determine how the endpoint is allowed to access the

network.

NOTE: To use a ScreenOS Enforcer as a RADIUS client of the Pulse

Policy Secure Series device, do not configure a RADIUS client for the

ScreenOS Enforcer.

Related

Documentation

Understanding RADIUS Authentication and Accounting Time Limits on page 13




Use Case: Using an EX Series Ethernet Switch as a RADIUS Client on page 42

Using Location Groups with Network Access Devices

Location groups let you organize or logically group NADs by associating the devices

with specific sign-in policies. Sign-in policies provide a way to define and direct

independent access control policies with the network. Location groups associate sign-

in policies with NADs.

A sign-in policy defines the realm that the NAD users can use to access the Pulse

Policy Secure Series device. When creating a sign-in policy, you associate it with the

appropriate realm. When creating a realm, you associate it with an authentication

server. Thus, by associating a location group with a sign-in policy, you can associate

a group of NADs with an authentication server along with the other realm settings,

such as an authentication policy and role-mapping.

For example, you might create location group policies to logically group the NADs in

each building at a corporate campus. You can also use location group policies to

specify a special realm for MAC address authentication.



As shown in Figure 2 on page 22, you can create two location group policies, called

Wired and Wireless, to require different levels of authentication credentials from wired

versus wireless endpoints. You might do this because you require the strictest

authentication modes for your wireless access points, while your wired networks have

an acceptable level of physical security.

In this example, each location group is associated with a different sign-in policy,

each sign-in policy uses a different realm, and each realm uses a different

authentication server.

The Wired location group for wired switches is associated with a sign-in policy

that uses an Active Directory authentication server. Users who connect to the

network through wired switches must sign in using Active Directory credentials.

For stricter authentication, the Wireless location group for wireless access points is

associated with a sign-in policy that uses an ACE authentication server. Users who

connect to the network through wireless access points must sign in using their ACE

server credentials. These credentials are a username and password that consists

of the concatenation of a PIN and the current value of an RSA SecurID hardware

token’s current value.

NOTE: With location groups, you can block Layer 2 endpoints in specific

locations from using particular authentication protocols, realms, and roles.

As an example, you can block endpoints in unsecure locations from

accessing sensitive roles. However, RADIUS clients should not be placed

in insecure locations. To ensure that RADIUS clients are not compromised

and do not violate these policies, all of the network RADIUS clients should

be securely protected.



Figure 2: Using Location Groups to Group Network Access Devices

Related

Documentation

Configuring a Location Group on page 22

Configuring a Location Group

To configure a location group on the Pulse Policy Secure Series device:

1. Create a sign-in policy to associate with the location group.

2. In the Pulse Policy Secure Series device admin console, select UAC > Network Access > Location Group.

3. On the New Location Group page, enter a name to label this location group and

optionally a l Description.

4. For Sign-in Policy, select the sign-in policy associate with the location group.

5. If this location group is for controlling an unmanageable device using MAC address

authentication, select a MAC Authentication Realm that you created from the list.

6. Click Save Changes.

Related

Documentation


Task Summary: Configuring the Pulse Policy Secure Series Device as a RADIUS Server for an 802.1X

Network Access Device on page 20



Understanding the RADIUS Client Configuration

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

deployment. It includes the following information:

RADIUS Client Configuration Overview on page 23

Sending Disconnect Requests to NADs (Dynamic Authorization Support) Using a

RADIUS Client Policy on page 24

RADIUS Client Configuration Overview

You configure RADIUS clients on the Pulse Policy Secure Series device to provide

the connection information required to allow communication with the 802.1X NAD.

When you configure a RADIUS client in the Pulse Policy Secure Series device you

must supply the following information about the device:

The IP address of the NAD

In large-scale deployments, if several NADs use the same RADIUS attributes and

have contiguous IP addresses, you can specify a group of NADs by using a

contiguous range of IP addresses instead of an IP address for each device. When

the Pulse Policy Secure Series device receives a RADIUS request that includes a

source IP address in this range, it uses the RADIUS client policy for the range to

determine the appropriate shared secret, make and model, and location group.

The shared secret used by both the Pulse Policy Secure Series device and the NAD

The make and model of the NAD, which you select from a list of devices in the Pulse

Policy Secure Series device admin console

The Pulse Policy Secure Series device supports a large number of specific NADs

by using its built-in standard RADIUS and vendor-specific, proprietary dictionary

files. You can upload new dictionaries to add new RADIUS clients. The Pulse

Policy Secure Series device uses the dictionary files to store lists of RADIUS

attributes, parse authentication requests, and generate responses.

When you select the device’s make and model in a RADIUS client policy, you are

selecting a dictionary file that contains the vendor-specific attributes (VSAs) for that

device. Whenever the Pulse Policy Secure Series device receives a RADIUS

packet from that device, it consults the dictionary file for any nonstandard attributes

that it encounters in the packet. If you do not know the make and model of a device,

you can use the standard RADIUS attributes by choosing the Standard RADIUS

setting in a RADIUS client policy.

In addition to the configuration on the Pulse Policy Secure Series device, you must

configure the Network Access Device with information about the Pulse Policy Secure

Series device, including:

The IP address of the Pulse Policy Secure Series device

The shared secret you specified in the RADIUS client policy for the device

For configuration instructions, see the documentation provided with the NAD.



You can use Network and Security Manager (NSM) to configure the Pulse Policy

Secure Series device to communicate with the Juniper Networks EX Series switch.

switch. If you use NSM, the RADIUS client is automatically created for the connection.

Sending Disconnect Requests to NADs (Dynamic Authorization Support) Using a RADIUS

Client Policy

You can configure a RADIUS client policy to send terminate session requests to

NADs that support RFC 3576. Using disconnect requests, you can terminate sessions

for OAC, Pulse, or non-Pulse Secure supplicant Layer 2 endpoints that have already

authenticated.

If you configure this option on the RADIUS client policy, you permit the Pulse Policy

Secure Series device to send unsolicited disconnect requests to the NAD. When a

user session is deleted on the Pulse Policy Secure Series device, the disconnect

messages cause the user’s session to be terminated immediately and all session

information is to be removed.

The Pulse Policy Secure Series device can also send disconnect messages upon a

role event that includes a VLAN change or a change in RADIUS attributes.

Requests are provided only for sessions that were initiated with Layer 2

authentication through a NAD that support RFC 3576, including Juniper Networks EX

Series.

Disconnect requests for switches always come from the IP address that was used for

authentication. The software automatically sends the correct IP address for Pulse

Policy Secure Series devices that are in a cluster.

You must have RADIUS accounting enabled on the NAD to allow the device to

uniquely identify a session.

The Pulse Policy Secure Series device makes a log entry for the following events:

Successful completion of a request

The NAK of a request

When a request times out

When the number of retries expires

Related

Documentation

Before Configuring a RADIUS Client on page 24



Before Configuring a RADIUS Client

Overlapping IP address ranges The address range assigned to one group of NADs in a RADIUS client

cannot overlap the address ranges assigned in another RADIUS client.

Topic Details



IP address range restrictions If an individual NAD has an IP address that falls within an address

range assigned to a group of NADs, the Pulse Policy Secure Series

device uses the RADIUS client for the individual NAD.

For example, suppose an individual NAD is configured in the NAD1

RADIUS client policy with IP address 192.168.21.55, and a group of

NADs is configured in the BLDG1 RADIUS client policy with an IP

address range of 192.168.21.50–192.168.21.60. If the Pulse Policy

Secure Series device receives a RADIUS request from 192.168.21.55, it

uses the NAD1 RADIUS client information. If the Pulse Policy Secure

Series device receives a RADIUS request from 192.168.21.56, it uses the

BLDG1 RADIUS client information.

Shared secret You must configure the NAD with the same shared secret that you enter

in the Pulse Policy Secure Series device.

If you change a shared secret, your connection is disrupted. Select a

complex password initially in accordance with your security policies.

RFC3680

Related

Documentation

If the NAD is not fully RFC compliant and does not accept RFC3680

Tunnel Attributes with tags, select - Standard RADIUS: No VLAN tags

- for Make/Model.



Configuring a RADIUS Client

To create a RADIUS client on the Pulse Policy Secure Series device:

1. If you have not already done so, configure a location group. At least one location

group is required before you can configure a RADIUS client.

2. In the Pulse Policy Secure Series device admin console, select UAC > Network Access > RADIUS Client.

3. Click New RADIUS Client.

4. On the RADIUS Client page, enter a name to label this RADIUS client. Although

you can assign any name to a RADIUS client entry, use the device's SSID or IPv4

address to avoid confusion.

RADIUS dictionary If you are not sure which make and model switch you are using or

if your device is not in the list, select - Standard RADIUS - for

Make/Model. Alternately, you can upload additional dictionaries to

add a new NAD.

IP address limitations A RADIUS client for a group of NADs cannot use a Class D,

E, or F IP

address (that is, an address greater than 223.255.255.0).

Topic Details

Starting IP address range restrictions The starting address of the address range assigned to a group of

NADs cannot be the same as the IP address of an individual NAD.

The starting address of the address range assigned to a group of

NADs cannot be the same as the IP address of an individual NAD.



5. For (Optional) Description, enter a description.

6. For IP Address, enter the IP address of the NAD. 7. (Optional) For IP Address Range, enter the number of IP addresses in the IP

address range for the NADs, starting with the address you specified for IP

Address. You can specify a range up to a maximum of 32,768 addresses.

8. For Shared Secret, enter the RADIUS shared secret. A RADIUS shared secret is a

case-sensitive password used to validate communications between the Pulse Policy

Secure Series device and NAD. The Pulse Policy Secure Series device supports

shared secrets of up to 127 alphanumeric characters, including spaces and the

following special characters:

~!@#$%^&*()_+|\=-‘{}[]:”’;<>?/.,

9. For Make/Model, select the make and model of the NAD. The make/model

selection tells the Pulse Policy Secure Series device which dictionary of RADIUS

attributes to use when communicating with this client.

10. For Location Group, select the location group to use with this NAD.

11. Select the Support Disconnect Messages check box to enable disconnect messages.

If this check box is selected, a disconnect request is sent to the NAD any time a

session is deleted on the Pulse Policy Secure Series device. This feature is not

supported on every manufacturer’s NAD. Consult the manufacturer for details.

a. (Optional) Enter a new Dynamic Authorization Port (the default port is 3799).

Some switches use a different default port.


Related

Documentation



Associating an Infranet Enforcer with the Access Control Service RADIUS Server on

page 45

Using RADIUS Client Dictionary Files

The Pulse Policy Secure Series device uses dictionary files to store lists of RADIUS

attributes. The Pulse Policy Secure Series device uses these dictionaries to parse

authentication and accounting requests and to generate responses.

The main dictionary file (radius.dct) lists attributes defined by the RADIUS standard.

In addition to the standard attributes, many NADs use Vendor-Specific Attributes

(VSAs) to complete a connection. The Pulse Policy Secure Series device supports a

large number of specific NADs by providing vendor-specific, proprietary dictionary

files.

During configuration of an Pulse Policy Secure Series device, when you make a

selection in the RADIUS Client Make/Model field, you are telling the server which

dictionary file contains the VSAs for this client device. Thereafter, whenever the

server receives a RADIUS packet from this client device, it can consult this dictionary

file for any nonstandard attributes that it encounters in the packet. Standard RADIUS

attributes are always defined by the radius.dct file.



You can display all of the built-in RADIUS dictionaries by selecting UAC > Network

Access

> RADIUS Dictionary on the Pulse Policy Secure Series device. You can upload new

dictionaries to define makes and models that are not preconfigured on the Pulse

Policy Secure Series device, and you can copy and modify existing dictionaries.

Related

Documentation



Creating a RADIUS Dictionary Based on an Existing Model on page 27

Uploading a New RADIUS Client Dictionary

To upload a new RADIUS client dictionary to the Pulse Policy Secure Series device:

1. In the admin console, select UAC > Network Access > RADIUS Dictionary to

display the preconfigured dictionaries and their associated vendors.

2. Click New RADIUS dictionary.

3. Enter a Name and optionally a description for the new dictionary.

4. Use the Browse button to search for the dictionary file (.dct) on a local or

connected drive, then click Save Changes. The uploaded dictionary is displayed

on the main RADIUS Dictionary page, and in the Make/Model list on the RADIUS

Client page.


NOTE:

You can only remove dictionaries that are not associated with a vendor.

You can download any dictionary from the list, including preinstalled

dictionaries. You can modify the downloaded dictionary and then upload it as

a new make/model.

Related

Documentation


Creating a RADIUS Dictionary Based on an Existing Model

To create a new RADIUS dictionary based on an existing manufacturer’s model:

1. In the admin console, select UAC > Network Access > RADIUS Dictionary to

display the listing of preconfigured dictionaries on the Pulse Policy Secure Series

device and their associated vendors.

2. Select the dictionary to copy.

3. Click the .dct file to download the existing dictionary.

4. Modify the downloaded .dct file and rename the file.

5. Select UAC > Network Access > RADIUS Dictionary and click New RADIUS Dictionary.



6. Browse for the file you have modified, and enter a new name and optional

description for the new dictionary.

7. Click Save Changes to upload the modified.dct file. The modified file is displayed

on the RADIUS Dictionary page. Note that there is no vendor associated with the

new dictionary.

8. Select UAC > Network Access RADIUS Vendor and click New RADIUS Vendor.

9. Enter a new name and optional description for the new RADIUS vendor.

10. Select the new dictionary you created from the list.

11. Click Save Changes. The new vendor and the associated dictionary will appear on

the RADIUS Vendor page.

Related

Documentation



Creating RADIUS Dictionary Files

The dictionary format is derived from the RADIUS 5 specification (July 1996).

This section contains dictionary translations for parsing requests and generating

responses. All transactions are composed of Attribute/Value Pairs. The value of each

attribute is specified as one of these valid data types shown in Table 6 on page 28.

Table 6: Valid Data Types

hexadecimal Hexadecimal string

string 0-254 octets (includes null terminator)

ipv6addr 16 octets in network byte order (per RFC-3162)

ipv6interface 8 octets in network byte order (per RFC-3162)

ipaddr-pool IP address selected from an IP address pool

ipaddr 4 octets in network byte order

ipv6prefix 2-18 octets in network byte order (per RFC-3162)

stringnz 0-254 octets (without null terminator)

hex1, hex4 1- or 4-byte hexadecimal number

Data Description



Table 6: Valid Data Types (continued)

integer 32-bit value in big endian order (high byte first)

time 32-bit value in big endian order; seconds since 00:00:00 GMT, Jan. 1, 1970

All attribute names and value names in the supplied radius.dct dictionary are derived

from the RADIUS specification by replacing all nonalphanumeric characters with

dashes (-).

The following dictionary format provides a mechanism for including secondary

dictionaries from the text of a primary dictionary. For example, only the attribute/value

definitions that differ from the RADIUS specification need to be listed in a primary

dictionary for a vendor specific implementation. Definitions for the attribute/values that

are common

to both are brought in by including the radius.dct dictionary anywhere within the

vendor dictionary.

The following rules apply to the creation and use of dictionaries:

All comments begin with a pound sign (#) in column 0 OR appear on a attribute

or value line with <white space>#<white space> as the Mandatory delimiter

between dictionary data and comment text. (This is a simple parser)

Include another dictionary file with an at sign (@). The (@) character must be in

column 0.

All attribute and attribute value names and numeric codes must be unique within a

single dictionary. Conflicts between dictionaries are resolved according to the

following rules:

Attributes and values have precedence over any that are parsed later, and parsing

is depth first.

For example, to override a baseline attribute, create a file with that attribute in it, followed by an include of the baseline file. Because the baseline file is parsed later than the desired override, the baseline file is ignored.

When two secondary dictionary definitions of an attribute or value conflict, the

earlier include takes precedence.

Other than include files, there are two meaningful line entry formats in a dictionary -

one for attributes and one for attribute values.

ATTRIBUTE_KEY ATTRIBUTE_NAME ATTRIBUTE_CODE DATA_TYPE FLAGS

[COMMENT_DELIMITER COMMENT_TEXT]

int1, int4 1- or 4-byte decimal number (integer is equivalent to int4)

Data Description

ipxaddr-pool IPX network number selected from an IPX address pool



VALUE_KEY ATTRIBUTE_NAME VALUE_NAME VALUE_CODE [COMMENT_DELIMITER

COMMENT_TEXT]

The legend for the last column of an attribute entry should be:

'c' indicates a SINGLE value attribute that is a candidate for inclusion in a

user's checklist.

'C' indicates a MULTI value attribute that is a candidate for inclusion in a user's

checklist.

'r' indicates a SINGLE value attribute that is a candidate for inclusion in a

user's reply list.

'R' indicates a MULTI valued attribute that is a candidate for inclusion in a user's

reply list.

'o','O' ordered attribute, some attributes (such as Reply-Message) might

need to be presented in a particular order to make sense.

NOTE:

The absence of {C,c,R,r} flags indicates an item that is neither a reply

nor a check list item (such as State, Proxy-State).

All FLAG characters on a given attribute line must be clustered

together to parse properly. No white space is allowed between

individual characters.

Related

Documentation


Understanding RADIUS Attributes Policies

You can configure RADIUS attributes policies on the Pulse Policy Secure Series device to

send return list attributes to an 802.1X NAD. For example, you can specify which VLAN

endpoints must be used to access the network. You can also configure other functions on a

NAD's port based on the role assigned to the user who is currently using that port. For

example, a particular switch might let you use return list attributes to configure Quality-of-

Service (QoS) functions (Bandwidth or Priority) on the device's port based on the current

user's role.

A return list is a set of attributes that the Pulse Policy Secure Series device returns to the

NAD after authentication. The return list usually provides additional parameters that the

NAD needs to complete the connection. Return list attributes are authorization

configuration parameters.

The specific attributes in each RADIUS packet depend upon the NAD or RADIUS server

that sent the packet. Different kinds of NADs may require different attributes to control their

behavior.

In the RADIUS attributes policy, you can select RADIUS attributes by name from a

predefined list. For each attribute, you specify values using strings or numbers.

By default, the Pulse Policy Secure Series device sends a session timeout value on all

RADIUS accepts that is equal to the timeout value of the configured session length. You

can bypass the default timeout.



If you do not want to either assign endpoints to a VLAN or, return any RADIUS attributes,

select the Open Port option. With this check box selected, the Pulse Policy Secure Series

device will not return any RADIUS attributes.

Related

Documentation






Using RADIUS Attributes in Access Policies on page 39

RADIUS Attributes Policy Configuration Guidelines

Network access device and RADIUS attributes Be sure to select the correct make and model of the NAD. During

authentication, the Pulse Policy Secure Series device filters the

return list based on the dictionary for the NAD that sent the

authentication request. The Pulse Policy Secure Series device

omits any return list attribute that is not valid for the device.

Matching the policy

Related

Documentation

The RADIUS return attributes are based on the first RADIUS

attributes policy that matches both the location group of the NAD and

the roles assigned to the user.






Dictionaries You can return RADIUS attributes that are in the installed dictionaries or in dictionaries you have uploaded to the IC Series device.

Topic Details



Creating a RADIUS Attributes Policy

Before you configure a RADIUS attributes policy, verify the following configuration on the

NADs you want to use with the Pulse Policy Secure Series device:

The NAD supports RADIUS-based, dynamic VLAN assignment if the VLAN check box

is selected.

The ports are 802.1X enabled.

The VLAN IDs you want to use in the Pulse Policy Secure Series device RADIUS

VLAN policies are configured on the NADs if the VLAN check box is selected.

The endpoints are able to obtain an IP address from a DHCP server that is in the VLAN

you are using.

Any modifications to the RADIUS attributes page causes endpoints with sessions

associated with the attributes policy to re-connect. We recommend that you schedule any

changes at a time when endpoints are not affected.

To configure a RADIUS attributes policy:

1. In the admin console, select UAC > Network Access > RADIUS Attributes.

2. Click New Policy.

3. On the New Policy page:

a. For Name, enter a name to label this policy.

b. (Optional) For Description, enter al description for the policy.

4. Under Location Group, select the location groups to which you want to apply

this policy, and click Add. To apply the policy to all location groups, do not add

any location groups and use the default setting (all) listed in the Selected

Location Groups list.

5. Under RADIUS Attributes, select from the following options:

Open Port— Check this option if you do not want to assign endpoints to a

VLAN or return any RADIUS attributes. Selecting this check box disables all

other RADIUS Attributes options.

VLAN—Select this option to configure VLAN assignment according to RFC

3580 by returning the RADIUS tunnel attributes to the NAD. Specify the existing

VLAN ID on the network infrastructure that you want to use for the role(s) to

which this policy applies. Selecting this option is equivalent to manually

specifying the three RFC 3580 RADIUS tunnel attributes in the Return Attribute

section.

Return Attribute—Select this option to specify the return attributes you want

sent to the NAD, select Return Attribute and then do the following:

From the Attribute list, select the return attribute to send. For User Attribute,

enter the return user attribute to be matched against the user attributes

obtained from the authentication server. For Value, enter the value for the

selected attribute. Then click Add.

You can specify multiple return attributes and values for this policy.

To add an attribute, select a new attribute from the list and enter the

appropriate value. To change an attribute value, click the value, enter the

appropriate value, and then click the check mark icon next to the value.



To rearrange the order in which you want to send the return attributes, select

the check box next to the attribute name and then click the up or down arrow.

To delete an attribute, select the check box next to the attribute name. Then

click Delete.

Add Session-Timeout attribute with value equal to the session lifetime—Clear

this check box to prevent the Pulse Policy Secure Series device from sending a

session timeout value equal to the timeout value of the configured session

length on all RADIUS accepts. This allows you to set the re-authentication timer

statically on the switch port, if required.

If you are using MAC address authentication (with an unmanageable device) and

you select the Add Session-Timeout attribute with value equal to the session

lifetime, the session timeout value that the Pulse Policy Secure Series device

sends is 60 seconds less than what is configured in Max session length for the

role that is configured for MAC authentication.

If you select this check box, you can select Add Termination-Action attribute with

value equal 1. The termination-action attribute indicates what action should be

taken when the session ends. The value 1 indicates that the session should

attempt re-authentication.

6. For Interface, specify the Pulse Policy Secure Series device network interface that

endpoints affected by this policy to use to connect to the Pulse Policy Secure

Series device:

Automatic (use configured VLANs)—Select this option to use VLAN tagging.

You must also connect the Pulse Policy Secure Series device internal

interface to the trunk port on a VLAN-enabled switch that sees all of the

VLAN traffic.

Internal— Select this option if the endpoints using this RADIUS attributes policy

should use the IP address of the Pulse Policy Secure Series device's internal

interface to communicate with the Pulse Policy Secure Series device.

External—Select this option if the endpoints on the configured VLAN should

use the IP address of the Pulse Policy Secure Series device's external interface

to communicate with the Pulse Policy Secure Series device.

7. In the Roles section, specify:

Policy applies to ALL roles—To apply this policy to all users.

Policy applies to SELECTED roles—To apply this policy only to users who are

mapped to roles in the Selected roles list. Be sure to add roles to this list from

the Available roles list.

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

policy to all users except for those who map to the roles in the Selected roles

list. Be sure to add roles to this list from the Available roles list.




Related

Documentation





Understanding RADIUS Request Attribute Policies

You can configure RADIUS request attribute policies to enforce the action of processing

authentication requests based on information in the RADIUS packet before a connection

can be authenticated. You assign RADIUS request attribute policies as a realm

restriction.

Any authentication request that comes from a realm with attribute policy requirements

must send the RADIUS attributes specified in the policy, otherwise the authentication

request is not granted. If multiple rules are configured in a policy, the user must pass all

of the rules, otherwise authentication fails.

When a user authentication fails because it did not meet the requirements specified in

the RADIUS request attribute policy, a user event log message is displayed that includes

information about which policies the user met or failed. Debug logs allow the

administrator to determine that a user met the policies, or indicate that the user failed a

RADIUS return attribute policy.

RADIUS request attribute policies consist of rules. Each rule consists of one attribute and

some number of values. The type of value depends on the type of rule chosen. For

example, if you select a rule with the User-Name attribute, you enter a string.

NOTE: Each request page includes guidance on what type of value is

expected.

If you select a rule with the Login-IP-Host attribute, you enter an IP address and an

optional netmask. The default netmask value is 255.255.255.255. The value of the

attribute must fall within the specified IP address and netmask to pass the policy.

For attributes that require an integer value, you can use a wildcard as the value to ensure

that these attributes exist in the request.

Wildcard values include the following:

For a string: an asterisk (*) and (?) (The * matches multiple characters and the

? matches a single character.)

For an integer: the * matches any value for the attribute.

For a hexadecimal type: Any hexadecimal value, or the * to match any value for

the attribute.



Related

Documentation

Configuring a RADIUS Request Attribute Policy on page 35




Configuring a RADIUS Request Attribute Policy

To configure RADIUS request attribute policies:

1. In the Pulse Policy Secure Series device admin console, select UAC > Network Access > RADIUS Attributes

> Request Attributes.

2. Click New.

3. Enter a name in the Policy Name box. You select the policy when you create a realm.

4. Optionally, describe the policy in the Description box.

5. Select a Rule Setting (attribute) from the list, then click Add. A new page opens that

allows you to enter values for the attribute type you selected.

6. Add values that are specific to the type of RADIUS attribute you have selected, then

click Add. You can add any number of values to the list. To delete a value, select the

check box and click Delete. Any RADIUS authentication request must contain one

of the values that you define.

For some rule types a list is displayed. Select the appropriate value from the list.

7. After you populat the list, click Save Changes.

You can add more RADIUS attribute requirements by adding new rule settings.

8. Click Save Changes. The policy is now visible on the User Realms > User > Authentication

Policy > RADIUS Request Policies page. Populate the Selected RADIUS Request

Attribute Policies list with the policies you created.

Related

Documentation



Understanding RADIUS Attribute Logging

You can configure the Pulse Policy Secure Series device to enable or disable

authentication reporting for RADIUS authentication events. With this feature, you can

obtain a granular record of authentication attempts using configurable, detailed

authentication reports.

You can selectively choose events to record based on both successful and unsuccessful

authentication attempts. If you select an attribute to be recorded and the value is not

present in the authentication request/response, an entry is made in the debug log and in

the RADIUS log.



You can also specify accounting log messages.

The byte limit for log entries is 2048. If a message exceeds this limit, the last value is

trimmed to fall within the maximum, and an entry is made in the debug and RADIUS logs.

Related

Documentation


Configuring RADIUS Attribute Logging

To configure RADIUS attribute logging:

1. In the Pulse Policy Secure Series device admin console, select UAC > Network Access >

RADIUS Attributes

> Attribute Logging.

2. Select the Authentication Success Log Message and Authentication Reject Log Message

check boxes.

3. To specify accounting log messages, select the Accounting Log Message check box.

4. Select Available attributes from the lists, and click Add to populate the Selected

Attributes lists.

5. Select Save Changes.

Related

Documentation



PART 2

Using the Pulse Policy Secure RADIUS Server

RADIUS Examples and Use Cases on page 39


CHAPTER 3

RADIUS Examples and Use Cases


Use Case: Using an EX Series Ethernet Switch as a RADIUS Client on page 42

Associating an Infranet Enforcer with the Access Control Service RADIUS

Server on page 45

Use Case: Using a Non-Pulse Secure 802.1X Supplicant on page 46

Before Configuring a Non-Pulse Secure Supplicant on page 47

Configuring a Non-Pulse Secure Networks Supplicant for 802.1X on page 48

Configuring Access to Switches and Access Points from a Browser on page 49

Authenticating Users with Non-Tunneled Protocols on page 49

Using a MAC Authentication Server on page 50

Use Case: Using an External LDAP Server for MAC Address Authentication on page 53

Configuring Network Access Policies for Unmanageable Devices on page 55

Using RADIUS Attributes in Access Policies

This topic describes how to use the RADIUS attributes options in RADIUS attributes

policies. It describes the following use cases:

Use Case 1: Configuring VLAN Assignment by Returning RADIUS Tunnel

Attributes on page 39

Use Case 2: Configuring VLAN Assignment Along with Other Attributes on page 40

Use Case 3: Configuring VLAN Assignment or Policies by using the Filter-ID Return

Attribute on page 40

Use Case 4: Configuring VLAN Assignment in a Heterogeneous Environment on page 40

Use Case 5: Using RADIUS Attributes with OAC to Avoid Disconnecting Concurrent

Network Connections on page 41

Use Case 1: Configuring VLAN Assignment by Returning RADIUS Tunnel Attributes

This use case describes how to configure VLAN assignment on NADs by returning

RADIUS tunnel attributes according to RFC 3580.

1. Select UAC > Network Access > RADIUS Attributes select VLAN.

2. Specify a VLAN ID.



Use Case 2: Configuring VLAN Assignment Along with Other Attributes

This use case describes how to configure VLAN assignment and other features on

NADs by returning RADIUS tunnel attributes in addition to returning other attributes.

1. On the UAC > Network Access > RADIUS Attributes, select VLAN.

2. Specify a VLAN ID.

3. Select Return Attribute.

4. Select the attribute you want to return from the Attribute list.

5. For Value, specify an attribute value.

Use Case 3: Configuring VLAN Assignment or Policies by using the Filter-ID Return Attribute

This use case describes how to configure VLAN assignment or other policies on NADs

by using the Filter-ID return attribute.

1. Select UAC > Network Access > RADIUS Attributes > Return Attribute.

2. Select Filter-ID from the Attribute list.

3. For value, specify the policy name.

4. Configure the filter on the NAD.

Use Case 4: Configuring VLAN Assignment in a Heterogeneous Environment

For this use case, you must have a heterogeneous network environment that includes

NADs from a variety of vendors. For example, you might have one type of switch that

supports RADIUS tunnel attributes only, a second type of switch that supports the

Filter-ID return attribute only, and a third type of switch that supports both.

1. Select UAC > Network Access > Location Group and create a location group policy for

each type of NAD.

a. Create a location group policy for switches that support RADIUS tunnel attributes

only.

b. Create a second location group policy for switches that support the Filter-ID return

attribute only.

c. Create a third location group policy for switches that support both RADIUS tunnel

attributes and the Filter-ID return attribute.

2. Select UAC > Network Access > RADIUS Client. Then, follow these steps to create a

RADIUS client policy for each type of NAD and associate each RADIUS client policy

with the appropriate location group.

a. Create a RADIUS client policy and specify a make/model for Make/Model that

supports the RADIUS tunnel attributes. Associate this policy with the location group

policy for switches that support RADIUS tunnel attributes only.


Chapter 3: RADIUS Examples and Use Cases

b. Create a second RADIUS client policy and specify a make/model that supports

the Filter-ID return attribute. Associate this policy with the location group policy

for switches that support the Filter-ID return attribute only.

c. Create a third RADIUS client policy and specify a make/model that supports the

both RADIUS tunnel attributes and the Filter-ID return attribute. Associate this

policy with the location group policy for switches that support both RADIUS tunnel

attributes and the Filter-ID return attribute.

3. Select UAC > Network Access > RADIUS Attributes. Then, follow these steps:

a. Create a RADIUS Attributes policy that specifies only the VLAN option and a value

for VLAN ID. Associate this policy with the location group policy for switches that

support RADIUS tunnel attributes only.

b. Create a second RADIUS Attributes policy that specifies only the Filter-ID option

from the Attribute list and a policy name for Value. Associate this policy with the

location group policy for switches that support the Filter-ID return attribute only.

c. Create a third RADIUS Attributes policy that specifies both the VLAN option and

a value for VLAN ID, and the Filter-ID option with a policy name for Value. Associate

this policy with the location group policy for switches that support both RADIUS

tunnel attributes and the Filter-ID return attribute.

NOTE: If all the dictionaries are correct, you do not need to create three

separate RADIUS attributes policies. The Pulse Policy Secure Series

device will strip out attributes that do not conform to the RADIUS client’s

dictionaries.

Use Case 5: Using RADIUS Attributes with OAC to Avoid Disconnecting Concurrent Network

Connections

You can configure RADIUS attributes to work with a connected switch to prevent

expired sessions from disconnecting concurrent network connections.

When an Pulse Policy Secure Series device session reaches its maximum lifetime (as

specified on the Session Options tab on the Role settings configuration page), all

access to the network through Pulse Policy Secure is terminated. If OAC is used for

access, OAC logs off the network (via EAPoL-LogOff). Any access provisioned through

the Infranet Enforcer is removed.

OAC then initiates a new session. If a new session is established, network connection

is reprovisioned. However, in most cases any TCP connections that were established

prior to the end of the Pulse Policy Secure Series device session expire and must be

re-established. For example, any remote desktop or Telnet sessions ends and the user

must restart them.

You can configure a timeout that is shorter than the Pulse Policy Secure Series device

session lifetime so that the Pulse Policy Secure Series device can periodically verify

that OAC is still operating correctly. You can configure a shorter session timeout on a

switch or wireless access point in a number of ways.



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

policies. Depending on the switch or wireless access point. You might also have to

configure a Timeout-Action RADIUS return attribute. In addition, you might have to

configure the switch or wireless access point so that it will respond to these attributes.

You can configure the switch or wireless access point with a shorter session timeout.

You must also configure the switch or wireless access point to ignore Session-Timeout

RADIUS return attributes from the Pulse Policy Secure Series device.

When the switch or wireless access point times out a session, OAC can resume the

Pulse Policy Secure Series device session by interacting in one or two ways with the

Pulse Policy Secure Series device without interrupting network access.

TTLS session resumption—OAC accesses the Pulse Policy Secure Series device

based on TLS keying material from the previous session.

DSID session resumption—The TTLS session fails to resume but the Pulse Policy

Secure Series device session is still valid. TTLS session resumption can fail if OAC is

configured for a shorter TTLS session resumption maximum than the length of the

Pulse Policy Secure session. In DSID session resumption, OAC accesses the Pulse

Policy Secure Series device using new TLS keying material, but does not create a

new Pulse Policy Secure session. You configure Session Resumption on the OAC

Tools > Options panel.

Related

Documentation




Use Case: Using an EX Series Ethernet Switch as a RADIUS Client

This topic shows how to configure the Juniper Networks EX Series switch as a RADIUS

client in an Access Control Service deployment. It includes the following information:

Hardware and Software Requirements on page 42

Topology and Overview on page 43

Configuration on page 44

Hardware and Software Requirements

Ensure the following:

JunosOS Release 9.0 or later for EX Series switches

One EX4200 switch acting as an authenticator. The ports on the authenticator serve

as a control gate that blocks all traffic to and from supplicants until users or devices

are authenticated.

The Pulse Policy Secure Series device, which acts as the authentication server with

access to credential information for users that have permission to access the network.

Before you connect the devices, be sure to do the following:



Install the switch. For more information see Installing and Connecting an EX4200

Switch.

Perform the initial switch configuration. See the Connecting and Configuring an EX

Series Switch (J-Web Procedure).

Set up basic bridging and VLAN configuration on the switch. For more

information see Example: Setting Up Basic Bridging and a VLAN for an EX

Series Switch.

Configure the Pulse Policy Secure Series device as a RADIUS server and

configure users on an authentication server.

Topology and Overview

Figure 3 on page 44 shows the EX4200 switch connected to the Pulse Policy Secure

Series device and to assorted endpoints and network devices.

Switch Settings—EX4200 access switch, 24 Gigabit Ethernet ports, 8 authenticator

ports, (ge-0/0/0 through ge-0/0/7) and 16 nonauthenticator ports (ge-0/0/8 - ge-

0/0/23).

VLAN name—default.

Pulse Policy Secure Series device Settings—IP address 10.0.0.100, connected to

switch at port ge- 0/0/10, Pulse Secure client selected as the RADIUS client.

In this example, connect the Pulse Policy Secure Series device to access port ge-

0/0/10 on the switch. The switch acts as the authenticator and forwards credentials

from the supplicant to the Pulse Policy Secure Series device. You must configure

connectivity between the EX4200 switch and the Pulse Policy Secure Series device by

specifying the IP address of the Pulse Policy Secure Series device and the shared

secret from the RADIUS client. This information is configured on the switch. For more

information, see the Junos OS System Basics Configuration Guide.



Configuration

Step-by-Step

Procedure

Figure 3: 802.1X Deployment with the EX4200 Switch

To connect the Pulse Policy Secure Series device to the switch:

1. Define the IP address of the Pulse Policy Secure Series device and configure the

shared secret.

[edit access]

user@switch# set radius-server 10.0.0.100 secret juniper

2. Configure the authentication order, making the RADIUS the first method of

authentication.

[edit access]

set profile profile1 authentication-order radius

3. Configure a list of IP addresses for authenticating the supplicant.

[edit access]

user@switch# set profile1 radius authentication-server 10.0.0.100 10.2.14.200

4. Display the results of the configuration.

user@switch> show configuration access

radius server {

10.0.0.100

port 1812;



secret "$9$qPT3ApBSrv69rvWLVb.P5"; ## SECRET-DATA

}

}

profile profile1{

authentication-order radius;

radius {

authentication-server 10.0.0.100 10.2.14.200;

}

}

}

Verification

Step-by-Step

Procedure

To confirm that the configuration is working properly:

1. Verify the connection by pinging the switch:

user@switch ping 10.0.0.100

You should receive ICMP echo responses from the Pulse Policy Secure Series device.

Related

Documentation





Associating an Infranet Enforcer with the Access Control Service RADIUS Server

If desired, you can use the Access Control Service RADIUS server for admin auth to an

Infranet Enforcer (ScreenOS or Junos OS). On the Access Control Service side, the

configuration is simple, and the RADIUS client configuration for the Infranet Enforcer is

created automatically.

To associate an Infranet Enforcer with the Access Control Service RADIUS server:

1. Configure the firewall to use the Access Control Service RADIUS server for

administrator access.

On Junos Enforcers, the commands are similar to the following example:

On ScreenOS Enforcers, the commands are similar to the following example:

2. Log into the Access Control Service admin console, and :

Authentication realm



Sign-in policy

a. Select UAC > Network Access > Location Group.

b. Click New Location Group.

c. On the New Location Group page, enter a name to label this location group policy.

d. (Optional) For Description, enter a description.

e. For Sign-in Policy, select the sign-in policy to associate with the location group.

f. Click Save Changes.

3. Associate the location group with the Infranet Enforcer:

a. Select UAC > Enforcer > Connection. In the Enforcer column, click the name of the Infranet Enforcer you want to configure.

b. Select the location group from the Location Group list.

c. Click Save Changes.

4. Create a RADIUS attribute return policy:

5. Test your configuration by attempting to log into the Infranet Enforcer as an admin user.

Use the Access Control Service event logs to help you troubleshoot unexpected results.

Related

Documentation



Use Case: Using a Non-Pulse Secure 802.1X Supplicant

You can configure 802.1X access to the Pulse Policy Secure Series device with OAC, Pulse, or

you can use a non-Pulse Secure 802.1X supplicant. OAC and Pulse are preconfigured with

standard protocols to work with the Pulse Policy Secure Series device. To use a non-Pulse

Secure supplicant you must configure the authentication protocols manually. A non-Pulse

Secure supplicant is any client that is configured without the JUAC protocol.

For example, the Microsoft Vista built-in supplicant allows you to select authentication protocols

for inner and outer authentication. To permit the client to access the Pulse Policy Secure Series

device, you choose the protocols on the endpoint, then select corresponding protocol sets on

the Pulse Policy Secure Series device, depending on the authentication server type you are

using.

Location group



You must also install a certificate on the client machine and select the certificate as a trusted

root CA. The certificate should be generated from the same CA that the Pulse Policy Secure

Series device is using for trusted client CAs.

If you configure endpoints to connect through Layer 2 with non-Pulse Secure supplicants, Layer

3 functionality of the Pulse Policy Secure Series device is not supported, and the user cannot

choose a realm or a role interactively. Configuration options like Host Checker, session limits,

and other restrictions are not applied.

For non-Pulse Secure supplicants, a username suffix can be used to select a realm in the form

user@realm. If a suffix is not used, there are additional options for specifying a realm.

Windows Vista and Windows XP Service Pack 3 supplicants are supported. If you use these

clients, you can use Statement of Health (SOH) policies in a Host Checker policy.

Related

Documentation


Task Summary: Configuring the Pulse Policy Secure Series Device as a RADIUS Server for an 802.1X Network Access Device on page 20


Configuring a Non-Pulse Secure Networks Supplicant for 802.1X on page 48

Before Configuring a Non-Pulse Secure Supplicant

Certificate installation With OAC or Pulse, when users connect with a Pulse Policy Secure

Series device that they have not connected with before, certificate

information is presented for the user to accept and trust dynamically.

With non-Pulse Secure 802.1X supplicants, you must install the

certificate before attempting to connect to the Pulse Policy Secure

Series device.

Outer proxy realms Host Checker is not downloaded to endpoints that connect with

non-Pulse Secure supplicants. If a realm or a role includes Host

Checker restrictions, only endpoints with OAC can pass the

restrictions.

Non-Pulse Secure clients cannot sign in to the role or realm.

Accounting stops You must configure the access point to send accounting stops so that

the IC Series device can log when a session ends and update the session

tables.

Realm selection at sign-in When a non- Pulse Secure supplicant attempts to connect to the IC

Series device and more than one realm is available, the user can select

a realm by adding a suffix to the outer username with @realmname. If

no suffix is present, and you have configured a sign-in policy with more

than one realm, the IC Series device searches for a realm whose

authentication server supports the authentication protocol that the

endpoint requests. For example, if CHAP is requested, the IC Series

device skips realms that use an Active Directory server.

Topic Details



Username suffixes By default, the User may specify the realm name as a username suffix

check box is not selected. If you choose this option, non- Pulse Policy

Secure endpoints access the Pulse Policy Secure Series device by

entering their credentials in the format user@realm.

Configuring a Non-Pulse Secure Networks Supplicant for 802.1X

To configure a non-Pulse Secure supplicant:

1. Configure authentication protocols on the non-Pulse Secure supplicant

according to the instructions in the vendor’s documentation.

2. Configure corresponding protocols on the Pulse Policy Secure Series device by

selecting Authentication> Signing In > Authentication Protocol Sets in the admin

console.

3. Install the certificate from the CA that the Pulse Policy Secure Series device is

using for trusted Client CAs.

4. Configure a Certificate Server by selecting Authentication > Auth. Servers.

5. Create a role for the user to access the Pulse Policy Secure Series device using a

non- Pulse Secure supplicant.

6. Create a realm for the endpoint by selecting Users > User Realms. Use role-

mapping to associate the role you created for non-Pulse Secure supplicants with

the realm. For the authentication server, select the Certificate Server you created.

7. Create a new sign-in policy by selecting Authentication > Signing In > Sign-In

Policies in the admin console. Associate the authentication protocol set you

created with the realm you created for this connection.

8. Configure a new location group by selecting UAC > Network Access > Location

Group and select the sign-in policy that you created from the Sign-in Policy list.

9. Create a new RADIUS client by selecting UAC > Network Access > RADIUS

Client and select the location group that you created from the Location Group list.

10. Configure a RADIUS attributes policy by selecting UAC > Network Access >

RADIUS Attributes and select the location group created for this connection from

the Location Group section, then select the role(s) configured for this access in

the Roles section.

11. Complete the remaining steps to configure 802.1X on the Pulse Policy Secure Series device.

Related

Documentation


Task Summary: Configuring the Pulse Policy Secure Series Device as a RADIUS Server for an 802.1X

Network Access Device on page 20

Use Case: Using a Non-Pulse Secure 802.1X Supplicant on page 46


Proxy realm sign-in If you configure a sign-in policy with multiple realms, and one of the

realms is a proxy realm, the user must append a suffix to the username

to access the proxy realm.

Topic Details



Configuring Access to Switches and Access Points from a Browser

Some switches support Web-based port authentication with CHAP, PAP, or EAP-MD5

Challenge (non-tunneled) authentication. You can configure the Pulse Policy Secure

Series device RADIUS server to support this functionality.

When a PC is connected to a port via captive portal, the PC receives an IP address from

the local DHCP server resident on the switch.

If a user browses to a properly configured switch, the switch displays an

authentication page. After the user submits the proper credentials, the switch

queries the Pulse Policy Secure Series device RADIUS server.

On successful authentication, the temporary IP address expires, and the port is opened

to the user. The PC then gets an IP address from the network DHCP server and the user

is granted access to the network.

Additionally, some switches can authenticate the administrator by querying a RADIUS

server using these protocols.

Related

Documentation



Authenticating Users with Non-Tunneled Protocols on page 49

Authenticating Users with Non-Tunneled Protocols

Follow these basic instructions to configure the Pulse Policy Secure Series device to

authenticate users through a switch using non-tunneled protocols:

1. Configure an external server or the local authentication server to include

authentication credentials for the device.

2. Create a new authentication server instance on the Pulse Policy Secure Series device by selecting Authentication > Authentication Servers.

3. Create a new role. It is not necessary to specify detailed role options.

4. Create a new realm that references the authentication server by selecting Users

> User Realms.

5. Create a new protocol set to include CHAP, PAP or EAP-MD5 Challenge by

selecting Authentication > Signing In > Authentication Protocols.

6. Create a sign-in policy by selecting Authentication > Signing In > Sign-In Policy and

specify the default sign-in page, the protocol set you have created, and the new

realm.

7. Create a location group by selecting UAC > Network Access > Location Groupand

set the sign-in policy to the sign-in policy created for CHAP authentication.



8. Configure a RADIUS client by selecting UAC > Network Access > RADIUS Client

and specify the new location group.

9. Configure the switch according to the manufacturer’s instructions.

Related

Documentation

Configuring Access to Switches and Access Points from a Browser on page 49

Using a MAC Authentication Server

This topic describes how to implement a MAC-address-based authentication policy to

the control network access of “unmanageable” devices. It includes the following

information:

About Unmanageable Devices on page 50

Configuring MAC Authentication on page 51

Third-Party Solutions on page 52

About Unmanageable Devices

Unmanageable devices are devices that cannot run OAC, Pulse, supplicants, or Web

browsers. Examples of unmanageable devices include IP phones, printers, and NAS

appliances. You can configure the Pulse Policy Secure Series device to authenticate

these unmanageable devices using MAC address authentication.

Unmanageable devices each have a unique MAC address. With MAC-based

authentication the MAC address serves as both the username and the password.

MAC address authentication is deployed at the edge of the network to provide port-

based security. MAC address authentication uses RADIUS as the method for information

exchange.

When a device connects to a switch, the switch forwards the MAC address to the Pulse

Policy Secure Series device as the login credential. The Pulse Policy Secure Series

device RADIUS server consults the authentication server (either a local database or an

external LDAP server) and allows or denies access to the device based on whether

there is a matching entry.

MAC addresses are not generally guarded as secrets, so an attacker can obtain a MAC

address and thereby pose as the device, gaining network access. For security, limit

access by creating a special VLAN for each device type.

After you direct unmanageable devices to a default VLAN, other resources in the VLAN

can access the device. For example, if a printer that is plugged into a Pulse Policy

Secure integrated switch is registered as a print server on the default VLAN, hosts that

can access that VLAN on the network can access the printer.

You can add MAC addresses manually, provision a MAC address authentication server

from an external LDAP server, or use a third-party device that can profile endpoints and

detect MAC addresses on the network.



NOTE: MAC-based authentication is not as secure as agent access or

agentless access authentication. A MAC address can be spoofed, so use

appropriate caution in granting MAC-authenticated devices access to sensitive

areas.

Configuring MAC Authentication

To allow access for unmanageable devices:

1. Configure the necessary VLANs on your internal network to accommodate the different

devices that you want to allow. On the Pulse Policy Secure Series device, you assign

devices to VLANs through the location groups that are added to RADIUS attributes

policies.

Figure 4 on page 51 shows an example network that is configured with different

phones and printers, an external LDAP server, and separate VLANS for different

devices. MAC address authentication on the Pulse Policy Secure Series device is

extremely flexible, and you can configure the network using any or all of these

components.

Figure 4: Example MAC Authentication Configuration

2. Create a MAC address authentication server, and populate the server with MAC

addresses and wildcards by selecting Authentication > Auth. Servers. Use the MAC

address for both the username and the password.



NOTE:

The Pulse Policy Secure Series device supports several formats for

MAC address credentials, including no-delimiter 003048436665,

single dash 003048-436665, multidash 00-30-48-43-66-65, and

multicolon 00:30:48:43:66:65. In the user log, entries appear in the

multicolon format.

Optionally, you can configure an external LDAP server or a third-party

appliance to monitor and classify devices on the network.

3. Create MAC address realms that reference the authentication server or LDAP server

by selecting UAC > MAC Address Realms.

4. Create location groups that reference the realms by selecting UAC > Network Access

> Location Groups.

5. Create RADIUS client policies for the switches that reference the applicable location

groups by selecting UAC > Network Access > RADIUS Client.

6. Create roles by selecting Users > Roles. Give the authentication server role-mappings

through the realm as required. You must configure a session length for the role that

is appropriate for the reauthentication interval of the switch.

Do not configure any role restrictions. Otherwise, roles cannot get assigned to devices,

and do not apply any Host Checker policies at the role or realm level.

7. Configure RADIUS attributes to include the applicable VLAN assignments by selecting

UAC > Network Access > RADIUS Attributes.

8. Configure the switch to communicate with the Pulse Policy Secure Series device for

MAC address authentication. The Pulse Policy Secure Series device supports HP

ProCurve, Cisco Catalyst, and Nortel Secure Network Access switches. You must

configure the following options on the switch:

Configure the desired ports to use the appropriate VLAN for unauthenticated

traffic.

Configure the ports to perform MAC-based RADIUS authentication.

Specify the Pulse Policy Secure Series device as the RADIUS server,

with the appropriate shared secret and IP addresses.

The HP and Cisco switches can use CHAP and EAP-MD5-Challenge protocols for MAC address authentication with the username (the MAC address) as the clear text password. By default, the Nortel switch uses PAP, with a password in the format .<MAC Address>. We recommend using PAP with the Nortel switch.

Third-Party Solutions

The Pulse Policy Secure Series device can utilize a third-party solution to supplement

MAC address identification and authentication. Some third-party appliances can detect

and categorize network objects based on MAC addresses. These appliances allow you

to arrange devices into types or profiles that serve a common functionality. You can map

specific types or profiles to one or more roles on the Pulse Policy Secure Series device.

The Pulse Policy Secure Series device uses LDAP to query the appliance for MAC

addresses of interest.



You configure the third-party device to monitor the traffic on your network and to

recognize and classify the types of devices that are on the network. The third-party

device can then serve as the LDAP interface for the Pulse Policy Secure Series device

to properly assign devices to the appropriate VLAN.

When you integrate the third-party appliance into a heterogeneous network consisting of

IP phones, printers, computer workstations, or any type of device that has a MAC

address, devices in the network are automatically enrolled in a profile type, for example

“IP Phone.” You can then configure the appliance to interoperate with the Pulse Policy

Secure Series device.

Related

Documentation

AAA Server Overview

Example: Using Endpoint Discovery and Profiling for MAC Address Authentication

Use Case: Using an External LDAP Server for MAC Address Authentication

If you are using an external LDAP server, you can configure it to interface with the Pulse

Policy Secure Series device instead of manually entering MAC addresses to the MAC

address authentication type server.

This configuration represents one example of an LDAP implementation with the Pulse

Policy Secure Series device. Refer to your vendor’s LDAP instructions for specific

details.

1. Populate your external LDAP server with MAC address entries for devices on the

network that you would like to provision through the Pulse Policy Secure Series device.

The MAC address serves as both the username and the password.

2. On the Pulse Policy Secure Series device, create an LDAP server instance using the

following information:

Name: MyLDAPAuthServer

Authentication Required

Authentication Required: Yes

Admin DN: cn=root,o=appliance

Password: ********

Finding User Entries

Base DN: o=appliance

Filter: (& (objectClass=ieee802Device) (macAddress = <USER>))

Determining Group Membership

Base DN: o=appliance

Filter: (& (objectClass=groupOfUniqueNames) (cn=<GROUPNAME>))

Member Attribute: UniqueMember

Nested Group Level: 0



2. Save the configuration by clicking Save Changes, then click the Server Catalog link.

a. Click Search.

b. Check the entries that correspond to the profiles you want to use (for example,

cn=IP Phone).

c. Click Add Selected.

3. Create a new MAC address authentication server, specifying your LDAP server

(MyLDAPAuthServer in this example) under Optional LDAP Servers on the New MAC

Address Authentication page.

Name: MACAuthServer

Under Optional LDAP Servers, add MyLDAPAuthServer.

4. Create a new MAC address realm. In the Servers section, select the following:

Name: MACAuthRealm

Authentication: MACAuthServer

Directory/Attribute: MyLDAPAuthServer

5. Create a new location group with the following details:

Name: MACAuthLocationGroup

For MAC Authentication Realm, select MACAuthRealm

6. Create a RADIUS client for the switch as follows:

Name: MACAuthRADIUSClient

For Make/Model, select the model of the switch you are using.

For Location Group, select MACAuthLocationGroup.

7. Create a new role for the network devices.

NOTE: Do not configure any role restrictions. Otherwise, roles cannot get

assigned to devices, and do not apply any Host Checker policies at the

role or realm level.

8. On the MACAuthRealm configuration page, create a role-mapping as follows:

a. Click New Rule on the Role Mapping tab.

b. Select Group membership after Rule Based on.

c. Enter the Name IPPhoneRule.

d. Click Update.

e. Under Rule: If user has any of these custom expressions..., select the group you

created in Step 3.



f. Under ...then assign these roles, add MyPhoneRole to Selected Roles.

g. Click Save Changes.

9. Create a RADIUS attributes policy.

Name: MyPhonePolicy

Location Group: MACAuthLocationGroup.

RADIUS Attributes:

VLAN: Add the VLAN number that you have allocated for IP phones from the

network.

10. Configure the switches to use MAC address LDAP authentication with the Pulse

Policy Secure Series device as a RADIUS server.

Related

Documentation


Configuring Network Access Policies for Unmanageable Devices on page 55

Configuring Network Access Policies for Unmanageable Devices

Unmanageable devices each have a unique MAC address. With MAC-based

authentication, the MAC address serves as the username. The password can be any of

the following:

the MAC address

the RADIUS shared secret

a string, such as 010010011253.00C0C1C2C3C4.0325, in which the middle component

is optional but if present is the MAC address

MAC addresses are not generally guarded as secrets, so an attacker could obtain a

MAC address and pose as the device, gaining network access. MAC-based

authentication is typically used for devices like IP phones and printers. For security,

access should be limited by creating a special VLAN for each device type.

This topic provides the following procedures for creating a MAC-address-based network

access policy:

Creating a MAC Address Realm on page 55

Configuring a Location Group for MAC Address Authentication on page 56

Configuring a RADIUS Client for MAC Address Authentication on page 57

Configuring RADIUS Attributes for MAC Address Authentication on page 57

Creating a MAC Address Realm

A realm is a grouping of authentication resources, including the authentication

server, directory server, and accounting server. A MAC address realm is a special

type of realm used only for MAC address authentication.



To configure a MAC address realm:

1. Create a MAC address authentication server. Populate the server with each device’s

MAC address, and specify the LDAP server that stores MAC addresses.

2. In the admin console, select UAC > MAC Address Realms.

3. Enter a name to label this realm and (optionally) a description.

4. Select When editing, start on the Role Mapping page if you want the Role Mapping tab

to be selected when you open the realm for editing.

5. Under Servers, specify:

The MAC Address Authentication server to use for authenticating devices that

access this realm.

A directory/attribute server to use for retrieving device attributes.

6. To limit the number of concurrent users on the realm, select the Authentication Policy

tab, then Limit the number of concurrent users and then specify limit values for the

following options:

Guaranteed minimum—You can specify any number of users between zero (0) and

the maximum number of concurrent users defined for the realm, or you can set the

number up to the maximum allowed by your license if there is no realm maximum.

Maximum(Optional) You can specify any number of concurrent users from the

minimum number you specified up to the maximum number of licensed users. If

you enter a zero (0) into the Maximum field, no users are allowed to log in to the

realm.


8. Create role-mapping rules for this realm from the Role Mapping tab. Attributes of

various device types can be used to assign roles, which can be referenced in

RADIUS attributes policies. This configuration allows you to assign devices to the

correct VLAN.

Configuring a Location Group for MAC Address Authentication

To configure a location group policy for MAC address authentication:

1. Create a sign-in policy to associate with the location group and select the default

sign-in page.

2. Create a new location group by selecting UAC > Network Access > Location Group.

3. On the New Location Group page, enter a name and an optional description.

4. For Sign-in Policy, select the sign-in policy you want to associate with the location

group.

5. Select a MAC Authentication Realm that you have already created.


After you create the MAC address authentication location group, you must create a

RADIUS client.



Configuring a RADIUS Client for MAC Address Authentication

To configure a RADIUS client policy for unmanageable devices:

1. Create a new RADIUS client.

2. For IP Address and IP Address Range, enter the IP address of the switch.

3. For Shared Secret, enter a shared secret that is common to the switch.

4. For Make/Model, select a switch that is supported for MAC Address Authentication.

5. Select the Location Group you created for MAC address authentication.


Configuring RADIUS Attributes for MAC Address Authentication

To configure a RADIUS attributes policy for unmanageable devices:

1. Create a new RADIUS attributes policy for unmanageable devices.

2. Select the location group that you created for unmanageable devices.

3. Specify the VLAN to which devices from this location group should be directed to. For

example, direct IP phones to a VLAN that contains the VoIP infrastructure.

4. Specify the interface on which the network device(s) are connected to the Pulse

Policy Secure Series device.

5. Select the role you created for MAC address authentication.


Related

Documentation



PART 3

Configuring the Pulse Policy Secure to Work with VLANs

VLANs on page 61


CHAPTER 4

VLANs

Using VLANs with the Pulse Policy Secure Series on page 61

Enabling Endpoints to Connect to VLANs behind the Pulse Policy Secure Series Device on page 62

Using VLANs with the Pulse Policy Secure Series

The Pulse Policy Secure Series device is compatible with IEEE 802.1Q VLAN tagging.

VLANs provide network segmentation. You can use RADIUS attributes to place different

users in different network segments.

When connected to a trunk port on a VLAN-enabled switch, the Pulse Policy Secure

Series device encounters traffic from all VLANs. This is useful for configuring separate

VLANs for separate classes of users or endpoints, and for making the Pulse Policy

Secure Series device accessible from all VLANs. You must define a VLAN port for each

VLAN. You assign the specific VLAN ID when defining the VLAN port.

The internal port must be assigned to the root system and must be marked as the default

VLAN. Routes to servers reachable via VLAN interfaces must have the next-hop gateway

set to the configured gateway for the VLAN interface, and must have the output port

defined as the VLAN port.

For an active/passsive clustered deployment, the root admin of an MSP network

configures all VLAN ports with at least one virtual port. The router administrator must

configure routes for the IVS Network Connect IP ranges that point to the VLAN virtual

port’s IP address as the next-hop gateway. This is required for Network Connect session

failover from an IVS in the active node to the corresponding IVS in the passive node.

Each VLAN port definition consists of:

Port Name—Must be unique across all VLAN ports that you define on the system or

cluster.

VLAN ID—An integer in the range of 1 through 4094 that uniquely identifies the VLAN.

IP Address/Netmask (only for non-802.1X deployments)—Must be an IP address or

netmask from the same network as the VLAN. VLAN IP addresses must be unique.

You cannot configure a VLAN to have the same network as the internal port. For

example, if the internal port is 10.64.4.30/16 and you configure a VLAN as

10.64.3.30/16, you might get unpredictable results and errors.

Default gateway—The IP address of the default router for the VLAN.

Other network settings—Inherited from the internal port.



When you create a new VLAN port the system creates two static routes by default:

The default route for the VLAN pointing to the default gateway.

The interface route to the directly connected network.

Related

Documentation

Creating a New VLAN Port

Enabling Endpoints to Connect to VLANs behind the Pulse Policy Secure Series Device on page 62


Enabling Endpoints to Connect to VLANs behind the Pulse Policy Secure Series Device

After an endpoint successfully accesses the Pulse Policy Secure Series device and the network, the Pulse Policy Secure Series device can continuously monitor the health status of the endpoint and apply any policy changes. To enable endpoints to connect to the Pulse Policy Secure Series device, use one of the following configurations:

If you are using more than two VLANs, connect the Pulse Policy Secure Series device

internal interface to the trunk port on a VLAN-enabled switch that sees all of the

VLAN traffic. You must also configure a RADIUS attributes policy with the Automatic

setting, which enables the Pulse Policy Secure Series device to take advantage of

VLAN tagging. When connected to a trunk port on a VLAN-enabled switch, the Pulse

Policy Secure Series device detects traffic from all VLANs. This is useful if you want

to configure separate VLANs for separate classes of users or endpoints, and you want

to make the Pulse Policy Secure Series device accessible from all VLANs.

In this configuration, you must also create VLAN ports on the Pulse Policy Secure

Series device and specify an existing VLAN ID on the network infrastructure.

You can also configure routing on the network to enable endpoints to access the

Pulse Policy Secure Series device over the network. In this case, you must configure

RADIUS attributes policies with the VLAN IDs you are using for endpoints, but you do

not need to configure any VLAN ports on the Pulse Policy Secure Series device.

Figure 5 on page 63illustrates an example of using a RADIUS attributes policy to

specify VLANs for endpoints.


Chapter 4: VLANs

Figure 5: Using a RADIUS Attributes Policy to Specify VLANs for Endpoints

Because user 1 is authenticated and the endpoint complies with Host Checker

security policies, the user is assigned a role on the Full Access VLAN that allows

full network access and access to protected resources.

Although User 2 is authenticated, the endpoint does not comply with Host Checker

security policies. The user is assigned a role on the Quarantine VLAN that only

allows access to a remediation server.

Related

Documentation

Using VLANs with the Pulse Policy Secure Series on page 61



PART 4

Index

Index on page 67


Index

EX Series Ethernet Switch and Pulse Policy Secure

Series, configuring ................................................. 44

EX Series Ethernet Switch, overview.............................. 43

Extensible Authentication Protocol (EAP)

EAP-PEAP, EAP-TTLS ............................................... 4

Symbols

802.1X overview ....................................................................... 17

802.1X supplicant, non-Pulse Secure

non-Pulse Secure supplicant, about.................. 46

802.1X task summary ..................................................... 20

802.1X, non-Pulse Secure supplicant, before

configuring .................................................................... 47

A

authentication methods ................................................ 5

authentication protocol set, sign in pages

default 802.1X IP phone ......................................... 10

authentication protocol sets, default ............................... 7

authentication protocol sets, uses and

restrictions ...................................................................... 9

authentication protocols, about ................................... 5

authentication protocols, recommended uses............ 8

authentication protocols, selecting.................................7

authentication, mutual .................................................. 6

C

Challenge Handshake Authentication Protocol

(CHAP) ........................................................................6

conventions

notice icons .…………………………………….xii

text ……………………………………………….xii

customer support ............................................................ xiii

contacting PSGSC ........................................................... xiii

D

documentation

comments on .......................................................... xiii

E

EAP Generic Token Card (EAP-GTC) .............................. 6

EAP State of Health (EAP-SOH) .................................. 6

EAP Transport Layer Security (EAP-TLS) .................... 6

EAP tunnels

tunneling protocols ................................................... 5

EAP-JUAC ................................................................................ 5

F filter-ID attribute, VLAN assignment .......................... 40

I inner RADIUS proxy ................................................................ 13

internal RADIUS server, about ........................................ 3

IP Phones

802.1X phones ............................................................. 10

J

Juniper Networks EX Series Ethernet switch, using

with the Pulse Policy Secure series ........................... 42

L location groups, about ................................................ 20

location groups, configuring ........................................... 22

M manuals

comments on ........................................................... xiii

N

network access policies for unmanageable

devices ............................................................................... 55

non-Pulse Secure supplicant for 802.1X, configuring ............................................................................................ 48

non-tunneled protocols ................................................. 49

notice icons ...................................................................... xii

O OAC, authentication method ....................................... 5

outer RADIUS proxy ................................................................ 12

P Password Authentication Protocol (PAP) with

plain-text passwords ................................................ 6

R RADIUS access policies, use cases ................................. 39

RADIUS attribute logging, about ................................... 35

RADIUS attribute logging, configuring .......................... 36

RADIUS attributes polices, creating ................................ 32

RADIUS attributes policies, about ............................ 30

RADIUS attributes policies, precautions before

configuring ......................................................................... 31



RADIUS attributes, using to avoid disconnecting

OAC concurrent connections

OAC, avoiding disconnecting concurrent

connections ............................................................... 41

RADIUS authentication and accounting, time

limits ................................................................................ 13

RADIUS client dictionary files

dictionary files ......................................................... 26

RADIUS client dictionary, duplicating and

modifying ................................................................... 27

RADIUS client dictionary, uploading ............................ 27

RADIUS client, configuring ............................................ 25

RADIUS client, overview ................................................... 23

RADIUS client, precautions before configuring .......... 24

RADIUS client, sending disconnect requests to NADs

dynamic authorization support ........................... 24

RADIUS proxy, about ........................................................... 11

RADIUS proxy, use cases ........................................................ 11

RADIUS request attribute policies, about ................... 34

RADIUS request attribute policy, configuring ............. 35

RADIUS tunnel attribute, for configuring VLAN

assignment ................................................................... 39

RADIUS, general description ........................................... 3

realm configuration for RADIUS proxy ............................. 12

S ScreenOS Enforcer as a RADIUS Client of Pulse Policy Secure Series

for 802.1X .......................................................................... 45

session-timeout attribute

RADIUS attributes ...................................................... 33

support, technical See technical support

switches, configuring access with non-tunneled

protocols .................................................................. 49

T

technical support

contacting PSGSC ........................................................... xiii

text conventions ............................................................... xii

U

unmanageable device, location group,

configuring ................................................................... 56

unmanageable device, RADIUS attributes,

configuring .................................................................... 57

unmanageable device, RADIUS client,

configuring .................................................................... 57

unmanageable devices, configuring ............................... 51

unmanageable devices, controlling and

authenticating ............................................................. 50

unmanageable devices, integration with LDAP

LDAP, using for unmanageable device MAC

address authentication ....................................... 53

unmanageable devices, integration with third-party

asset profilers ................................................................... 52

V

VLAN assignment, heterogeneous environment ..... 40

VLAN, enabling endpoints to connect ........................ 62

VLANs, using with the Pulse Policy Secure Series ... 61

Pulse Policy Secure - Juniper Networks...© 2015 by Pulse Secure, LLC. All rights reserved vii List...

Documents

Transcript of Pulse Policy Secure - Juniper Networks...© 2015 by Pulse Secure, LLC. All rights reserved vii List...