®

Junos OS

User Access and Authentication User Guide

Published
2020-03-26
 ii

Juniper Networks, Inc.

1133 Innovation Way
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net

Juniper Networks, the Juniper Networks logo, Juniper, and Junos are registered trademarks of Juniper Networks, Inc. in
the United States and other countries. All other trademarks, service marks, registered marks, or registered service marks
are the property of their respective owners.

Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right
to change, modify, transfer, or otherwise revise this publication without notice.

®
Junos OS User Access and Authentication User Guide
Copyright © 2020 Juniper Networks, Inc. All rights reserved.

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

YEAR 2000 NOTICE

Juniper Networks hardware and software products are Year 2000 compliant. Junos OS has no known time-related
limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.

END USER LICENSE AGREEMENT

The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with)
Juniper Networks software. Use of such software is subject to the terms and conditions of the End User License Agreement
(“EULA”) posted at https://support.juniper.net/support/eula/. By downloading, installing or using such software, you
agree to the terms and conditions of that EULA.
 iii

Table of Contents
About the Documentation | xxix

Documentation and Release Notes | xxix

Using the Examples in This Manual | xxix

Merging a Full Example | xxx

Merging a Snippet | xxxi

Documentation Conventions | xxxi

Documentation Feedback | xxxiv

Requesting Technical Support | xxxiv

Self-Help Online Tools and Resources | xxxv

Creating a Service Request with JTAC | xxxv

1 Login Classes and Login Settings

Junos OS Login Classes Overview | 37

Junos OS Login Classes Overview | 37

Permission Bits | 38

Denying or Allowing Individual Commands | 41

Defining Junos OS Login Classes | 41

Example: Creating Login Classes with Specific Privileges | 42

Junos OS Login Settings | 43

Configuring Junos OS to Display a System Login Announcement | 44

Configuring System Alarms to Appear Automatically Upon Login | 46

Configuring Login Tips | 46

Examples: Configuring Time-Based User Access | 47

Configuring the Timeout Value for Idle Login Sessions | 48

Login Retry Options | 49

Limiting the Number of User Login Attempts for SSH and Telnet Sessions | 50

Example: Configuring Login Retry Options | 52

 iv

2 User Accounts
Junos OS User Accounts | 57

Junos OS User Accounts Overview | 57

Junos-FIPS Crypto Officer and User Accounts Overview | 59

Crypto Officer User Configuration | 60

FIPS User Configuration | 60

Example: Configuring User Accounts | 60

Example: Configuring New Users | 61

Configuring Junos OS User Accounts by Using a Configuration Group | 68

Junos OS Administrative Roles | 71

Understanding Administrative Roles | 72

Example: Configuring Administrative Roles | 74

Configuring a Local Administrator Account | 82

Junos OS User Access Privileges | 83

Understanding Junos OS Access Privilege Levels | 84

Junos OS Login Class Permission Flags | 84

Allowing or Denying Individual Commands for Junos OS Login Classes | 88

Example: Configuring User Permissions with Access Privilege Levels | 89

Regular Expressions for Allowing and Denying Junos OS Operational Mode Commands,
Configuration Statements, and Hierarchies | 94

Understanding Regular Expressions | 94

Specifying Regular Expressions | 97

Regular Expressions Operators | 99

Regular Expression Examples | 102

Examples of Defining Access Privileges Using allow-configuration and deny-configuration

Statements | 105

Example: Using Additive Logic With Regular Expressions to Specify Access Privileges | 108

Example: Configuring User Permissions with Access Privileges for Operational Mode
Commands | 111

Example: Configuring User Permissions with Access Privileges for Configuration Statements
and Hierarchies | 126
 v

3 Passwords for User Access

Root Password | 142

Configuring the Root Password | 142

Example: Configuring a Plain-Text Password for Root Logins | 144

Example: Configuring SSH Authentication for Root Logins | 147

Recovering Root Password | 148

Recovering the Root Password on Routers | 148

Recovering the Root Password on Junos OS with Upgraded FreeBSD | 151

Recovering the Root Password for Junos OS Evolved | 154

Connecting to the Serial Port | 154

Recovering the Root Password | 156

Recovering the Root Password on Switches | 158

Plain-Text Passwords | 161

Changing the Requirements for Junos OS Plain-Text Passwords | 161

Example: Changing the Requirements for Junos OS Plain-Text Passwords | 162

Master Password for Configuration Encryption | 164

Hardening Shared Secrets in Junos OS | 165

Understanding Hardening Shared Secrets | 165

Using Trusted Platform Module to Bind Secrets on SRX Series Devices | 167

Limitations | 168

Configuring Master Encryption Password | 168

Verifying the Status of the TPM | 169

Changing the Master Encryption Password | 169

4 User Authentication
Junos OS User Authentication Overview | 172

Junos OS User Authentication Methods | 172

Configuring Local User Template Accounts for User Authentication | 173

Configuring Remote Template Accounts for User Authentication | 175

Example: Creating Template Accounts | 176

Understanding Remote Authentication Servers | 180

 vi

Local Password Authentication with Remote Authorization on TACACS+ Server | 181

Authentication Order for RADIUS, TACACS+, and Local Password | 182

Junos OS Authentication Order for RADIUS, TACACS+, and Password Authentication | 182

Using RADIUS or TACACS+ Authentication | 183

Using Local Password Authentication | 183

Order of Authentication Attempts | 184

Configuring the Junos OS Authentication Order for RADIUS, TACACS+, and Local Password
Authentication | 189

Example: Configuring Authentication Order | 191

Example: Configuring System Authentication for RADIUS, TACACS+, and Password

Authentication | 194

RADIUS Authentication | 197

Configuring RADIUS Server Authentication | 197

Why Use RADIUS | 198

Configuring RADIUS Server Details | 198

Configuring RADIUS To Use the Management Instance | 202

Example: Configuring a RADIUS Server for System Authentication | 203

Example: Configuring RADIUS Authentication | 206

Configuring RADIUS Authentication (QFX Series or OCX Series) | 208

Configuring RADIUS Server Details | 209

Configuring MS-CHAPv2 for Password-Change Support | 210

Specifying a Source Address for the Junos OS to Access External RADIUS Servers | 211

Juniper Networks Vendor-Specific RADIUS Attributes | 211

Juniper-Switching-Filter VSA Match Conditions and Actions | 215

Understanding RADIUS Accounting | 218

Configuring RADIUS System Accounting | 219

Configuring Auditing of User Events on a RADIUS Server | 219

Specifying RADIUS Server Accounting and Auditing Events | 220

Configuring RADIUS Server Accounting | 220

RADIUS over TLS (RADSEC) | 223

Configure the RADSEC Destination | 224

Configure TLS Connection Parameters | 225

Example: Simple RADSEC Configuration | 226

 vii

Monitoring Certificates | 226

Monitoring RADSEC Destinations | 227

TACACS+ Authentication | 227

Configuring TACACS+ Authentication | 228

Configuring TACACS+ Server Details | 228

Configuring TACACS+ to Use the Management Instance | 230

Specifying a Source Address for the Junos OS to Access External TACACS+ Servers | 230

Configuring the Same Authentication Service for Multiple TACACS+ Servers | 231

Configuring Juniper Networks Vendor-Specific TACACS+ Attributes | 231

Example: Configuring a TACACS+ Server for System Authentication | 232

Configuring Periodic Refresh of the TACACS+ Authorization Profile | 235

Using Regular Expressions on a RADIUS or TACACS+ Server to Allow or Deny Access to

Commands | 237

Juniper Networks Vendor-Specific TACACS+ Attributes | 240

Configuring TACACS+ System Accounting | 242

Specifying TACACS+ Auditing and Accounting Events | 243

Configuring TACACS+ Server Accounting | 243

Configuring TACACS+ To Use the Management Instance | 245

Configuring TACACS+ Accounting on a TX Matrix Router | 246

Authentication for Routing Protocols | 247

Junos OS Authentication Methods for Routing Protocols | 247

Example: Configuring the Authentication Key for BGP and IS-IS Routing Protocols | 248

Configuring BGP | 248

Configuring IS-IS | 249

Configuring the Authentication Key Update Mechanism for BGP and LDP Routing
Protocols | 250

Configuring Authentication Key Updates | 251

Configuring BGP and LDP for Authentication Key Updates | 251

5 Remote Access Management

Remote Access Overview | 254

System Services Overview | 254

Configuring Telnet Service for Remote Access to a Router or Switch | 255

Configuring FTP Service for Remote Access to the Router or Switch | 256
 viii

Configuring Finger Service for Remote Access to the Router | 257

Configuring SSH Service for Remote Access to the Router or Switch | 257

Configuring the Root Login Through SSH | 259

Configuring Incoming SFTP Connections | 260

Configuring the SSH Protocol Version | 260

Configuring the Client Alive Mechanism | 261

Configuring the SSH Fingerprint Hash Algorithm | 261

The telnet Command | 262

The ssh Command | 263

Configuring SSH Host Keys for Secure Copying of Data | 264

Configuring SSH Known Hosts | 265

Configuring Support for SCP File Transfer | 266

Updating SSH Host Key Information | 266

Configuring the SSH Service to Support Legacy Cryptography | 268

Configuring Outbound SSH Service | 270

Configuring the Device Identifier for Outbound SSH Connections | 271

Sending the Public SSH Host Key to the Outbound SSH Client | 271

Configuring Keepalive Messages for Outbound SSH Connections | 272

Configuring a New Outbound SSH Connection | 273

Configuring the Outbound SSH Client to Accept NETCONF as an Available Service | 273

Configuring Outbound SSH Clients | 273

Configuring Routing Instances for Outbound SSH Clients | 274

Configuring NETCONF-Over-SSH Connections on a Specified TCP Port | 274

Configuring Password Retry Limits for Telnet and SSH Access | 275

Example: Configuring a Filter to Block Telnet and SSH Access | 276

USB Modems for Remote Management of Security Devices | 284

USB Modem Interface Overview | 284

USB Modem Interfaces | 285

Dialer Interface Rules | 285

How the Device Initializes USB Modems | 286

USB Modem Configuration Overview | 287

Example: Configuring a USB Modem Interface | 290

Example: Configuring a Dialer Interface | 293

 ix

Example: Configuring a Dialer Interface for USB Modem Dial-In | 298

Configuring a Dial-Up Modem Connection Remotely | 300

Connecting to the Device Remotely | 302

Modifying USB Modem Initialization Commands | 302

Resetting USB Modems | 303

Secure Web Access for Remote Management | 304

Secure Web Access Overview | 304

Generating SSL Certificates for Secure Web Access (SRX Series Devices) | 305

Generating SSL Certificates to Be Used for Secure Web Access (EX Series Switch) | 306

Generating a Self-Signed SSL Certificate Automatically | 307

Manually Generating Self-Signed SSL Certificates | 307

Deleting Self-Signed Certificates (CLI Procedure) | 308

Understanding Self-Signed Certificates on EX Series Switches | 308

Manually Generating Self-Signed Certificates on Switches (CLI Procedure) | 310

Generating a Public-Private Key Pair on Switches | 310

Generating Self-Signed Certificates on Switches | 311

Example: Configuring Secure Web Access | 311

Example: Controlling Management Access on SRX Series Devices | 314

Configuration Guidelines for Securing Console Port Access | 319

Securing Console Port | 319

Securing Mini-USB Ports | 321

Configuring the Console Port Type (CLI Procedure) | 322

6 Access Control on Switches

Access Control and Authentication on Switching Devices | 326

Understanding Authentication on Switches | 326

Sample Authentication Topology | 327

802.1X Authentication | 329

MAC RADIUS Authentication | 330

Captive Portal Authentication | 331

Static MAC Bypass of Authentication | 331

 x

Fallback of Authentication Methods | 332

Understanding Access Control on Switches | 333

Understanding Authentication Session Timeout | 335

Controlling Authentication Session Timeouts (CLI Procedure) | 336

Preventing Unauthorized Access to EX Series Switches Using Unattended Mode for

U-Boot | 338

Understanding Unattended Mode for U-Boot on EX Series Switches | 338

Using Unattended Mode for U-Boot to Prevent Unauthorized Access | 340

Configuring the Boot Loader Password | 341

Configuring Unattended Mode for U-Boot | 342

Accessing the U-Boot CLI | 342

RADIUS Server Configuration for Authentication | 343

Specifying RADIUS Server Connections on Switches (CLI Procedure) | 344

Configuring MS-CHAPv2 to Provide Password-Change Support (CLI Procedure) | 345

Configuring MS-CHAPv2 for Password-Change Support | 346

Understanding Server Fail Fallback and Authentication on Switches | 348

Configuring RADIUS Server Fail Fallback (CLI Procedure) | 349

802.1X Authentication | 351

802.1X for Switches Overview | 352

How 802.1X Authentication Works | 352

802.1X Features Overview | 353

802.1X Authentication on Trunk Ports | 354

Configuring 802.1X Interface Settings (CLI Procedure) | 355

Understanding RADIUS-Initiated Changes to an Authorized User Session | 357

Disconnect Messages | 357

Change of Authorization Messages | 358

CoA Request Port Bounce | 358

Error-Cause Codes | 359

Filtering 802.1X Supplicants by Using RADIUS Server Attributes | 360

Configuring Firewall Filters on the RADIUS Server | 361

Applying a Locally Configured Firewall Filter from the RADIUS Server | 364

Example: Connecting a RADIUS Server for 802.1X to an EX Series Switch | 365

Understanding Dynamic Filters Based on RADIUS Attributes | 370

 xi

Understanding Dynamic VLAN Assignment Using RADIUS Attributes | 371

Understanding Guest VLANs for 802.1X on Switches | 372

Example: Configuring 802.1X Authentication Options When the RADIUS Server Is Unavailable
to an EX Series Switch | 373

Example: Configuring Fallback Options on EX Series Switches for EAP-TTLS Authentication

and Odyssey Access Clients | 379

Monitoring 802.1X Authentication | 385

Verifying 802.1X Authentication | 386

Troubleshooting Authentication of End Devices on EX Series Switches | 388

MAC RADIUS Authentication | 390

Configuring MAC RADIUS Authentication (CLI Procedure) | 391

Example: Configuring MAC RADIUS Authentication on an EX Series Switch | 392

802.1X and RADIUS Accounting | 399

Understanding 802.1X and RADIUS Accounting on Switches | 400

RADIUS Accounting Process | 400

Supported RADIUS Attributes | 401

Configuring 802.1X RADIUS Accounting (CLI Procedure) | 403

Example: Setting Up 802.1X for Single-Supplicant or Multiple-Supplicant Configurations

on an EX Series Switch | 405

Example: Setting Up 802.1X in Conference Rooms to Provide Internet Access to

Corporate Visitors on an EX Series Switch | 413

Interfaces Enabled for 802.1X or MAC RADIUS Authentication | 420

Example: Applying a Firewall Filter to 802.1X-Authenticated Supplicants by Using RADIUS

Server Attributes on an EX Series Switch | 420

Example: Applying Firewall Filters to Multiple Supplicants on Interfaces Enabled for 802.1X
or MAC RADIUS Authentication | 428

Example: Applying Firewall Filters to Multiple Supplicants on Interfaces Enabled for 802.1X
or MAC RADIUS Authentication on EX Series Switches with ELS Support | 435

Static MAC Bypass of 802.1X and MAC RADIUS Authentication | 441

Configuring Static MAC Bypass of 802.1X and MAC RADIUS Authentication (CLI
Procedure) | 442

Example: Configuring Static MAC Bypass of 802.1X and MAC RADIUS Authentication on an
EX Series Switch | 443
 xii

Captive Portal Authentication | 449

Example: Setting Up Captive Portal Authentication on an EX Series Switch | 449

Configuring Captive Portal Authentication (CLI Procedure) | 456

Configuring Secure Access for Captive Portal | 456

Enabling an Interface for Captive Portal | 457

Configuring Bypass of Captive Portal Authentication | 457

Designing a Captive Portal Authentication Login Page on Switches | 458

Configuring Captive Portal Authentication (CLI Procedure) on an EX Series Switche with ELS
Support | 461

Configuring Secure Access for Captive Portal | 462

Enabling an Interface for Captive Portal | 462

Configuring Bypass of Captive Portal Authentication | 463

Example: Setting Up Captive Portal Authentication on an EX Series Switch with ELS

Support | 463

Flexible Authentication Order on EX Series Switches | 469

Configuring Flexible Authentication Order | 470

Configuring EAPoL Block to Maintain an Existing Authentication Session | 472

Central Web Authentication | 474

Understanding Central Web Authentication | 474

Central Web Authentication Process | 475

Dynamic Firewall Filters for Central Web Authentication | 476

Redirect URL for Central Web Authentication | 477

Configuring Central Web Authentication | 477

Configuring Dynamic Firewall Filters for Central Web Authentication | 478

Configuring the Redirect URL for Central Web Authentication | 479

Guidelines for Configuring Central Web Authentication | 480

Centralized Access Control to Network Resources on EX Series Switches | 481

Understanding Centralized Network Access Control and EX Series Switches | 481

NAC Using Any RADIUS Server and Access Polices Defined on the Local Switch | 482

Centralized NAC Using Junos Pulse Access Control Service | 482

 xiii

Captive Portal Authentication | 483

Configuring an EX Series Switch to Use Junos Pulse Access Control Service for Network Access
Control (CLI Procedure) | 484

OBSOLETE: Configuring the EX Series Switch for Captive Portal Authentication with Junos
Pulse Access Control Service (CLI Procedure) | 488

VoIP on EX Series Switches | 489

Understanding 802.1X and VoIP on EX Series Switches | 489

Multi Domain 802.1X Authentication | 491

Example: Setting Up VoIP with 802.1X and LLDP-MED on an EX Series Switch | 492

Example: Configuring VoIP on an EX Series Switch Without Including LLDP-MED Support | 501

Example: Configuring VoIP on an EX Series Switch Without Including LLDP-MED Support | 508

Example: Configuring VoIP on an EX Series Switch Without Including 802.1X

Authentication | 514

Example: Setting Up VoIP with 802.1X and LLDP-MED on an EX Series Switch with ELS
Support | 522

7 Configuring IEEE 802.1x Port-Based Network Access Control

IEEE 802.1x Port-Based Network Access Control Overview | 534

Understanding the Administrative State of the Authenticator Port | 535

Understanding the Administrative Mode of the Authenticator Port | 535

Configuring the Authenticator | 536

Viewing the dot1x Configuration | 537

Configuring IEEE 802.1x Port-Based Network Access Control in Enhanced

8 LAN Mode
802.1X for MX Series Routers in Enhanced LAN Mode Overview | 540

How 802.1X Authentication Works | 541

802.1X Features Overview | 543

Supported Features Related to 802.1X Authentication | 543

Understanding 802.1X and LLDP and LLDP-MED on MX Series Routers in Enhanced

LAN Mode | 544

Understanding 802.1X and RADIUS Accounting on MX Series Routers in Enhanced LAN

Mode | 547

Understanding 802.1X and VoIP on MX Series Routers in Enhanced LAN Mode | 548
 xiv

Understanding Guest VLANs for 802.1X on MX Series Routers in Enhanced LAN

Mode | 551

Understanding Dynamic VLANs for 802.1X on MX Series Routers in Enhanced LAN

Mode | 551

Understanding Server Fail Fallback and Authentication on MX Series Routers in Enhanced

LAN Mode | 552

Configuring 802.1X RADIUS Accounting on MX Series Routers in Enhanced LAN

Mode | 553

Configuring 802.1X Interface Settings on MX Series Routers in Enhanced LAN Mode | 556

Configuring LLDP-MED on MX Series Routers in Enhanced LAN Mode | 558

Enabling LLDP-MED on Interfaces | 558

Configuring Location Information Advertised by the Router | 558

Configuring for Fast Start | 559

Configuring LLDP on MX Series Routers in Enhanced LAN Mode | 560

Enabling LLDP on Interfaces | 560

Adjusting LLDP Advertisement Settings | 561

Adjusting SNMP Notification Settings of LLDP Changes | 562

Specifying a Management Address for the LLDP Management TLV | 563

Configuring Server Fail Fallback on MX Series Routers in Enhanced LAN Mode | 564

Understanding Captive Portal Authentication on the MX Series Routers | 566

Limitations of Captive Portal | 566

Understanding Authentication Session Timeout on MX Series Routers | 567

Authentication Process Flow for MX Series Routers in Enhanced LAN Mode | 568

Specifying RADIUS Server Connections on an MX Series Router in Enhanced LAN

Mode | 570

Configuring Captive Portal Authentication on MX Series Routers in Enhanced LAN

Mode | 571

Configuring Secure Access for Captive Portal | 572

Enabling an Interface for Captive Portal | 573

Configuring Bypass of Captive Portal Authentication | 573

 xv

Designing a Captive Portal Authentication Login Page on an MX Series Router | 574

Configuring Static MAC Bypass of Authentication on MX Series Routers in Enhanced

LAN Mode | 577

Controlling Authentication Session Timeouts on an MX Series Router in Enhanced LAN

Mode | 578

Configuring MAC RADIUS Authentication on MX Series Routers in Enhanced LAN

Mode | 580

Example: Configuring MAC RADIUS Authentication on an MX Series Router | 582

Example: Setting Up Captive Portal Authentication on an MX Series Router | 587

Example: Connecting a RADIUS Server for 802.1X to an MX Series Router | 594

Example: Setting Up 802.1X in Conference Rooms to Provide Internet Access to

Corporate Visitors on an MX Series Router | 598

Example: Configuring Static MAC Bypass of Authentication on an MX Series Router | 602

Example: Applying Firewall Filters to Multiple Supplicants on Interfaces Enabled for

802.1X or MAC RADIUS Authentication on MX Series Routers | 607

9 Device Discovery
Device Discovery Using LLDP and LLDP-MED on Switches | 615

Understanding LLDP | 615

Configuring LLDP (CLI Procedure) | 616

Enabling LLDP on Interfaces | 617

Adjusting LLDP Advertisement Settings | 617

Adjusting SNMP Notification Settings of LLDP Changes | 618

Specifying a Management Address for the LLDP Management TLV | 619

Configuring LLDP Power Negotiation | 619

Disabling LLDP TLVs | 620

Configuring LLDP (J-Web Procedure) | 622

Understanding LLDP and LLDP-MED on EX Series Switches | 623

Benefits of LLDP and LLDP-MED | 623

LLDP and LLDP-MED Overview | 624

Supported LLDP TLVs | 624

Supported LLDP-MED TLVs | 626

 xvi

Disabling TLVs | 627

Configuring LLDP-MED (CLI Procedure) | 627

Enabling LLDP-MED on Interfaces | 627

Configuring Location Information Advertised by the Switch | 628

Configuring a Fast Start for LLDP-MED | 628

Disabling LLDP-MED TLVs | 629

NetBIOS Snooping on EX Series Switches | 631

Understanding NetBIOS Snooping | 631

What Is a NetBIOS Name? | 631

How NetBIOS Snooping Works | 632

Configuring NetBIOS Snooping (CLI Procedure) | 632

Enabling NetBIOS Snooping | 633

Disabling NetBIOS Snooping | 633

10 Domain Name Security

DNSSEC Overview | 635

Configuring the TTL Value for DNS Server Caching | 635

Example: Configuring DNSSEC | 637

Example: Configuring Secure Domains and Trusted Keys for DNSSEC | 638

Example: Configuring Keys for DNSSEC | 640

DNS Proxy Overview | 641

DNS Proxy Cache | 641

DNS Proxy with Split DNS | 642

Dynamic Domain Name System Client | 644

Configuring the Device as a DNS Proxy | 646

11 Permission Flags
access | 652

access-control | 657

admin | 658

admin-control | 664
 xvii

all-control | 665

clear | 666

configure | 767

control | 768

field | 769

firewall | 770

firewall-control | 775

floppy | 776

flow-tap | 777

flow-tap-control | 782

flow-tap-operation | 783

idp-profiler-operation | 784

interface | 784

interface-control | 790

maintenance | 791

network | 804

pgcp-session-mirroring | 807

pgcp-session-mirroring-control | 812

reset | 812

rollback | 814

routing | 814

routing-control | 825

secret | 831

secret-control | 837

security | 839
 xviii

security-control | 849

shell | 854

snmp | 855

snmp-control | 860

system | 861

system-control | 869

trace | 871

trace-control | 883

view | 890

view-configuration | 1040

12 Configuration Statements
accounting (System) | 1048

accounting-order | 1050

accounting-port (RADIUS Server) | 1051

accounting-server | 1052

address-protection | 1054

algorithm (Authentication Keychain) | 1056

archival | 1057

authentication-key-chains | 1059

authentication-order (System) | 1061

authentication-order (Authenticator) | 1063

authentication-protocol | 1066

authentication-whitelist | 1068

authenticator | 1070

boot-loader-authentication | 1073
 xix

boot-server (NTP) | 1075

boot-server (NTP) | 1076

broadcast | 1078

broadcast | 1080

broadcast-client | 1081

broadcast-client | 1082

ca-type | 1083

captive-portal | 1085

civic-based | 1087

class (Defining Login Classes) | 1089

connection-limit | 1100

custom-options | 1102

description (Authentication Keychain) | 1105

destination (Accounting) | 1106

destination (Accounting) | 1108

destination (RADSEC) | 1110

detection-time | 1112

disable (DNSSEC) | 1113

dlv | 1114

dot1x | 1115

eapol-block | 1118

enhanced-avs-max | 1120

events | 1121

failover-delay | 1122

file (System Logging) | 1123

 xx

file (System Logging) | 1125

finger | 1127

flow-tap-dtcp | 1128

ftp | 1129

host (SSH Known Hosts) | 1130

hostkey-algorithm | 1132

http (Web Management) | 1134

https (Web Management) | 1135

interface (802.1X) | 1137

interface (Captive Portal) | 1145

interface (LLDP) | 1148

interface (LLDP-MED) | 1151

interface (VoIP) | 1153

interface-description-format | 1155

interfaces (ARP) | 1157

interfaces (Security Zones) | 1158

key (Authentication Keychain) | 1159

key-chain (Security) | 1161

key-exchange | 1163

lldp | 1165

lldp-med (Ethernet Switching) | 1173

lldp-priority | 1175

local-certificate | 1176

location (LLDP-MED) | 1177

location (System) | 1179

 xxi

login | 1181

mac-radius | 1186

master-password | 1188

method | 1190

multi-domain | 1192

multicast-client | 1194

multicast-client | 1195

nas-port-extended-format | 1196

nas-port-id-format (Subscriber Management) | 1198

nas-port-type (Subscriber Management) | 1200

ntp | 1202

options (Security) | 1205

outbound-ssh | 1206

password (Login) | 1209

password-options | 1215

peer (NTP) | 1216

port (NETCONF) | 1217

port (RADIUS Server) | 1218

port (SRC Server) | 1219

port (TACACS+ Server) | 1220

profile | 1221

profilerd | 1223

provisioning-order (Diameter Applications) | 1224

proxy | 1225

radius (System) | 1226

 xxii

radius-options (System) | 1227

radius-server | 1229

radius-server | 1231

radius-server (System) | 1233

radsec | 1234

radsec-destination | 1236

rate-limit | 1237

regex-additive-logic | 1239

remote-debug-permission | 1240

retry | 1241

retry (RADIUS) | 1242

retry-options | 1243

revert-interval (Access) | 1245

root-authentication | 1246

routing-engine-profile | 1248

routing-instance | 1249

routing-instance (Accounting and Authentication) | 1250

secret (RADIUS or TACACS+ Server) | 1252

server (NTP) | 1254

server (DNS, Port, and TFTP Service) | 1256

server (RADIUS Accounting) | 1258

server (TACACS+ Accounting) | 1259

server-reject-bridge-domain | server-reject-vlan | 1260

servers | 1262

service (Service Accounting) | 1263

 xxiii

service-deployment | 1264

services (Switches) | 1265

session (Web Management) | 1266

single-connection | 1267

sip-server | 1268

source-address (NTP, RADIUS, System Logging, or TACACS+) | 1269

source-address (SRC Software) | 1270

ssh (System Services) | 1271

ssh-known-hosts | 1279

ssh-known-hosts | 1280

ssl-renegotiation | 1281

start-time (Authentication Key Transmission) | 1282

static (802.1X) | 1284

static-subscribers | 1285

statistics-service | 1286

subscriber-management-helper | 1287

tacplus | 1288

tacplus | 1289

tacplus-options | 1291

tacplus-server | 1294

telnet | 1296

tftp | 1297

timeout (System) | 1298

timeout-action (Access Control Service) | 1299

tlv-filter | 1300
 xxiv

tlv-select | 1303

traceoptions (802.1X) | 1306

traceoptions (DNS, Port, and TFTP Packet Forwarding) | 1308

traceoptions (LLDP) | 1311

traceoptions (Outbound SSH) | 1314

traceoptions (SBC Configuration Process) | 1316

traceoptions (Security) | 1318

trusted-key | 1320

uac-policy | 1321

uac-service | 1322

uac-service | 1323

unattended-boot | 1324

usb-control | 1325

user (Access) | 1326

voip | 1329

vpn (Forwarding Options) | 1330

watchdog | 1331

web-management (System Services) | 1332

web-management (System Processes) | 1336

xnm-clear-text | 1337

xnm-ssl | 1338

13 Operational Commands
clear accounting server statistics archival-transfer | 1344

clear captive-portal | 1345

clear dot1x | 1348

 xxv

clear lldp neighbors | 1351

clear lldp statistics | 1352

clear lldp neighbors | 1353

clear lldp statistics | 1354

clear network-access radsec state | 1355

clear network-access radsec statistics | 1356

clear security pki local-certificate | 1357

clear security ssh key-pair-identity | 1359

clear system login lockout | 1360

request component login | 1361

request ipsec switch | 1364

request message | 1365

request security certificate enroll (Signed) | 1367

request security certificate enroll (Unsigned) | 1369

request security key-pair | 1371

request security pki generate-key-pair | 1373

request security pki local-certificate generate-self-signed | 1375

request security ssh key-pair-identity generate | 1377

request security tpm master-encryption-password set | 1379

request system autorecovery state | 1381

request system decrypt password | 1384

request system download abort | 1386

request system download clear | 1388

request system download pause | 1389

request system download resume | 1391

 xxvi

request system download start | 1393

request system firmware upgrade | 1395

request system license update | 1397

request system reboot | 1399

request system reboot (SRX Series) | 1409

request system snapshot (Maintenance) | 1411

request system software abort in-service-upgrade (ICU) | 1415

request system software add (Maintenance) | 1417

request system software rollback (SRX Series) | 1418

request system zeroize | 1419

show accounting server statistics archival-transfer | 1421

show captive-portal authentication-failed-users | 1422

show captive-portal firewall | 1424

show captive-portal interface | 1427

show chassis routing-engine (View) | 1431

show dot1x | 1437

show dot1x accounting attribute | 1444

show dot1x authentication-failed-users | 1447

show dot1x firewall | 1449

show dot1x static-mac-address | 1451

show dot1x statistics | 1453

show ethernet-switching interface | 1456

show ethernet-switching interfaces | 1460

show firewall (View) | 1470

show lldp | 1473

 xxvii

show lldp local-information | 1481

show lldp neighbors | 1484

show lldp neighbors | 1490

show lldp remote-global-statistics | 1498

show lldp statistics | 1500

show lldp statistics | 1502

show network-access aaa statistics accounting | 1505

show network-access aaa statistics authentication | 1507

show network-access aaa statistics dynamic-requests | 1509

show network-access radsec local-certificate | 1511

show network-access radsec statistics | 1514

show network-access radsec state | 1517

show route extensive | 1520

show route instance | 1546

show security ssh key-pair-identity | 1551

show security pki local-certificate | 1553

show security tpm status | 1557

show services unified-access-control authentication-table | 1559

show services unified-access-control policies | 1562

show services unified-access-control status | 1565

show snmp | 1566

show snmp statistics | 1569

show ssl-certificates | 1577

show system autorecovery state | 1580

show system download | 1582

 xxviii

show system license (View) | 1584

show system login lockout | 1588

show system services service-deployment | 1590

show system snapshot media | 1592

show system storage partitions | 1595

show system users | 1599

ssh | 1605

telnet | 1608

test access profile | 1611

test access radius-server | 1616

 xxix

About the Documentation

IN THIS SECTION

Documentation and Release Notes | xxix

Using the Examples in This Manual | xxix

Documentation Conventions | xxxi

Documentation Feedback | xxxiv

Requesting Technical Support | xxxiv

The Junos operating system (Junos OS) enables you to configure user access and authentication features
at the [edit system] hierarchy level of the CLI. Essential user access features include login classes, user
accounts, access privilege levels, and user authentication methods. Use the topics on this page to configure
essential user access features for your system.

Documentation and Release Notes

®
To obtain the most current version of all Juniper Networks technical documentation, see the product
documentation page on the Juniper Networks website at https://www.juniper.net/documentation/.

If the information in the latest release notes differs from the information in the documentation, follow the
product Release Notes.

Juniper Networks Books publishes books by Juniper Networks engineers and subject matter experts.
These books go beyond the technical documentation to explore the nuances of network architecture,
deployment, and administration. The current list can be viewed at https://www.juniper.net/books.

Using the Examples in This Manual

If you want to use the examples in this manual, you can use the load merge or the load merge relative
command. These commands cause the software to merge the incoming configuration into the current
candidate configuration. The example does not become active until you commit the candidate configuration.
 xxx

If the example configuration contains the top level of the hierarchy (or multiple hierarchies), the example
is a full example. In this case, use the load merge command.

If the example configuration does not start at the top level of the hierarchy, the example is a snippet. In
this case, use the load merge relative command. These procedures are described in the following sections.

Merging a Full Example

To merge a full example, follow these steps:

1. From the HTML or PDF version of the manual, copy a configuration example into a text file, save the
file with a name, and copy the file to a directory on your routing platform.

For example, copy the following configuration to a file and name the file ex-script.conf. Copy the
ex-script.conf file to the /var/tmp directory on your routing platform.

system {
scripts {
commit {
file ex-script.xsl;
}
}
}
interfaces {
fxp0 {
disable;
unit 0 {
family inet {
address 10.0.0.1/24;
}
}
}
}

2. Merge the contents of the file into your routing platform configuration by issuing the load merge
configuration mode command:

[edit]
user@host# load merge /var/tmp/ex-script.conf
load complete
 xxxi

Merging a Snippet

To merge a snippet, follow these steps:

1. From the HTML or PDF version of the manual, copy a configuration snippet into a text file, save the
file with a name, and copy the file to a directory on your routing platform.

For example, copy the following snippet to a file and name the file ex-script-snippet.conf. Copy the
ex-script-snippet.conf file to the /var/tmp directory on your routing platform.

commit {
file ex-script-snippet.xsl; }

2. Move to the hierarchy level that is relevant for this snippet by issuing the following configuration mode
command:

[edit]
user@host# edit system scripts
[edit system scripts]

3. Merge the contents of the file into your routing platform configuration by issuing the load merge
relative configuration mode command:

[edit system scripts]

user@host# load merge relative /var/tmp/ex-script-snippet.conf
load complete

For more information about the load command, see CLI Explorer.

Documentation Conventions

Table 1 on page xxxii defines notice icons used in this guide.

 xxxii

Table 1: Notice Icons

Icon Meaning Description

Informational note Indicates important features or instructions.

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

damage.

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

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

Tip Indicates helpful information.

Best practice Alerts you to a recommended use or implementation.

Table 2 on page xxxii defines the text and syntax conventions used in this guide.

Table 2: Text and Syntax Conventions

Convention Description Examples

Bold text like this Represents text that you type. To enter configuration mode, type
the configure command:

user@host> configure

Fixed-width text like this Represents output that appears on user@host> show chassis alarms
the terminal screen.
No alarms currently active

Italic text like this • Introduces or emphasizes important • A policy term is a named structure
new terms. that defines match conditions and
• Identifies guide names. actions.

• Identifies RFC and Internet draft • Junos OS CLI User Guide

titles. • RFC 1997, BGP Communities
Attribute
 xxxiii

Table 2: Text and Syntax Conventions (continued)

Convention Description Examples

Italic text like this Represents variables (options for Configure the machine’s domain
which you substitute a value) in name:
commands or configuration
[edit]
statements.
root@# set system domain-name
domain-name

Text like this Represents names of configuration • To configure a stub area, include
statements, commands, files, and the stub statement at the [edit
directories; configuration hierarchy protocols ospf area area-id]
levels; or labels on routing platform hierarchy level.
components. • The console port is labeled
CONSOLE.

< > (angle brackets) Encloses optional keywords or stub <default-metric metric>;
variables.

| (pipe symbol) Indicates a choice between the broadcast | multicast

mutually exclusive keywords or
(string1 | string2 | string3)
variables on either side of the symbol.
The set of choices is often enclosed
in parentheses for clarity.

# (pound sign) Indicates a comment specified on the rsvp { # Required for dynamic MPLS
same line as the configuration only
statement to which it applies.

[ ] (square brackets) Encloses a variable for which you can community name members [
substitute one or more values. community-ids ]

Indention and braces ( { } ) Identifies a level in the configuration [edit]

hierarchy. routing-options {
static {
; (semicolon) Identifies a leaf statement at a route default {
configuration hierarchy level. nexthop address;
retain;
}
}
}

GUI Conventions
 xxxiv

Table 2: Text and Syntax Conventions (continued)

Convention Description Examples

Bold text like this Represents graphical user interface • In the Logical Interfaces box, select
(GUI) items you click or select. All Interfaces.
• To cancel the configuration, click
Cancel.

> (bold right angle bracket) Separates levels in a hierarchy of In the configuration editor hierarchy,
menu selections. select Protocols>Ospf.

Documentation Feedback

We encourage you to provide feedback so that we can improve our documentation. You can use either
of the following methods:

• Online feedback system—Click TechLibrary Feedback, on the lower right of any page on the Juniper
Networks TechLibrary site, and do one of the following:

• Click the thumbs-up icon if the information on the page was helpful to you.

• Click the thumbs-down icon if the information on the page was not helpful to you or if you have
suggestions for improvement, and use the pop-up form to provide feedback.

• E-mail—Send your comments to [email protected]. Include the document or topic name,

URL or page number, and software version (if applicable).

Requesting Technical Support

Technical product support is available through the Juniper Networks Technical Assistance Center (JTAC).
If you are a customer with an active Juniper Care or Partner Support Services support contract, or are
 xxxv

covered under warranty, and need post-sales technical support, you can access our tools and resources
online or open a case with JTAC.

• JTAC policies—For a complete understanding of our JTAC procedures and policies, review the JTAC User
Guide located at https://www.juniper.net/us/en/local/pdf/resource-guides/7100059-en.pdf.

• Product warranties—For product warranty information, visit https://www.juniper.net/support/warranty/.

• JTAC hours of operation—The JTAC centers have resources available 24 hours a day, 7 days a week,
365 days a year.

Self-Help Online Tools and Resources

For quick and easy problem resolution, Juniper Networks has designed an online self-service portal called
the Customer Support Center (CSC) that provides you with the following features:

• Find CSC offerings: https://www.juniper.net/customers/support/

• Search for known bugs: https://prsearch.juniper.net/

• Find product documentation: https://www.juniper.net/documentation/

• Find solutions and answer questions using our Knowledge Base: https://kb.juniper.net/

• Download the latest versions of software and review release notes:

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

• Search technical bulletins for relevant hardware and software notifications:

https://kb.juniper.net/InfoCenter/

• Join and participate in the Juniper Networks Community Forum:

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

• Create a service request online: https://myjuniper.juniper.net

To verify service entitlement by product serial number, use our Serial Number Entitlement (SNE) Tool:
https://entitlementsearch.juniper.net/entitlementsearch/

Creating a Service Request with JTAC

You can create a service request with JTAC on the Web or by telephone.

• Visit https://myjuniper.juniper.net.

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

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

https://support.juniper.net/support/requesting-support/.
1 CHAPTER

Login Classes and Login Settings

Junos OS Login Classes Overview | 37

Junos OS Login Settings | 43

 37

Junos OS Login Classes Overview

IN THIS SECTION

Junos OS Login Classes Overview | 37

Defining Junos OS Login Classes | 41

Example: Creating Login Classes with Specific Privileges | 42

Junos OS login classes allow you to define access privileges, permission for using CLI commands and
statements, and session idle time for each login class. You can apply a login class to an individual user
account, thereby specifying certain privileges and permissions to the user. Read this topic for more
information.

Junos OS Login Classes Overview

All users who can log in to the router or switch must be in a login class. With login classes, you define the
following:

• Access privileges that users have when they are logged in to the router or switch

• Commands and statements that users can and cannot specify

• How long a login session can be idle before it times out and the user is logged out

You can define any number of login classes and then apply one login class to an individual user account.

The Junos operating system (Junos OS) contains a few predefined login classes, which are listed in
Table 3 on page 37. The predefined login classes cannot be modified.

Table 3: Predefined System Login Classes

Login Class Permission Flag Set

operator clear, network, reset, trace, and view

read-only view

superuser or super-user all

 38

Table 3: Predefined System Login Classes (continued)

Login Class Permission Flag Set

unauthorized None

NOTE:
• You cannot modify a predefined login class name. If you issue the set command on a predefined
class name, the Junos OS appends -local to the login class name. The following message also
appears:

warning: '<class-name>' is a predefined class name; changing to '<class-name>-local'

• You cannot issue the rename or copy command on a predefined login class. Doing so results
in the following error message:

error: target '<class-name>' is a predefined class

Permission Bits

Each top-level CLI command and each configuration statement has an access privilege level associated
with it. Users can execute only those commands and configure and view only those statements for which
they have access privileges. The access privileges for each login class are defined by one or more permission
bits (see Table 4 on page 38).

Two forms for the permissions control the individual parts of the configuration:

• "Plain" form—Provides read-only capability for that permission type. An example is interface.

• Form that ends in -control—Provides read and write capability for that permission type. An example is
interface-control.

Table 4: Permission Bits for Login Classes

Permission Bit Access

admin Can view user account information in configuration mode and with the show
configuration command.

admin-control Can view user accounts and configure them (at the [edit system login] hierarchy
level).
 39

Table 4: Permission Bits for Login Classes (continued)

Permission Bit Access

access Can view the access configuration in configuration mode and with the show
configuration operational mode command.

access-control Can view and configure access information (at the [edit access] hierarchy level).

all Has all permissions.

clear Can clear (delete) information learned from the network that is stored in various
network databases (using the clear commands).

configure Can enter configuration mode (using the configure command) and commit
configurations (using the commit command).

control Can perform all control-level operations (all operations configured with the -control
permission bits).

field Reserved for field (debugging) support.

firewall Can view the firewall filter configuration in configuration mode.

firewall-control Can view and configure firewall filter information (at the [edit firewall] hierarchy
level).

floppy Can read from and write to the removable media.

interface Can view the interface configuration in configuration mode and with the show
configuration operational mode command.

interface-control Can view chassis, class of service, groups, forwarding options, and interfaces
configuration information. Can configure chassis, class of service, groups,
forwarding options, and interfaces (at the [edit] hierarchy).

maintenance Can perform system maintenance, including starting a local shell on the device
and becoming the superuser in the shell (by issuing the su root command), and
can halt and reboot the device (using the request system commands).

network Can access the network by entering the ping, ssh, telnet, and traceroute commands.

reset Can restart software processes using the restart command and can configure
whether software processes are enabled or disabled (at the [edit system processes]
hierarchy level).
 40

Table 4: Permission Bits for Login Classes (continued)

Permission Bit Access

rollback Can use the rollback command to return to a previously committed configuration
other than the most recently committed one.

routing Can view general routing, routing protocol, and routing policy configuration
information in configuration and operational modes.

routing-control Can view general routing, routing protocol, and routing policy configuration
information and configure general routing (at the [edit routing-options] hierarchy
level), routing protocols (at the [edit protocols] hierarchy level), and routing policy
(at the [edit policy-options] hierarchy level).

secret Can view passwords and other authentication keys in the configuration.

secret-control Can view passwords and other authentication keys in the configuration and can
modify them in configuration mode.

security Can view security configuration in configuration mode and with the show
configuration operational mode command.

security-control Can view and configure security information (at the [edit security] hierarchy level).

shell Can start a local shell on the device by entering the start shell command.

snmp Can view SNMP configuration information in configuration and operational modes.

snmp-control Can view SNMP configuration information and configure SNMP (at the [edit snmp]
hierarchy level).

system Can view system-level information in configuration and operational modes.

system-control Can view system-level configuration information and configure it (at the [edit
system] hierarchy level).

trace Can view trace file settings in configuration and operational modes.

trace-control Can view trace file settings and configure trace file properties.

view Can use various commands to display current system-wide, routing table, and
protocol-specific values and statistics.
 41

Denying or Allowing Individual Commands

By default, all top-level CLI commands have associated access privilege levels. Users can execute only
those commands and view only those statements for which they have access privileges. For each login
class, you can explicitly deny or allow the use of operational and configuration mode commands that are
otherwise permitted or not allowed by a permission bit.

Defining Junos OS Login Classes

Login classes allow you to define the following:

• Access privileges that users have when they are logged in to the router or switch

• Commands and statements that users can and cannot specify

• How long a login session can be idle before it times out and the user is logged out

All users who can log in to the router or switch must be in a login class. Therefore, you must define a Junos
OS login class for each user or class of users. You can define any number of login classes depending on
the types of permissions the users need.

To define a login class and its access privileges, include the class statement at the [edit system login]
hierarchy level:

[edit system login]

class class-name {
access-end hh:mm;
access-start hh:mm;
( allow-commands | allow-commands-regexps ) “regular expression 1” “regular expression 2”;
( allow-configuration | allow-configuration-regexps ) “regular expression 1” “regular expression 2”;
allow-sources [ allow-sources ... ];
allow-times [ allow-times ... ];
allowed-days [ days of the week ];
cli {
prompt prompt;
}
configuration-breadcrumbs;
confirm-commands [“regular expression or command 1” “regular expression or command 2” ...] {
confirmation-message;
}
( deny-commands | deny-commands-regexps ) [ “regular expression 1” “regular expression 2 ” ... ];
( deny-configuration | deny-configuration-regexps ) “regular expression 1” “regular expression 2 ”;
deny-sources [ deny-sources ... ];
deny-times [ deny-times ... ];
 42

idle-timeout minutes;
logical-system logical-system-name;
login-alarms;
login-script filename;
login-tip;
no-scp-server;
no-sftp-server;
permissions [ permissions ];
satellite all;
security-role (audit-administrator | crypto-administrator | ids-administrator | security-administrator);
tenant tenant;
}

Example: Creating Login Classes with Specific Privileges

Login classes are used to assign certain permissions or restrictions to groups of users, ensuring that sensitive
commands are only accessible to the appropriate users. By default, Juniper Networks devices have four
types of login classes with preset permissions: operator, read-only, superuser or super-user, and
unauthorized.

You can create new custom login classes to make different combinations of permissions that are not found
in the default login classes. The following example shows how to create three custom login classes, each
with specific privileges and timers to disconnect the class members after a period of inactivity. Inactivity
timers help protect network security by disconnecting a user from the network if the user is away from
his computer for too long, preventing potential security risks created by leaving an unattended account
logged in to a switch or router. The permissions and inactivity timers shown here are only examples and
should be customized to your organization.

The first class of users is called observation and they can only view statistics and configuration. They are
not allowed to modify any configuration. The second class of users is called operation and they can view
and modify the configuration. The third class of users is called engineering and they have unlimited access
and control. All three login classes use the same inactivity timer of 5 minutes.

[edit]
system {
login {
class observation {
idle-timeout 5;
permissions [ view ];
}
class operation {
 43

idle-timeout 5;
permissions [ admin clear configure interface interface-control network
reset routing routing-control snmp snmp-control trace-control
firewall-control rollback ];
}
class engineering {
idle-timeout 5;
permissions all;
}
}
}

RELATED DOCUMENTATION

Junos OS User Accounts | 57

Junos OS Administrative Roles | 71
Junos OS User Access Privileges | 83

Junos OS Login Settings

IN THIS SECTION

Configuring Junos OS to Display a System Login Announcement | 44

Configuring System Alarms to Appear Automatically Upon Login | 46

Configuring Login Tips | 46

Examples: Configuring Time-Based User Access | 47

Configuring the Timeout Value for Idle Login Sessions | 48

Login Retry Options | 49

Limiting the Number of User Login Attempts for SSH and Telnet Sessions | 50

Example: Configuring Login Retry Options | 52

 44

Junos OS allows you to specify various settings for the users after they have logged in. You can define
what to notify for the users after they have logged in, display system alarms, provide login tips, or specify
time-based user access, and limit the number of login attempts. Read this topic for more information.

Configuring Junos OS to Display a System Login Announcement

Sometimes you want to make announcements only to authorized users after they have logged in. For
example, you might want to announce an upcoming maintenance event.

You can format the announcement using the following special characters:

• \n—New line

• \t—Horizontal tab

• \'—Single quotation mark

• \"—Double quotation mark

• \\—Backslash

If the message text contains any spaces, enclose it in quotation marks.

By default, no login announcement is displayed.

To configure an announcement that can be seen only by authorized users:

1. Include the announcement statement in the [edit system login] configuration.

[edit system login]

user@host# set announcement text

For example:

system {
login {
announcement "\tJuly 27th 1:00 AM to 8:00\n\nPlanned Network Maintenance\n\nAFFECTED
LOCATIONS: Sunnyvale\n\nPLANNED ACTIVITY: Upgrade all 6200 switch firmware to the Enterprise
TAC recommended firmware version\n\nPURPOSE: This activity will help to minimize the impact of
unplanned power outages as well as address known issues within our currently installed firmware
version(s)\n\nWHAT TO EXPECT: During the maintenance window for your site, the office network
will not be available.\n\n";
message "\n\n\n\tTP0 - M7i - iX Router Lab\n\n\tUNAUTHORIZED USE OF THIS ROUTER\n\tIS
STRICTLY PROHIBITED!\n\n\tPlease contact \'[email protected]\' to gain\n\taccess to this equipment
if you need authorization.\n\n\n"
 45

}
}

2. Commit the configuration.

[edit system login]

user@host# commit

3. Connect to the device in a new session to verify the presence of the new banner.

The preceding login message configuration example produces a login message similar to the following:

server% telnet host

Trying 203.0.113.0
Connected to host.example.net
Escape character is ’^]’.

TP0 - M7i - iX Router Lab

UNAUTHORIZED USE OF THIS ROUTER

IS STRICTLY PROHIBITED!

Please contact '[email protected]' to gain

access to this equipment if you need authorization

login: user
Password:

July 27th 1:00 AM to 8:00

Planned Network Maintenance

AFFECTED LOCATIONS: Sunnyvale

PLANNED ACTIVITY: Upgrade all 6200 switch firmware to the Enterprise TAC
recommended firmware version

PURPOSE: This activity will help to minimize the impact of unplanned power
 46

outages as well as address known issues within our currently installed firmware
version(s)

WHAT TO EXPECT: During the maintenance window for your site, the office network
will not be available.

If the announcement text contains any spaces, enclose the text in quotation marks.

A system login announcement appears after the user logs in. A system login message appears before the
user logs in.

TIP: You can use the same special characters described to format your system login
announcement.

Configuring System Alarms to Appear Automatically Upon Login

You can configure Juniper Networks routers and switches to run the show system alarms command
whenever a user with the login class admin logs in to the router or switch. To do so, include the login-alarms
statement at the [edit system login class admin] hierarchy level.

[edit system login class admin]

login-alarms;

For more information on the show system alarms command, see the CLI Explorer.

SEE ALSO

show system alarms

Configuring Login Tips

The Junos OS CLI provides the option of configuring login tips for the user. By default, the tip command
is not enabled when a user logs in.
 47

• To enable tips, include the login-tip statement at the [edit system login class class-name] hierarchy level:

[edit system login class class-name]

login-tip;

Adding this statement enables the tip command for the class specified, provided the user logs in using the
CLI.

Examples: Configuring Time-Based User Access

The following example shows how to configure user access for the operator-round-the-clock-access login
class from Monday through Friday without any restriction on access time or duration of login:

[edit system]
login {
class operator-round-the-clock-access {
allowed-days [ monday tuesday wednesday thursday friday ];
}

The following example shows how to configure user access for the operator-day-shift login class on
Monday, Wednesday, and Friday from 8:30 AM to 4:30 PM:

[edit system]
login {
class operator-day-shift {
allowed-days [ monday wednesday friday ];
access-start 0830;
access-end 1630;
}
}

Alternatively, you can also specify the login start time and end time for the operator-day-shift login class
to be from 8:30 AM to 4:30 PM in the following format:

[edit system]
login {
class operator-day-shift {
allowed-days [ monday wednesday friday ];
access-start 08:30am;
access-end 04:30pm;
 48

}
}

The following example shows how to configure user access for the operator-day-shift-all-days-of-the-week
login class to be on all days of the week from 8:30 AM to 4:30 PM:

[edit system]
login {
class operator-day-shift-all-days-of-the-week {
access-start 0830;
access-end 1630;
}
}

SEE ALSO

Configuring Time-Based User Access

Configuring the Timeout Value for Idle Login Sessions

An idle login session is one in which the CLI operational mode prompt is displayed but there is no input
from the keyboard. By default, a login session remains established until a user logs out of the router or
switch, even if that session is idle. To close idle sessions automatically, you must configure a time limit for
each login class. If a session established by a user in that class remains idle for the configured time limit,
the session automatically closes. Idle-timeout can only be configured for user defined classes. Configuration
won't work for the system predefined classes: operator, read-only, super-user. These classes’ values and
permissions are not editable.

To define the timeout value for idle login sessions, include the idle-timeout statement at the [edit system
login class class-name] hierarchy level:

[edit system login class class-name]

idle-timeout minutes;

Specify the number of minutes that a session can be idle before it is automatically closed.

If you have configured a timeout value, the CLI displays messages similar to the following when timing out
an idle user. It starts displaying these messages 5 minutes before timing out the user.
 49

user@host# Session will be closed in 5 minutes if there is no activity.

Warning: session will be closed in 1 minute if there is no activity
Warning: session will be closed in 10 seconds if there is no activity
Idle timeout exceeded: closing session

If you configure a timeout value, the session closes after the specified time has elapsed, unless the user
is running telnet or monitoring interfaces using the monitor interface or monitor traffic command.

Login Retry Options

The security administrator can configure the number of times a user can try to log in to the device with
invalid login credentials. The device can be locked after the specified number of unsuccessful authentication
attempts. This helps to protect the device from malicious users attempting to access the system by guessing
an account’s password. The security administrator can unlock the user account or define a time period for
the user account to remain locked.

The system lockout-period defines the amount of time the device can be locked for a user account after
a specified number of unsuccessful login attempts.

The security administrator can configure a period of time after which an inactive session will be locked
and require re-authentication to be unlocked. This helps to protect the device from being idle for a long
period before the session times out.

The system idle-timeout defines length of time the CLI operational mode prompt remains active before
the session times out.

The security administrator can configure a banner with an advisory notice to be displayed before the
identification and authentication screen.

The system message defines the system login message. This message appears before a user logs in.

The number of reattempts the device allows is defined by the tries-before-disconnect option. The device
allows 3 unsuccessful attempts by default or as configured by the administrator. The device prevents the
locked users to perform activities that require authentication, until a security administrator manually clears
the lock or the defined time period for the device to remain locked has elapsed. However, the existing
locks are ignored when the user attempts to log in from the local console.
 50

NOTE: To clear the console during an administrator-initiated logout, the administrator must configure the set
system login message “message string” such that, the message-string contains newline (\n) characters and a
login banner message at the end of the \n characters.

To ensure that configuration information is cleared completely, the administrator can enter 50 or more \n
characters in the message-string of the command set system login message “message string”.

For example, set system login message

"\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Welcome to Junos!!!"

Limiting the Number of User Login Attempts for SSH and Telnet Sessions

You can limit the number of times a user can attempt to enter a password while logging in through SSH
or Telnet. The connection is terminated if a user fails to log in after the number of attempts specified. You
can also specify a delay, in seconds, before a user can try to enter a password after a failed attempt. In
addition, you can specify the threshold for the number of failed attempts before the user experiences a
delay in being able to enter a password again.

To specify the number of times a user can attempt to enter a password while logging in, include the
retry-options statement at the [edit system login] hierarchy level:

[edit system login]

retry-options {
tries-before-disconnect number;
backoff-threshold number;
backoff-factor seconds;
maximum-time seconds
minimum-time seconds;
}

You can configure the following options:

• tries-before-disconnect—Number of times a user can attempt to enter a password when logging in. The
connection closes if a user fails to log in after the number specified. The range is from 1 through 10, and
the default is 10.

• backoff-threshold—Threshold for the number of failed login attempts before the user experiences a
delay in being able to enter a password again. Use the backoff-factor option to specify the length of the
delay in seconds. The range is from 1 through 3, and the default is 2.
 51

• backoff-factor—Length of time, in seconds, before a user can attempt to log in after a failed attempt.
The delay increases by the value specified for each subsequent attempt after the threshold. The range
is from 5 through 10, and the default is 5 seconds.

• maximum-time seconds—Maximum length of time, in seconds, that the connection remains open for the
user to enter a username and password to log in. If the user remains idle and does not enter a username
and password within the configured maximum-time, the connection is closed. The range is from 20
through 300 seconds, and the default is 120 seconds.

• minimum-time—Minimum length of time, in seconds, that a connection remains open while a user is
attempting to enter a correct password. The range is from 20 through 60, and the default is 40.

The following example shows how to limit the user to four attempts when the user enters a password
while logging in through SSH or Telnet:

Limiting the number of SSH and Telnet login attempts per user is one of the most effective methods of
stopping brute force attacks from compromising your network security. Brute force attackers execute a
large number of login attempts in a short period of time to illegitimately gain access to a private network.
By configuring the retry-options command, you can create an increasing delay after each failed login
attempt, eventually disconnecting any user who passes your set threshold of login attempts.

Set the backoff-threshold to 2, the back-off-factor to 5 seconds, and the minimum-time to 40 seconds.
The user experiences a delay of 5 seconds after the second attempt to enter a correct password fails. After
each subsequent failed attempt, the delay increases by 5 seconds. After the fourth and final failed attempt
to enter a correct password, the user experiences an additional 10-second delay, and the connection closes
after a total of 40 seconds.

The additional variables maximum-time and lockout-period are not set in this example.

[edit]
system {
login {
retry-options {
backoff-threshold 2;
backoff-factor 5;
minimum-time 40;
tries-before-disconnect 4;
}
password {
}
}
}
 52

NOTE: This sample only shows the portion of the [edit system login] hierarchy level being
modified.

Example: Configuring Login Retry Options

IN THIS SECTION

Requirements | 52
Overview | 52

Configuration | 54

Verification | 55

This example shows how to configure system retry options to protect the device from malicious users.

Requirements

Before you begin, you should understand “Login Retry Options” on page 49.

No special configuration beyond device initialization is required before configuring this feature.

Overview

Malicious users sometimes try to log in to a secure device by guessing an authorized user account’s
password. Locking out a user account after a number of failed authentication attempts helps protect the
device from malicious users.

Device lockout allows you to configure the number of failed attempts before the user account is locked
out of the device and configure the amount of time before the user can attempt to log in to the device
again. You can configure the amount of time in-between failed login attempts of a user account and can
manually lock and unlock user accounts.
 53

NOTE:
This example includes the following settings:

• backoff-factor — Sets the length of delay in seconds after each failed login attempt. When a
user incorrectly logs in to the device, the user must wait the configured amount of time before
attempting to log in to the device again. The length of delay increases by this value for each
subsequent login attempt after the value specified in the backoff-threshold statement. The
default value for this statement is five seconds, with a range of five to ten seconds.

• backoff-threshold — Sets the threshold for the number of failed login attempts on the device
before the user experiences a delay when attempting to reenter a password. When a user
incorrectly logs in to the device and hits the threshold of failed login attempts, the user
experiences a delay that is set in the backoff-factor statement before attempting to log in to
the device again. The default value for this statement is two, with a range of one through three.

• lockout-period — Sets the amount of time in minutes before the user can attempt to log in to
the device after being locked out due to the number of failed login attempts specified in the
tries-before-disconnect statement. When a user fails to correctly login after the number of
allowed attempts specified by the tries-before-disconnect statement, the user must wait the
configured amount of minutes before attempting to log in to the device again. The
lockout-period must be greater than zero. The range at which you can configure the
lockout-period is one through 43,200 minutes.

• tries-before-disconnect — Sets the maximum number of times the user is allowed to enter a
password to attempt to log in to the device through SSH or Telnet. When the user reaches
the maximum number of failed login attempts, the user is locked out of the device. The user
must wait the configured amount of minutes in the lockout-period statement before attempting
to log back in to the device. The tries-before-disconnect statement must be set when the
lockout-period statement is set; otherwise, the lockout-period statement is meaningless. The
default number of attempts is ten, with a range of one through ten attempts.

Once a user is locked out of the device, if you are the security administrator, you can manually
remove the user from this state using the clear system login lockout <username> command. You
can also use the show system login lockout command to view which users are currently locked
out, when the lockout period began for each user, and when the lockout period ends for each
user.

If the security administrator is locked out of the device, he can log in to the device from the
console port, which ignores any user locks. This provides a way for the administrator to remove
the user lock on their own user account.

In this example the user waits for the backoff-threshold multiplied by the backoff-factor interval, in
seconds, to get the login prompt. In this example, the user must wait 5 seconds after the first failed login
attempt and 10 seconds after the second failed login attempt to get the login prompt. The user gets
 54

disconnected after 15 seconds after the third failed attempt because the tries-before-disconnect option
is configured as 3.

The user cannot attempt anther login until 120 minutes has elapsed, unless a security administrator manually
clears the lock sooner.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, copy and paste the
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

set system login retry-options backoff-factor 5

set system login retry-options backoff-threshold 1
set system login retry-options lockout-period 120
set system login retry-options tries-before-disconnect 3

Step-by-Step Procedure
To configure system retry-options:

1. Configure the backoff factor.

[edit ]
user@host# set system login retry-options backoff-factor 5

2. Configure the backoff threshold.

[edit]
user@host# set system login retry-options backoff-threshold 1

3. Configure the amount of time the device gets locked after failed attempts.

[edit]
user@host# set system login retry-options lockout-period 5

4. Configure the number of unsuccessful attempts during which, the device can remain unlocked.

[edit]
user@host# set system login retry-options tries-before-disconnect 3
 55

Results
From configuration mode, confirm your configuration by entering the show system login retry-options
command. If the output does not display the intended configuration, repeat the configuration instructions
in this example to correct it.

[edit]
user@host# show system login retry-options
backoff-factor 5;
backoff-threshold 1;
lockout-period 5;
tries-before-disconnect 3;

Confirm that the configuration is working properly.

If you are done configuring the device, enter commit from configuration mode.

Verification

Displaying the Locked User Logins

Purpose
Verify that the login lockout configuration is enabled.

Action
Attempt three unsuccessful logins for a particular username. The device will be locked for that username;
then log in to the device with a different username. From operational mode, enter the show system login
lockout command.

Meaning
When you perform three unsuccessful login attempts with a particular username, the device is locked for
that user for five minutes, as configured in the example. You can verify that the device is locked for that
user by logging in to the device with a different username and entering the show system login lockout
command.

RELATED DOCUMENTATION

Junos OS Login Classes Overview | 37

Junos OS User Accounts | 57
2 CHAPTER

User Accounts

Junos OS User Accounts | 57

Junos OS Administrative Roles | 71

Junos OS User Access Privileges | 83

 57

Junos OS User Accounts

IN THIS SECTION

Junos OS User Accounts Overview | 57

Junos-FIPS Crypto Officer and User Accounts Overview | 59

Example: Configuring User Accounts | 60

Example: Configuring New Users | 61

Configuring Junos OS User Accounts by Using a Configuration Group | 68

Junos OS allows you to create accounts for router, switch, and security users. All users also belong to one
of the system login classes.

Junos OS requires that all users have a predefined user account before they can log in to the device. For
each user account, you define the login name for the user and, optionally, information that identifies the
user. User accounts provide a way for users to access a router or switch or security device. Read this topic
for more information.

Junos OS User Accounts Overview

User accounts provide one way for users to access the device. (Users can access the device without
accounts if you configured RADIUS or TACACS+ servers, as described in “Junos OS User Authentication
Methods” on page 172.) For each account, you define the login name and password for the user and,
optionally, additional parameters and metadata for the user. After you have created an account, the
software creates a home directory for the user.

An account for the user root is always present in the configuration. You configure the password for root
using the root-authentication statement, as described in “Configuring the Root Password” on page 142.

It is a common practice to use remote authentication servers to centrally store information about users.
Even so, it is also a good practice to configure at least one non-root user directly on each device, in case
access to the remote authentication server is disrupted. This one non-root user commonly has a generic
name, such as admin.

For each user account, you can define the following:

 58

• Username: Name that identifies the user. It must be unique within the device. Do not include spaces,
colons, or commas in the username. The username can be up to 64 characters long.

• User’s full name: (Optional) If the full name contains spaces, enclose it in quotation marks. Do not include
colons or commas.

• User identifier (UID): (Optional) Numeric identifier that is associated with the user account name. Typically
there is no need to set the UID because the software automatically assigns it when you commit the
configuration. However, if you manually configure the UID, it must be in the range from 100 through
64,000 and must be unique within the device.

You must ensure that the UID is unique. However, it is possible to assign the same UID to different
users. If you do this, the CLI displays a warning when you commit the configuration and then assigns
the duplicate UID.

• User’s access privilege: (Required) One of the login classes you defined in the class statement at the
[edit system login] hierarchy level, or one of the default classes listed in “Junos OS User Access Privileges”
on page 83.

• Authentication method or methods and passwords that the user can use to access the device—You can
use SSH or a Message Digest 5 (MD5) password, or you can enter a plain-text password that the Junos
OS encrypts using MD5-style encryption before entering it in the password database. For each method,
you can specify the user’s password. If you configure the plain-text-password option, you are prompted
to enter and confirm the password:

[edit system login user username]

user@host# set authentication plain-text-password
New password: type password here
Retype new password: retype password here

The default requirements for plain-text passwords are:

• The password must be between 6 and 128 characters long.

• You can include most character classes in a password (uppercase letters, lowercase letters, numbers,
punctuation marks, and other special characters). Control characters are not recommended.

• Valid passwords must contain at least one change of case or character class.

Junos-FIPS and Common Criteria have special password requirements. FIPS and Common Criteria
passwords must be between 10 and 20 characters in length. Passwords must use at least three of the
five defined character sets (uppercase letters, lowercase letters, digits, punctuation marks, and other
special characters). If Junos-FIPS is installed on the device, you cannot configure passwords unless they
meet this standard.

For SSH authentication, you can copy the contents of an SSH key file into the configuration or directly
configure SSH key information. Use the load-key-file URL filename command to load an SSH key file that
was previously generated, e.g. by using ssh-keygen. The URL filename is the path to the file’s location and
 59

name. This command loads RSA (SSH version 1 and SSH version 2) and DSA (SSH version 2) public keys.
The contents of the SSH key file are copied into the configuration immediately after you enter the
load-key-file statement. Optionally, you can use the ssh-dsa public key <from hostname> and the ssh-rsa
public key <from hostname> statements to directly configure SSH keys.

The following TLS version and cipher suite combinations will fail when you use the specified type of host
key.

With RSA host keys:

• TLS_1.0@DHE-RSA-AES128-SHA

• TLS_1.0@DHE-RSA-AES256-SHA

With DSA host keys:

• TLS 1.0 (default ciphers)

• TLS 1.1 (default ciphers)

• TLS_1.0@DHE-DSS-AES128-SHA

• TLS_1.0@DHE-DSS-AES256-SHA

For each user account and for root logins, you can configure more than one public RSA or DSA key for
user authentication. When a user logs in using a user account or as root, the configured public keys are
referenced to determine whether the private key matches any of them.

To view the SSH keys entries, use the configuration mode show command. For example:

[edit system login user boojum]

user@host# set authentication load-key-file my-host:.ssh/id_dsa.pub
.file.19692 | 0 KB | 0.3 kB/s | ETA: 00:00:00 | 100%
[edit system]
user@host# show
root-authentication {
ssh-rsa "$ABC123"; # SECRET-DATA
}

Junos-FIPS Crypto Officer and User Accounts Overview

Junos-FIPS defines a restricted set of user roles. Unlike the Junos OS, which enables a wide range of
capabilities to users, FIPS 140-2 defines specific types of users (Crypto Officer, User, and Maintenance).
Crypto Officers and FIPS Users perform all FIPS-related configuration tasks and issue all FIPS-related
commands. Crypto Officer and FIPS User configurations must follow FIPS 140-2 guidelines. Typically, no
user besides a Crypto Officer can perform FIPS-related tasks.
 60

Crypto Officer User Configuration

Junos-FIPS offers finer control of user permissions than those mandated by FIPS 140-2. For FIPS 140-2
conformance, any Junos-FIPS user with the secret, security, and maintenance permission bits set is a
Crypto Officer. In most cases, the super-user class should be reserved for a Crypto Officer. A FIPS User
can be defined as any Junos-FIPS user that does not have the secret, security, and maintenance bits set.

FIPS User Configuration

A Crypto Officer sets up FIPS Users. FIPS Users can be granted permissions normally reserved for a Crypto
Officer; for example, permission to zeroize the system and individual AS-II FIPS PICs.

Example: Configuring User Accounts

The following example shows how to create accounts for four router or switch users, and create an account
for the template user remote. All users use one of the default system login classes. User alexander also
has two digital signal algorithm (DSA) public keys configured for SSH authentication.

[edit]
system {
login {
user philip {
full-name “Philip of Macedonia”;
uid 1001;
class super-user;
authentication {
encrypted-password “$ABC123”;
}
}
user alexander {
full-name “Alexander the Great”;
uid 1002;
class view;
authentication {
encrypted-password “$ABC123”;
ssh-dsa “8924 37 5678 [email protected]”;
ssh-dsa “6273 94 [email protected]”;
}
}
user darius {
full-name “Darius King of Persia”;
 61

uid 1003;
class operator;
authentication {
ssh-rsa “1024 37 [email protected]”;
}
}
user anonymous {
class unauthorized;
}
user remote {
full-name “All remote users”;
uid 9999;
class read-only;
}
}
}

Example: Configuring New Users

IN THIS SECTION

Requirements | 61

Overview | 62

Configuration | 62

Verification | 67

This example shows how to configure new users.

Requirements

No special configuration beyond device initialization is required before configuring this feature.
 62

Overview

You can add new users to the device’s local database. For each account, you define a login name and
password for the user and specify a login class for access privileges. The login password must meet the
following criteria:

• The password must be at least six characters long.

• You can include most character classes in a password (alphabetic, numeric, and special characters), but
not control characters.

• The password must contain at least one change of case or character class.

In this example, you create a login class named operator-and-boot and allow it to reboot the device. You
can define any number of login classes. You then allow the operator-and-boot login class to use commands
defined in the clear, network, reset, trace, and view permission bits.

Then you create user accounts. User accounts enable you to access the device. (You can access the device
without accounts if you configured RADIUS or TACACS+ servers.) You set the username as cmartin and
the login class as superuser. Finally, you define the encrypted password for the user.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, copy and paste the
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

set system login class operator-and-boot allow-commands “request system reboot”

set class system login operator-and-boot permissions [clear network reset trace view]
set system login user cmartin class superuser authentication encrypted-password $1$ABC123

GUI Step-by-Step Procedure

To configure new users:

1. In the J-Web user interface, select Configure>System Properties>User Management.

2. Click Edit. The Edit User Management dialog box appears.

3. Select the Users tab.

4. Click Add to add a new user. The Add User dialog box appears.

5. In the User name box, type a unique name for the user.
 63

Do not include spaces, colons, or commas in the username.

6. In the User ID box, type a unique ID for the user.

7. In the Full Name box, type the user’s full name.

If the full name contains spaces, enclose it in quotation marks. Do not include colons or commas.

8. In the Password and Confirm Password boxes, enter a login password for the user and verify your
entry.

9. From the Login Class list, select the user’s access privilege:

• operator

• read-only

• unauthorized

This list also includes any user-defined login classes.

10. Click OK in the Add User dialog box and Edit User Management dialog box.

11. Click OK to check your configuration and save it as a candidate configuration.

12. If you are done configuring the device, click Commit Options>Commit.

Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions
on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure new users:

1. Set the name of the login class and allow the use of the reboot command.

[edit system login]

user@host# set class operator-and-boot allow-commands “request system reboot”

2. Set the permission bits for the login class.

[edit system login]

user@host# set class operator-and-boot permissions [clear network reset trace view]

3. Set the username, login class, and encrypted password for the user.
 64

[edit system login]

user@host# set user cmartin class superuser authentication encrypted-password $1$ABC123

Results
From configuration mode, confirm your configuration by entering the show system login command. If the
output does not display the intended configuration, repeat the configuration instructions in this example
to correct it.

[edit]
user@host# show system login
class operator-and-boot {
permissions [ clear network reset trace view ];
allow-commands "request system reboot";
}
user cmartin {
class superuser;
authentication {
encrypted-password "$1$ABC123";
}
}

The following example shows how to create accounts for four router or switch users, and create an account
for the template user remote. All users use one of the default system login classes. User alexander also
has two digital signal algorithm (DSA) public keys configured for SSH authentication.

[edit]
system {
login {
user philip {
full-name “Philip of Macedonia”;
uid 1001;
class super-user;
authentication {
encrypted-password “$ABC123”;
}
}
user alexander {
full-name “Alexander the Great”;
uid 1002;
class view;
authentication {
encrypted-password “$ABC123”;
 65

ssh-dsa “8924 37 5678 [email protected]”;

ssh-dsa “6273 94 [email protected]”;
}
}
user darius {
full-name “Darius King of Persia”;
uid 1003;
class operator;
authentication {
ssh-rsa “1024 37 [email protected]”;
}
}
user anonymous {
class unauthorized;
}
user remote {
full-name “All remote users”;
uid 9999;
class read-only;
}
}
}

The following example shows how to create accounts for four router or switch users, and create an account
for the template user remote. All users use one of the default system login classes. User alexander also
has two digital signal algorithm (DSA) public keys configured for SSH authentication.

[edit]
system {
login {
user philip {
full-name “Philip of Macedonia”;
uid 1001;
class super-user;
authentication {
encrypted-password “$ABC123”;
}
}
user alexander {
full-name “Alexander the Great”;
uid 1002;
class view;
authentication {
encrypted-password “$ABC123”;
 66

ssh-dsa “8924 37 5678 [email protected]”;

ssh-dsa “6273 94 [email protected]”;
}
}
user darius {
full-name “Darius King of Persia”;
uid 1003;
class operator;
authentication {
ssh-rsa “1024 37 [email protected]”;
}
}
user anonymous {
class unauthorized;
}
user remote {
full-name “All remote users”;
uid 9999;
class read-only;
}
}
}

The following example shows how to create accounts for four router or switch users, and create an account
for the template user remote. All users use one of the default system login classes. User alexander also
has two digital signal algorithm (DSA) public keys configured for SSH authentication.

[edit]
system {
login {
user philip {
full-name “Philip of Macedonia”;
uid 1001;
class super-user;
authentication {
encrypted-password “$ABC123”;
}
}
user alexander {
full-name “Alexander the Great”;
uid 1002;
class view;
authentication {
encrypted-password “$ABC123”;
 67

ssh-dsa “8924 37 5678 [email protected]”;

ssh-dsa “6273 94 [email protected]”;
}
}
user darius {
full-name “Darius King of Persia”;
uid 1003;
class operator;
authentication {
ssh-rsa “1024 37 [email protected]”;
}
}
user anonymous {
class unauthorized;
}
user remote {
full-name “All remote users”;
uid 9999;
class read-only;
}
}
}

If you are done configuring the device, enter commit from configuration mode.

NOTE: To completely set up RADIUS or TACACS+ authentication, you must configure at least
one RADIUS or TACACS+ server and specify a user template account. Do one of the following
tasks:

• Configure a RADIUS server. See “Example: Configuring a RADIUS Server for System
Authentication” on page 203.

• Configure a TACACS+ server. See “Example: Configuring a TACACS+ Server for System
Authentication” on page 232.

• Configure a user. See “Example: Configuring New Users” on page 61.

• Configure template accounts. See “Example: Creating Template Accounts” on page 176.

Verification

Confirm that the configuration is working properly.

 68

Verifying the New Users Configuration

Purpose
Verify that the new users have been configured.

Action
From operational mode, enter the show system login command.

Configuring Junos OS User Accounts by Using a Configuration Group

Because user accounts are configured on multiple devices, they are commonly configured inside of a
configuration group. As such, the examples shown here are in a configuration group called global. Using
a configuration group for your user accounts is optional.

To create a user account:

1. Add a new user, using the user’s assigned account login name.

[edit groups global]

user@host# edit system login user username

2. (Optional) Configure a full descriptive name for the account.

If the full name includes spaces, enclose the entire name in quotation marks.

[edit groups global system login user user-name]

user@host# set full-name complete-name

For example:

user@host# show groups

global {
system {
login {
user admin {
full-name "general administrator";
}
}
}
}

3. (Optional) Set the user identifier (UID) for the account.

 69

As with UNIX systems, the UID enforces user permissions and file access. If you do not set the UID,
Junos OS assigns one for you. The format of the UID is a number in the range of 100 to 64000.

[edit groups global system login user user-name]

user@host# set uid uid-value

For example:

user@host# show groups

global {
system {
login {
user admin {
uid 9999;
}
}
}
}

4. Assign the user to a login class.

You can define your own login classes or assign one of the predefined Junos OS login classes.

The predefined login classes are as follows:

• super-user—all permissions

• operator—clear, network, reset, trace, and view permissions

• read-only— view permissions

• unauthorized—no permissions

[edit groups global system login user user-name]

user@host# set class class-name

For example:

user@host# show groups

global {
system {
login {
user admin {
class super-user;
}
 70

}
}
}

5. Use one of the following methods to configure the user password.

• To enter a clear-text password that the system encrypts for you, use the following command to set
the user password:

[edit groups global system login user user-name]

user@host# set authentication plain-text-password password
New Password: type password here
Retype new password: retype password here

As you enter the password in plain text, Junos OS encrypts it immediately. You do not have to
configure Junos OS to encrypt the password as in some other systems. Plain-text passwords are
therefore hidden and marked as ## SECRET-DATA in the configuration.

• To enter a password that is already encrypted, use the following command to set the user password:

CAUTION: Do not use the encrypted-password option unless the password is

already encrypted, and you are entering the encrypted version of the password.

If you accidentally configure the encrypted-password option with a plain-text

password or with blank quotation marks (" "), you will not be able to log in to the
device as this user.

[edit groups global system login user user-name]

user@host# set authentication encrypted-password "password"

• To load previously generated public keys from a named file at a specified URL location, use the
following command to set the user password:

[edit groups global system login user user-name]

user@host# set authentication load-key-file URL filename

• To enter an ssh public string, use the following command to set the user password:

[edit groups global system login user user-name]

user@host# set authentication (ssh-ecdsa | ssh-ed25519 | ssh-rsa) authorized-key
 71

6. At the top level of the configuration, apply the configuration group.

If you use a configuration group, you must apply it for it to take effect.

[edit]
user@host# set apply-groups global

7. Commit the configuration.

user@host# commit

8. To verify the configuration, log out and log back in as the new user.

RELATED DOCUMENTATION

Junos OS Administrative Roles | 71

Junos OS User Access Privileges | 83
Junos OS User Accounts Overview | 57

Junos OS Administrative Roles

IN THIS SECTION

Understanding Administrative Roles | 72

Example: Configuring Administrative Roles | 74

Configuring a Local Administrator Account | 82

Junos OS allows you to define a system user to act as a particular kind of administrator for the system.
You can assign an administrative role to a user by configuring a login class to have the administrative role
attributes. You can assign one of the role attributes such as audit-officer crypto-officer, security-officer,
ids-officer to an administrative user. Read this topic for more information.
 72

Understanding Administrative Roles

A system user can be a member of a class that allows the user to act as a particular kind of administrator
for the system. Requiring a specific role to view or modify an item restricts the extent of information a
user can obtain from the system. It also limits how much of the system is open to intentional or unintentional
modification or observation by a user. We recommend that you use the following guidelines when you
are designing administrative roles:

• Do not allow any user to log in to the system as root.

• Restrict each user to the smallest set of privileges needed to perform the user’s duties.

• Do not allow any user to belong to a login class containing the shell permission flag. The shell permission
flag allows users to run the start shell command from the CLI.

• Allow users to have rollback permissions. Rollback permissions allow users to undo an action performed
by an administrator but does not allow them to commit the changes.

You can assign an administrative role to a user by configuring a login class to have the privileges required
for that role. You can configure each class to allow or deny access to configuration statements and
commands by name. These specific restrictions override and take precedence over any permission flags
also configured in the class. You can assign one of the following role attributes to an administrative user.

• Crypto-administrator—Allows the user to configure and monitor cryptographic data.

• Security-administrator—Allows the user to configure and monitor security data.

• Audit-administrator—Allows the user to configure and monitor audit data.

• IDS-administrator—Allows the user to monitor and clear the intrusion detection service (IDS) security
logs.

Each role can perform the following specific management functions:

• Cryptographic Administrator

• Configures the cryptographic self-test.

• Modifies the cryptographic security data parameters.

• Audit Administrator

• Configures and deletes the audit review search and sort feature.

• Searches and sorts audit records.

• Configures search and sort parameters.

• Manually deletes audit logs.

• Security Administrator
 73

• Invokes, determines, and modifies the cryptographic self-test behavior.

• Enables, disables, determines, and modifies the audit analysis and audit selection functions and
configures the device to automatically delete audit logs.

• Enables or disables security alarms.

• Specifies limits for quotas on Transport Layer connections.

• Specifies the limits, network identifiers, and time periods for quotas on controlled connection-oriented
resources.

• Specifies the network addresses permitted to use Internet Control Message Protocol (ICMP) or Address
Resolution Protocol (ARP).

• Configures the time and date used in time stamps.

• Queries, modifies, deletes, and creates the information flow or access control rules and attributes for
the unauthenticated information flow security function policy (SFP), the authenticated information
flow SFP, the unauthenticated device services, and the discretionary access control policy.

• Specifies initial values that override default values when object information is created under
unauthenticated information flow SFP, the authenticated information flow SFP, the unauthenticated
target of evaluation (TOE) services, and the discretionary access control policy.

• Creates, deletes, or modifies the rules that control the address from which management sessions can
be established.

• Specifies and revokes security attributes associated with the users, subjects, and objects.

• Specifies the percentage of audit storage capacity at which the device alerts administrators.

• Handles authentication failures and modifies the number of failed authentication attempts through
SSH or from the CLI that can occur before progressive throttling is enforced for further authentication
attempts and before the connection is dropped.

• Manages basic network configuration of the device.

• IDS Administrator—Specifies IDS security alarms, intrusion alarms, audit selections, and audit data.

You need to set the security-role attribute in the classes created for these administrative roles. This attribute
restricts which users can show and clear the security logs, actions that cannot be performed through
configuration alone.

For example, you need to set the security-role attribute in the ids-admin class created for the IDS
administrator role if you want to restrict clearing and showing IDS logs to the IDS administrator role.
Likewise, you need to set the security-role to one of the other admin values to restrict that class from
being able to clear and show non-IDS logs only.
 74

NOTE: When a user deletes an existing configuration, the configuration statements under the
hierarchy level of the deleted configuration (that is, the child objects that the user does not have
permission to modify), now remain in the device.

Example: Configuring Administrative Roles

IN THIS SECTION

Requirements | 74

Overview | 74

Configuration | 75

Verification | 81

This example shows how to configure individual administrative roles for a distinct, unique set of privileges
apart from all other administrative roles.

Requirements

No special configuration beyond device initialization is required before configuring this feature.

Overview

This example configures four users:

• audit-officer of the class audit-admin

• crypto-officer of the class crypto-admin

• security-officer of the class security-admin

• ids-officer of the class ids-admin

When a security-admin class is configured, the privileges for creating administrators are revoked from the
user who created the security-admin class. Creation of new users and logins is at the discretion of the
security-officer.
 75

In this example, you create audit admin, crypto admin, security admin, and ids admin with permission flags
pertaining to this role. Then you allow or deny access to configuration statements and commands by name
for each administrative role. These specific restrictions take precedence over the permission flags also
configured in the class. For example, only the crypto-admin can run the request system set-encryption-key
command, which requires having the security permission flag to access it. Only the security-admin can
include the system time-zone statement in the configuration, which requires having the system-control
permission flag.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, copy and paste the
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

set system login class audit-admin permissions security

set system login class audit-admin permissions trace
set system login class audit-admin permissions maintenance
set system login class audit-admin allow-commands "^clear (log|security log)"
set system login class audit-admin deny-commands "^clear (security alarms|system login lockout)|^file
(copy|delete|rename)|^request (security|system set-encryption-key)|^rollback|^set date|^show security
(alarms|dynamic-policies|match-policies|policies)|^start shell";
set system login class audit-admin security-role audit-administrator
set system login class crypto-admin permissions admin-control
set system login class crypto-admin permissions configure
set system login class crypto-admin permissions maintenance
set system login class crypto-admin permissions security-control
set system login class crypto-admin permissions system-control
set system login class crypto-admin permissions trace
set system login class crypto-admin allow-commands "^request system set-encryption-key"
set system login class crypto-admin deny-commands "^clear (log|security alarms|security log|system login
lockout)|^file (copy|delete|rename)|^rollback|^set date|^show security
(alarms|dynamic-policies|match-policies|policies)|^start shell"
set system login class crypto-admin allow-configuration-regexps "security (ike|ipsec) (policy|proposal)" "security
ipsec ^vpn$ .* manual (authentication|encryption|protocol|spi)" "system fips self-test after-key-generation"
set system login class crypto-admin security-role crypto-administrator
set system login class security-admin permissions all
set system login class security-admin deny-commands "^clear (log|security log)|^(clear|show) security alarms
alarm-type idp|^request (security|system set-encryption-key)|^rollback|^start shell"
set system login class security-admin deny-configuration-regexps "security alarms potential-violation idp"
"security (ike|ipsec) (policy|proposal)" "security ipsec ^vpn$ .* manual (authentication| encryption|protocol|spi)"
"security log cache" "security log exclude .* event-id IDP_.*" "system fips self-test after-key- generation"
set system login class security-admin security-role security-administrator
set system login class ids-admin permissions configure
 76

set system login class ids-admin permissions security-control

set system login class ids-admin permissions trace
set system login class ids-admin permissions maintenance
set system login class ids-admin allow-configuration-regexps "security alarms potential-violation idp" "security
log exclude .* event-id IDP_.*"
set system login class ids-admin deny-commands "^clear log|^(clear|show) security alarms
(alarm-id|all|newer-than|older- than|process|severity)|^(clear|show) security alarms alarm-type
(authentication|cryptographic-self-test|decryption-failures|encryption-failures|
ike-phase1-failures|ike-phase2-failures|key-generation-self-test|
non-cryptographic-self-test|policy|replay-attacks)|^file (copy|delete|rename)|^request (security|system
set-encryption-key)|^rollback|
^set date|^show security (dynamic-policies|match-policies|policies)|^start shell"
set system login class ids-admin deny-configuration-regexps "security alarms potential-violation
(authentication|cryptographic-self-test|decryption-
failures|encryption-failures|ike-phase1-failures|ike-phase2-failures|
key-generation-self-test|non-cryptographic-self-test|policy|replay-attacks)"
set system login class ids-admin security-role ids-admin
set system login user audit-officer class audit-admin
set system login user crypto-officer class crypto-admin
set system login user security-officer class security-admin
set system login user ids-officer class ids-admin
set system login user audit-officer authentication plain-text-password
set system login user crypto-officer authentication plain-text-password
set system login user security-officer authentication plain-text-password
set system login user ids-officer authentication plain-text-password

Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For information
about navigating the CLI, see Using the CLI Editor in Configuration Mode.

To configure users in administrative roles:

1. Create the audit-admin login class.

[edit]
user@host# set system login class audit-admin
[edit system login class audit-admin]
user@host# set permissions security
user@host# set permissions trace
user@host# set permissions maintenance

2. Configure the audit-admin login class restrictions.

 77

[edit system login class audit-admin]

user@host# set allow-commands "^clear (log|security log)"
user@host# set deny-commands "^clear (security alarms|system login lockout)|^file
(copy|delete|rename)|^request (security|system set-encryption-key)|^rollback|^set date|^show security
(alarms|dynamic-policies|match-policies|policies)|^start shell"
user@host# set security-role audit-administrator

3. Create the crypto-admin login class.

[edit]
user@host# set system login class crypto-admin

[edit system login class crypto-admin]

user@host# set permissions admin-control
user@host# set permissions configure
user@host# set permissions maintenance
user@host# set permissions security-control
user@host# set permissions system-control
user@host# set permissions trace

4. Configure the crypto-admin login class restrictions.

[edit system login class crypto-admin]

user@host# set allow-commands "^request system set-encryption-key"
user@host# set deny-commands "^clear (log|security alarms|security log|system login lockout)|^file
(copy|delete|rename)|^rollback|^set date|^show security
(alarms|dynamic-policies|match-policies|policies)|^start shell"
user@host# set allow-configuration-regexps "security (ike|ipsec) (policy|proposal)" "security ipsec ^vpn$ .*
manual (authentication|encryption|protocol|spi)" "system fips self-test after-key-generation"
user@host# set security-role crypto-administrator

5. Create the security-admin login class.

[edit]
user@host# set system login class security-admin

[edit system login class security-admin]

user@host# set permissions all

6. Configure the security-admin login class restrictions.

 78

[edit system login class security-admin]

user@host# set deny-commands "^clear (log|security log)|^(clear|show) security alarms alarm-type idp|^request
(security|system set-encryption-key)|^rollback|^start shell"
user@host# set deny-configuration-regexps "security alarms potential-violation idp" "security (ike|ipsec)
(policy|proposal)" "security ipsec ^vpn$ .* manual (authentication| encryption|protocol|spi)" "security log
cache" "security log exclude .* event-id IDP_.*" "system fips self-test after-key- generation"
user@host# set security-role security-administrator

7. Create the ids-admin login class.

[edit]
user@host# set system login class ids-admin

[edit system login class ids-admin]

user@host# set permissions configure
user@host# set permissions maintenance
user@host# set permissions security-control
user@host# set permissions trace

8. Configure the ids-admin login class restrictions.

[edit system login class ids-admin]

user@host# set allow-configuration-regexps "security alarms potential-violation idp" "security log exclude
.* event-id IDP_.*"
set system login class ids-admin deny-commands "^clear log|^(clear|show) security alarms
(alarm-id|all|newer-than|older- than|process|severity)|^(clear|show) security alarms alarm-type
(authentication|cryptographic-self-test|decryption-failures|encryption-failures|
ike-phase1-failures|ike-phase2-failures|key-generation-self-test|
non-cryptographic-self-test|policy|replay-attacks)|^file (copy|delete|rename)|^request (security|system
set-encryption-key)|
^rollback|^set date|^show security (dynamic-policies|match-policies|policies)|^start shell"
set system login class ids-admin deny-configuration-regexps "security alarms potential-violation
(authentication|cryptographic-self-test|decryption-
failures|encryption-failures|ike-phase1-failures|ike-phase2-failures|
key-generation-self-test|non-cryptographic-self-test|policy|replay-attacks)"
user@host# set security-role ids-administrator

9. Assign users to the roles.

[edit]
user@host# set system login
 79

[edit system login]

user@host# set user audit-officer class audit-admin
user@host# set user crypto-officer class crypto-admin
user@host# set user security-officer class security-admin
user@host# set user ids-officer class ids-admin

10. Configure passwords for the users.

[edit system login]

user@host# set user audit-officer authentication plain-text-password
user@host# set user crypto-officer authentication plain-text-password
user@host# set user security-officer authentication plain-text-password
user@host# set user ids-officer authentication plain-text-password

Results

From configuration mode, confirm your configuration by entering the show system command. If the output
does not display the intended configuration, repeat the instructions in this example to correct the
configuration.

[edit]
user@host# show system
system {
login {
class audit-admin {
permissions [ maintenance security trace ];
allow-commands "^clear (log|security log)";
deny-commands "^clear (security alarms|system login lockout)|^file (copy|delete|rename)|^request
(security|system set-encryption-key)|^rollback|^set date|^show security
(alarms|dynamic-policies|match-policies|policies)|^start shell";
security-role audit-administrator;
}
class crypto-admin {
permissions [ admin-control configure maintenance security-control system-control trace ];
allow-commands "^request (system set-encryption-key)";
deny-commands "^clear (log|security alarms|security log|system login lockout)|^file
(copy|delete|rename)|^rollback|^set date|^show security
(alarms|dynamic-policies|match-policies|policies)|^start shell";
allow-configuration-regexps "security (ike|ipsec) (policy|proposal)" "security ipsec ^vpn$ .* manual
(authentication|encryption|protocol|spi)" "system fips self-test after-key-generation" ;
security-role crypto-administrator;
}
 80

class security-admin {
permissions [all];
deny-commands "^clear (log|security log)|^(clear|show) security alarms alarm-type idp|^request
(security|system set-encryption-key)|^rollback|^start shell";
deny-configuration-regexps "security alarms potential-violation idp" "security (ike|ipsec) (policy|proposal)"
"security ipsec ^vpn$ .* manual (authentication|encryption|protocol|spi)" "security log exclude .* event-id
IDP_.*" "system fips self-test after-key-generation";
security-role security-administrator;
}
class ids-admin {
permissions [ configure maintenance security-control trace ];
deny-commands "^clear log|^(clear|show) security alarms
(alarm-id|all|newer-than|older-than|process|severity)|^(clear|show) security alarms alarm-type
(authentication | cryptographic-self-test | decryption-failures | encryption-failures
| ike-phase1-failures | ike-phase2-failures|key-generation-self-test |
non-cryptographic-self-test |policy | replay-attacks) | ^file (copy|delete|rename)
|^request (security|system set-encryption-key) | ^rollback |
^set date | ^show security (dynamic-policies|match-policies|policies) |^start shell";
allow-configuration-regexps "security alarms potential-violation idp" "security log exclude .* event-id
IDP_.*";
deny-configuration-regexps "security alarms potential-violation
(authentication|cryptographic-self-test|decryption-
failures|encryption-failures|ike-phase1-failures|ike-phase2-failures|
key-generation-self-test|non-cryptographic-self-test|policy|replay-attacks)"
security-role ids-administrator;
}
user audit-officer {
class audit-admin;
authentication {
encrypted-password "$1$ABC123"; ## SECRET-DATA
}
}
user crypto-officer {
class crypto-admin;
authentication {
encrypted-password "$1$ABC123."; ## SECRET-DATA
}
}
user security-officer {
class security-admin;
authentication {
encrypted-password "$1$ABC123."; ##SECRET-DATA
}
}
 81

user ids-officer {
class ids-admin;
authentication {
encrypted-password "$1$ABC123/"; ## SECRET-DATA
}
}
}
}

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying the Login Permissions

Purpose
Verify the login permissions for the current user.

Action
From operational mode, enter the show cli authorization command.

user@host>show cli authorization

Current user: 'example' class 'super-user'

Permissions:
admin -- Can view user accounts
admin-control-- Can modify user accounts
clear -- Can clear learned network info
configure -- Can enter configuration mode
control -- Can modify any config
edit -- Can edit full files
field -- Can use field debug commands
floppy -- Can read and write the floppy
interface -- Can view interface configuration
interface-control-- Can modify interface configuration
network -- Can access the network
reset -- Can reset/restart interfaces and daemons
routing -- Can view routing configuration
routing-control-- Can modify routing configuration
shell -- Can start a local shell
snmp -- Can view SNMP configuration
snmp-control-- Can modify SNMP configuration
 82

system -- Can view system configuration

system-control-- Can modify system configuration
trace -- Can view trace file settings
trace-control-- Can modify trace file settings
view -- Can view current values and statistics
maintenance -- Can become the super-user
firewall -- Can view firewall configuration
firewall-control-- Can modify firewall configuration
secret -- Can view secret statements
secret-control-- Can modify secret statements
rollback -- Can rollback to previous configurations
security -- Can view security configuration
security-control-- Can modify security configuration
access -- Can view access configuration
access-control-- Can modify access configuration
view-configuration-- Can view all configuration (not including secrets)
flow-tap -- Can view flow-tap configuration
flow-tap-control-- Can modify flow-tap configuration
idp-profiler-operation-- Can Profiler data
pgcp-session-mirroring-- Can view pgcp session mirroring configuration
pgcp-session-mirroring-control-- Can modify pgcp session mirroring configura
tion
storage -- Can view fibre channel storage protocol configuration
storage-control-- Can modify fibre channel storage protocol configuration
all-control -- Can modify any configuration
Individual command authorization:
Allow regular expression: none
Deny regular expression: none
Allow configuration regular expression: none
Deny configuration regular expression: none

This output summarizes the login permissions.

Configuring a Local Administrator Account

The following example shows how to configure a password- protected local administration account called
admin with superuser privileges. Superuser privileges give a user permission to use any command on the
router and are generally reserved for a select few users such as system administrators. It is important to
protect the local administrator account with a password to prevent unauthorized users from gaining access
to superuser commands that can be used to alter the system configuration. Even users with RADIUS
 83

authentication should configure a local password. If RADIUS fails or becomes unreachable, the login process
will revert to password authentication on the local administrator account.

[edit]
system {
login {
user admin {
uid 1000;
class superuser;
authentication {
encrypted-password "<PASSWORD>"; # SECRET-DATA
}
}
}
}

RELATED DOCUMENTATION

Junos OS Login Classes Overview | 37

Configuring Junos OS User Accounts by Using a Configuration Group | 68

Junos OS User Access Privileges

IN THIS SECTION

Understanding Junos OS Access Privilege Levels | 84

Example: Configuring User Permissions with Access Privilege Levels | 89

Regular Expressions for Allowing and Denying Junos OS Operational Mode Commands, Configuration
Statements, and Hierarchies | 94

Examples of Defining Access Privileges Using allow-configuration and deny-configuration Statements | 105

Example: Using Additive Logic With Regular Expressions to Specify Access Privileges | 108

Example: Configuring User Permissions with Access Privileges for Operational Mode Commands | 111

Example: Configuring User Permissions with Access Privileges for Configuration Statements and
Hierarchies | 126
 84

Junos OS allows you to grant the access or permissions to the commands and configuration hierarchy
levels and statements. This enables users to execute only those commands and configure and view only
those statements for which they have access privileges. You can use extended regular expressions to
specify which operational mode commands, configuration statements, and hierarchies are denied or allowed
for users. This prevents unauthorized users from executing or configuring sensitive commands and
statements that could potentially cause damage to the network. Read this topic for more information.

Understanding Junos OS Access Privilege Levels

IN THIS SECTION

Junos OS Login Class Permission Flags | 84

Allowing or Denying Individual Commands for Junos OS Login Classes | 88

Each top-level CLI command and each configuration statement have an access privilege level associated
with them. Users can execute only those commands and configure and view only those statements for
which they have access privileges. The access privileges for each login class are defined by one or more
permission flags.

For each login class, you can explicitly deny or allow the use of operational and configuration mode
commands that would otherwise be permitted or not allowed by a privilege level specified in the permissions
statement.

The following sections provide additional information about permissions:

Junos OS Login Class Permission Flags

Permission flags are used to grant a user access to operational mode commands and configuration hierarchy
levels and statements. By specifying a specific permission flag on the user's login class at the [edit system
login class] hierarchy level, you grant the user access to the corresponding commands and configuration
hierarchy levels and statements. To grant access to all commands and configuration statements, use the
all permissions flag.

NOTE: Each command listed represents that command and all subcommands with that command
as a prefix. Each configuration statement listed represents the top of the configuration hierarchy
to which that flag grants access.
 85

The permissions statement specifies one or more of the permission flags listed in Table 5 on page 85.
Permission flags are not cumulative, so for each class you must list all the permission flags needed, including
view to display information and configure to enter configuration mode. Two forms of permissions control
for individual parts of the configuration are:

• "Plain” form—Provides read-only capability for that permission type. An example is interface.

• Form that ends in -control—Provides read and write capability for that permission type. An example is
interface-control.

For permission flags that grant access to configuration hierarchy levels and statements, the flags grant
read-only privilege to that configuration. For example, the interface permissions flag grants read-only
access to the [edit interfaces] hierarchy level. The -control form of the flag grants read-write access to
that configuration. Using the preceding example, interface-control grants read-write access to the [edit
interfaces] hierarchy level.

Table 5 on page 85 lists the Junos OS login class permission flags that you can configure by including the
permissions statement at the [edit system login class class-name] hierarchy level.

The permission flags grant a specific set of access privileges. Each permission flag is listed with the
operational mode commands and configuration hierarchy levels and statements for which that flag grants
access.

Table 5: Login Class Permission Flags

Permission Flag Description

“access” on page 652 Can view the access configuration in configuration mode and with the show
configuration operational mode command.

“access-control” on page 657 Can view and configure access information at the [edit access] hierarchy level.

“admin” on page 658 Can view user account information in configuration mode and with the show
configuration operational mode command.

“admin-control” on page 664 Can view user account information and configure it at the [edit system]
hierarchy level.

“all-control” on page 665 Can view user accounts and configure them at the [edit system login] hierarchy
level.

all Can access all operational mode commands and configuration mode commands.
Can modify configuration in all the configuration hierarchy levels.

“clear” on page 666 Can clear (delete) information learned from the network that is stored in various
network databases by using the clear commands.
 86

Table 5: Login Class Permission Flags (continued)

Permission Flag Description

“configure” on page 767 Can enter configuration mode by using the configure command.

“control” on page 768 Can perform all control-level operations—all operations configured with the
-control permission flags.

“field” on page 769 Can view field debug commands. Reserved for debugging support.

“firewall” on page 770 Can view the firewall filter configuration in configuration mode.

“firewall-control” on page 775 Can view and configure firewall filter information at the [edit firewall] hierarchy
level.

“floppy” on page 776 Can read from and write to the removable media.

“flow-tap” on page 777 Can view the flow-tap configuration in configuration mode.

“flow-tap-control” on page 782 Can view the flow-tap configuration in configuration mode and can configure
flow-tap configuration information at the [edit services flow-tap] hierarchy
level.

“flow-tap-operation” on page 783 Can make flow-tap requests to the router or switch. For example, a Dynamic
Tasking Control Protocol (DTCP) client must have flow-tap-operation
permission to authenticate itself to the Junos OS as an administrative user.

NOTE: The flow-tap-operation option is not included in the all-control

permissions flag.

“idp-profiler-operation” on page 784 Can view profiler data.

“interface” on page 784 Can view the interface configuration in configuration mode and with the show
configuration operational mode command.

“interface-control” on page 790 Can view chassis, class of service (CoS), groups, forwarding options, and
interfaces configuration information. Can edit configuration at the following
hierarchy levels:

• [edit chassis]
• [edit class-of-service]
• [edit groups]
• [edit forwarding-options]
• [edit interfaces]
 87

Table 5: Login Class Permission Flags (continued)

Permission Flag Description

“maintenance” on page 791 Can perform system maintenance, including starting a local shell on the router
or switch and becoming the superuser in the shell by using the su root
command, and can halt and reboot the router or switch by using the request
system commands.

“network” on page 804 Can access the network by using the ping, ssh, telnet, and traceroute
commands.

“pgcp-session-mirroring” on Can view the pgcp session mirroring configuration.

page 807

“pgcp-session-mirroring-control” Can modify the pgcp session mirroring configuration.

on page 812

“reset” on page 812 Can restart software processes by using the restart command and can configure
whether software processes are enabled or disabled at the [edit system
processes] hierarchy level.

“rollback” on page 814 Can use the rollback command to return to a previously committed
configuration other than the most recently committed one.

“routing” on page 814 Can view general routing, routing protocol, and routing policy configuration
information in configuration and operational modes.

“routing-control” on page 825 Can view general routing, routing protocol, and routing policy configuration
information and can configure general routing at the [edit routing-options]
hierarchy level, routing protocols at the [edit protocols] hierarchy level, and
routing policy at the [edit policy-options] hierarchy level.

“secret” on page 831 Can view passwords and other authentication keys in the configuration.

“secret-control” on page 837 Can view passwords and other authentication keys in the configuration and
can modify them in configuration mode.

“security” on page 839 Can view security configuration in configuration mode and with the show
configuration operational mode command.

“security-control” on page 849 Can view and configure security information at the [edit security] hierarchy
level.

“shell” on page 854 Can start a local shell on the router or switch by using the start shell command.
 88

Table 5: Login Class Permission Flags (continued)

Permission Flag Description

“snmp” on page 855 Can view Simple Network Management Protocol (SNMP) configuration
information in configuration and operational modes.

“snmp-control” on page 860 Can view SNMP configuration information and can modify SNMP configuration
at the [edit snmp] hierarchy level.

“system” on page 861 Can view system-level information in configuration and operational modes.

“system-control” on page 869 Can view system-level configuration information and configure it at the [edit
system] hierarchy level.

“trace” on page 871 Can view trace file settings and configure trace file properties.

“trace-control” on page 883 Can modify trace file settings and configure trace file properties.

“view” on page 890 Can use various commands to display current system-wide, routing table, and
protocol-specific values and statistics. Cannot view the secret configuration.

“view-configuration” on page 1040 Can view all of the configuration excluding secrets, system scripts, and event
options.

NOTE: Only users with the maintenance permission can view commit script,
op script, or event script configuration.

Allowing or Denying Individual Commands for Junos OS Login Classes

By default, all top-level CLI commands have associated access privilege levels. Users can execute only
those commands and view only those statements for which they have access privileges. For each login
class, you can explicitly deny or allow the use of operational and configuration mode commands that would
otherwise be permitted or not allowed by a privilege level specified in the permissions statement.

Permission flags are used to grant a user access to operational mode commands and configuration hierarchy
levels and statements. By specifying a specific permission flag on the user's login class at the [edit system
login class] hierarchy level, you grant the user access to the corresponding commands and configuration
hierarchy levels and statements. To grant access to all commands and configuration statements, use the
all permissions flag. For permission flags that grant access to configuration hierarchy levels and statements,
the flags grant read-only privilege to that configuration. For example, the interface permissions flag grants
read-only access to the [edit interfaces] hierarchy level. The -control form of the flag grants read-write
access to that configuration. Using the preceding example, interface-control grants read-write access to
the [edit interfaces] hierarchy level.
 89

• The all login class permission bits take precedence over extended regular expressions when a user issues
rollback command with rollback permission flag enabled.

• Expressions used to allow and deny commands for users on RADIUS and TACACS+ servers have been
simplified. Instead of a single, long expression with multiple commands (allow-commands=cmd1 cmd2
... cmdn), you can specify each command as a separate expression. This new syntax is valid for
allow-configuration, deny-configuration, allow-commands, deny-commands, and all user permission
bits.

• Users cannot issue the load override command when specifying an extended regular expression. Users
can only issue the merge, replace, and patch configuration commands.

• If you allow and deny the same commands, the allow-commands permissions take precedence over the
permissions specified by the deny-commands. For example, if you include allow-commands "request
system software add" and deny-commands "request system software add", the login class user is allowed
to install software using the request system software add command.

• Regular expressions for allow-commands and deny-commands can also include the commit, load,
rollback, save, status, and update commands.

• If you specify a regular expression for allow-commands and deny-commands with two different variants
of a command, the longest match is always executed.

For example, if you specify a regular expression for allow-commands with the commit-synchronize
command and a regular expression for deny-commands with the commit command, users assigned to
such a login class would be able to issue the commit synchronize command, but not the commit command.
This is because commit-synchronize is the longest match between commit and commit-synchronize
and it is specified for allow-commands.

Likewise, if you specify a regular expression for allow-commands with the commit command and a
regular expression for deny-commands with the commit-synchronize command, users assigned to such
a login class would be able to issue the commit command, but not the commit-synchronize command.
This is because commit-synchronize is the longest match between commit and commit-synchronize
and it is specified for deny-commands.

Example: Configuring User Permissions with Access Privilege Levels

IN THIS SECTION

Requirements | 90

Overview | 90

Configuration | 91

Verification | 93
 90

This example shows how to view permissions for a user account and configure the user permissions with
access privileges for a login class. This enables users to execute only those commands and configure and
view only those statements for which they have access privileges. This prevents unauthorized users from
executing or configuring sensitive commands and statements that could potentially cause damage to the
network.

Requirements

This example uses the following hardware and software components:

• One Juniper Networks device

• One TACACS+ (or RADIUS) server

• Junos OS build running on the Juniper Networks device

Before you begin:

• Establish connection between the device and the TACACS+ server.

For information on configuring a TACACS+ server, see “Configuring TACACS+ Authentication” on

page 228.

• Configure at least one user assigned to a login class on the Juniper Networks device. There can be more
than one login class, each with varying permission configurations, and more than one user on the device.

Overview

Each top-level command-line interface (CLI) command and each configuration statement in Junos OS has
an access privilege level associated with it. For each login class, you can explicitly deny or allow the use
of operational and configuration mode commands that would otherwise be permitted or not allowed by
a privilege level. Users can execute only those commands and configure and view only those statements
for which they have access privileges. To configure access privilege levels, include the permissions statement
at the [edit system login class class-name] hierarchy level.

The access privileges for each login class are defined by one or more permission flags specified in the
permissions statement. Permission flags are used to grant a user access to operational mode commands,
statements, and configuration hierarchies. Permission flags are not cumulative, so for each login class you
must list all the permission flags needed, including view to display information and configure to enter
configuration mode. By specifying a specific permission flag on the user's login class, you grant the user
access to the corresponding commands, statements, and configuration hierarchies. To grant access to all
commands and configuration statements, use the all permissions flag. The permission flags provide read-only
(“plain” form) and read and write (form that ends in -control) capability for a permission type.
 91

NOTE: The all login class permission bits take precedence over extended regular expressions
when a user issues a rollback command with the rollback permission flag enabled.

To configure user access privilege levels:

1. View permissions for a user account.

You can view the permissions for a user account before configuring the access privileges for those
permissions.

To view the user permissions, enter ? at the [edit] hierarchy level:

[edit]
?

2. Configure user permissions with access privileges.

All users who can log in to a device must be in a login class. For each login class, you can configure the
access privileges that the associated users can have when they are logged in to the device.

To configure access privilege levels for user permissions, include the permissions statement at the [edit
system login class class-name] hierarchy level, followed by the user permission, the permissions option,
and the required permission flags.

[edit system login]

user@host# set class class-name permissions user-permission permissions [permission flags];

Configuration

Configuring User Permissions with Access Privilege Levels

Step-by-Step Procedure
To configure access privileges:

1. From the device, view the list of permissions available for the user account. In this example, the username
of the user account is host.

[edit]
user@host> ?
Possible completions:
clear Clear information in the system
configure Manipulate software configuration information
 92

file Perform file operations

help Provide help information
load Load information from file
monitor Show real-time debugging information
mtrace Trace multicast path from source to receiver
op Invoke an operation script
ping Ping remote target
quit Exit the management session
request Make system-level requests
restart Restart software process
save Save information to file
set Set CLI properties, date/time, craft interface message
show Show system information
ssh Start secure shell on another host
start Start shell
telnet Telnet to another host
test Perform diagnostic debugging
traceroute Trace route to remote host

The output lists the permissions for the user host. Customized login classes can be created by configuring
different access privileges on these user permissions.

2. Configure an access privilege class to enable user host to configure and view SNMP parameters only.
In this example, this login class is called network-management. To customize the network-management
login class, include the SNMP permission flags to the configure user permission.

[edit system login class network-management]

user@host# set permissions configure permissions snmp
user@host# set permissions configure permissions snmp-control

Here, the configured permission flags provide both read (snmp) and read-and-write (snmp-control)
capability for SNMP, and this is the only allowed access privilege for the network-management login
class. In other words, all other access privileges other than configuring and viewing SNMP parameters
are denied.

Results

From configuration mode, confirm your configuration by entering the show system login command. If the
output does not display the intended configuration, repeat the instructions in this example to correct the
configuration.

user@host# show system login

class network-management {
 93

permissions [ configure snmp snmp-control ];

}

Verification

IN THIS SECTION

Verifying SNMP Configuration | 93

Verifying non-SNMP Configuration | 93

Log in as the username assigned with the new login class, and confirm that the configuration is working
properly.

Verifying SNMP Configuration

Purpose
Verify that SNMP configuration can be executed.

Action

From configuration mode, execute basic SNMP commands at the [edit snmp] hierarchy level.

[edit snmp]
user@host# set name device1
user@host# set description switch1
user@host# set location Lab1
user@host# set contact example.com
user@host# commit

Meaning
The user host assigned to the network-management login class is able to configure SNMP parameters, as
the permission flags specified for this class include both snmp (read capabilities) and snmp-control (read
and write capabilities) permission bits.

Verifying non-SNMP Configuration

Purpose
Verify that non-SNMP configuration is denied for the network-management login class.

Action
 94

From the configuration mode, execute any non-SNMP configuration, for example, interfaces configuration.

[edit]
user@host# edit interfaces
Syntax error, expecting <statement> or <identifier>.

Regular Expressions for Allowing and Denying Junos OS Operational Mode

Commands, Configuration Statements, and Hierarchies

IN THIS SECTION

Understanding Regular Expressions | 94

Specifying Regular Expressions | 97

Regular Expressions Operators | 99

Regular Expression Examples | 102

This topic contains the following sections:

Understanding Regular Expressions

You can use extended regular expressions to specify which operational mode commands, configuration
statements, and hierarchies are denied or allowed. You specify these regular expressions locally in the
allow/deny-commands, allow/deny-configuration, and allow/deny-commands-regexps and
allow/deny-configuration-regexp statements at the [edit system login class class-name] hierarchy level,
or remotely by specifying Juniper Networks vendor-specific TACACS+ or RADIUS attributes in your
authorization server’s configuration.

NOTE: Starting in Junos OS Release 18.1, the allow-commands-regexps and

deny-commands-regexps statements are supported for TACACS+ authorization.

The difference between a local and remote authorization configuration is the pattern in which the regular
expressions statements are executed. While it is possible to specify multiple regular expressions using
strings in the local authorization configuration, in a remote configuration, the regular expressions statements
need to be split and specified in individual strings. When the authorization parameters are configured both
 95

remotely and locally, the regular expressions received during TACACS+ or RADIUS authorization get
merged with any regular expressions available on the local device.

When specifying multiple regular expressions in a local configuration using the allow-configuration,
deny-configuration, allow-commands, or deny-commands statements, regular expressions are configured
within parentheses and separated using the pipe symbol. The complete expression is enclosed in double
quotes. For example, you can specify multiple allow-commands parameters with the following syntax:

allow-commands "(cmd1)|(cmd2)|(cmdn)"

The same expression configured remotely on the authorization server uses the following syntax:

allow-commands1 = "cmd1"
allow-commands2 = "cmd2"
allow-commandsn = "cmdn"

When specifying multiple regular expressions in a local configuration using the allow-configuration-regexps,
deny-configuration-regexps, allow-commands-regexps, or deny-commands-regexps statements, regular
expressions are configured within double quotes and separated using the space operator. The complete
expression is enclosed in square brackets. For example, you can specify multiple allow-commands parameters
with the following syntax:

allow-commands-regexps [ "cmd1" "cmd2" "cmdn" ]

The same expression configured remotely on the authorization server uses the following syntax:

allow-commands-regexps1 = "cmd1"
allow-commands-regexps2 = "cmd2"
allow-commands-regexpsn = "cmdn"

Table 6 on page 96 differentiates the local and remote authorization configuration using regular expressions.
 96

Table 6: Sample Local and Remote Authorization Configuration Using Regular Expressions

Local Configuration Remote Configuration

login { user = remote {

class local { login = username
permissions configure; service = junos-exec {
allow-commands "(ping .*)|(traceroute allow-commands1 = "ping .*"
.*)|(show .*)|(configure allow-commands2 = "traceroute .*"
.*)|(edit)|(exit)|(commit)|(rollback .*)"; allow-commands3 = "show .*"
deny-commands .*; allow-commands4 = "configure"
allow-configuration "(interfaces .* unit allow-commands5 = "edit"
0 family ethernet-switching vlan allow-commands6 = "exit"
mem.* .*)|(interfaces .* native.* allow-commands7 = "commit"
.*)|(interfaces .* unit 0 family allow-commands8 = ".*xml-mode" <<<<<
ethernet-switching interface-mo.* allow-commands9 = ".*netconf" <<<<<
.*)|(interfaces .* unit .*)|(interfaces .* allow-commands10 = ".*need-trailer" <<<<<
disable)|(interfaces .* description allow-commands11 = "rollback.*"
.*)|(vlans .* vlan-.* .*)" deny-commands1 = ".*"
deny-configuration .*; allow-configuration1 = "interfaces .* unit 0 family
} ethernet-switching vlan mem.* .*"
} allow-configuration2 = "interfaces .* native.* .*"
allow-configuration3 = "interfaces .* unit 0 family
ethernet-switching interface-mo.* .*"
allow-configuration4 = "interfaces .* unit .*"
allow-configuration5 = "interfaces .* disable"
allow-configuration6 = "interfaces .* description .*"
allow-configuration7 = "interfaces .*"
allow-configuration8 = "vlans .* vlan-.* .*"
deny-configuration1 = ".*"
local-user-name = local-username
user-permissions = "configure"
}
}

NOTE:
• You need to explicitly allow access to the NETCONF mode, either locally or remotely, by
issuing the following three commands: xml-mode, netconf, and need-trailer.

• When the deny-configuration = “.*” statement is used, all the other desired configurations
should be allowed using the allow-configuration statement. This can affect the allowed regular
expressions buffer limit for the allow-configuration statement. When this limit exceeds, the
allowed configuration might not work. This regular expression buffer size limit has been
increased in Junos OS Release 14.1x53-D40, 15.1, and 16.1.
 97

Specifying Regular Expressions

WARNING: When you specify regular expression for commands and configuration
statements, pay close attention to the following examples, as regular expression with
invalid syntax might not produce the desired results, even if the configuration is
committed without any error.

Regular expressions for commands and configuration statements should be specified in the same manner
as executing the complete command or statement. Table 7 on page 98 lists the regular expressions for
configuring access privileges for the [edit interfaces] and [edit vlans] statement hierarchies, and for the
delete interfaces command.
 98

Table 7: Specifying Regular Expressions

Statement Regular Expression Configuration Notes

[edit interfaces] The set interfaces statement is • The .* operator denotes everything from
incomplete by itself, and requires the the specified point onward for that
The set command for
unit option to execute the statement. particular command or statement. In this
interfaces is executed as
example, it denotes any interface name
follows: As a result, the regular expression
with any unit value.
required for denying the set interfaces
[edit] • Specifying only the deny-configuration
configuration must specify the entire
user@host# set interfaces "interfaces .*" statement is incorrect and
executable string with the .* operator
interface-name unit does not deny access to the interfaces
in place of statement variables:
interface-unit-number configuration for the specified login class.
[edit system login class class-name] • Other valid options can be included in the
user@host# set permissions regular expression, for example:
configure
[edit system login class class-name]
user@host# set deny-configuration
user@host# set permissions configure
"interfaces .* unit .*"
user@host# set deny-configuration
"interfaces .* description .*"

[edit system login class class-name]

user@host# set permissions configure
user@host# set
allow-configuration-regexps [
"interfaces .* description .*” “interfaces
.* unit .* description .*” “interfaces .*
unit .* family inet address .*”
“interfaces.* disable" ]

[edit system login class class-name]

user@host# set permissions configure
user@host# set allow-configuration
"interfaces .* unit 0 family
ethernet-switching vlan mem.* .*"

Note: The mem.* regular expression in

this example is used when multiple strings
starting with the mem keyword are
expected to be included in the specified
regular expression. When only one
member string is expected to be included,
the member .* regular expression is used.
 99

Table 7: Specifying Regular Expressions (continued)

Statement Regular Expression Configuration Notes

delete interfaces The delete interfaces statement can • The .* operator denotes everything from
be executed by itself and does not the specified point onward for that
The delete command for
require additional statements to be particular command or statement. In this
interfaces is executed as
complete. example, it denotes any interface name.
follows:
• For the deny-configuration "interfaces
As a result, the regular expression
[edit] .*" regular expression to take effect, the
required for denying the delete
user@host# delete specified login class should allow
interfaces statement should specify
interfaces interface-name configuration permissions for the
the following:
interfaces hierarchy using the
[edit system login class class-name] allow-configuration "interfaces .*" regular
user@host# set permissions expression.
configure
user@host# set allow-configuration
"interfaces .*"
user@host# set deny-configuration
"interfaces .*"

[edit vlans] Here, the set vlans statement is • The .* operator denotes everything from
incomplete by itself, and requires the the specified point onward for that
The set command for VLANs
vlan-id option to execute the particular command or statement. In this
is executed as follows:
statement. example, it denotes any VLAN name with

[edit] any VLAN ID.

As a result, the regular expression
user@host# set vlans • Other valid options under the [edit vlans]
required for allowing the set vlans
vlan-name vlan-id vlan-id statement hierarchy can be included in
configuration must specify the entire
the regular expression, for example:
executable string with the .* operator
in place of statement variables: [edit system login class class-name]
user@host# set permissions configure
[edit system login class class-name]
user@host# set
user@host# set permissions
allow-configuration-regexps [ "vlans
configure
.* vlan-id .*" "vlans .* vlan-id .*
user@host# set allow-configuration
description .*" "vlans .* vlan-id .* filter
"vlans .* vlan-id .*"
.*" ]

Regular Expressions Operators

Table 8 on page 100 lists common regular expression operators that you can use for allowing or denying
operational and configuration modes.

Command regular expressions implement the extended (modern) regular expressions, as defined in POSIX
1003.2.
 100

Table 8: Common Regular Expression Operators

Operator Match Example

| One of two or [edit system login class test]

more terms user@host# set permissions configure
separated by user@host# set allow-commands "(ping)|(traceroute)|(show system alarms)|(show
the pipe. Each system software)"
term must be a user@host# set deny-configuration
complete "(access)|(access-profile)|(accounting-options)|(applications)|(apply-groups)|
standalone (bridge-domains)|(chassis)|(class-of-service)"
expression
With the above configuration, the users assigned to the test login class have operational
enclosed in
mode access restricted to only the commands specified in the allow-commands
parentheses ( ),
statement, and access to the configuration mode, excluding the hierarchy levels
with no spaces
specified in the deny-configuration statement.
between the
pipe and the
adjacent
parentheses.

^ At the [edit system login class test]

beginning of user@host# set permissions interface
an expression, user@host# set permissions interface-control
used to denote user@host# set allow-commands "(^show) (log|interfaces|policer))|(^monitor)"
where the
With the above configuration, the users assigned to the test login class have access
command
to configuring and viewing interface configuration from the operational and
begins, where
configuration mode. The allow-commands statement specifies access to commands
there might be
that begin with show and monitor keywords.
some
ambiguity. For the first filter, the commands specified include the show log, show interfaces, and
show policer commands. The second filter specifies all commands starting with the
monitor keyword, such as monitor interfaces or monitor traffic commands.

$ Character at [edit system login class test]

the end of a user@host# set permissions interface
command. user@host# set allow-commands "(show interfaces$)"
Used to
With the above configuration, the users assigned to the test login class can view the
denote a
interface configuration in the configuration mode and with the show configuration
command that
operational mode command with the interface user permission. However, the regular
must be
expression specified in the allow-commands statement restricts the users to execute
matched
only the show interfaces command and denies access to the command extensions,
exactly up to
such as show interfaces detail or show interfaces extensive.
that point.
 101

Table 8: Common Regular Expression Operators (continued)

Operator Match Example

[] Range of [edit system login class test]

letters or user@host# set permissions clear
digits. To user@host# set permissions configure
separate the user@host# set permissions network
start and end user@host# set permissions trace
of a range, use user@host# set permissions view
a hyphen ( - ). user@host# set allow-configuration-regexps [ "interfaces [gx]e-.* unit [0-9]* description
.*" ]

With the above configuration, the users assigned to the test login class have
operator-level user permissions, and have access to configure interfaces within the
specified range of interface name and unit number (0 through 9).

() A group of [edit system login class test]

commands, user@host# set permissions all
indicating a user@host# set allow-commands "(clear)|(configure)"
complete, user@host# deny-commands "(mtrace)|(start)|(delete)"
standalone
With the above configuration, users assigned to the test login class have superuser-level
expression to
permissions, and have access to the commands specified in the allow-commands
be evaluated.
statement.
The result is
then evaluated
as part of the
overall
expression.
Parentheses
must be used
in conjunction
with pipe
operators, as
explained.

* Zero or more [edit system login class test]

terms. user@host# set permissions configure
user@host# set deny-configuration "(system login class m*)"

With the above configuration, users assigned to the test login class whose login
username begins with m are denied configuration access.
 102

Table 8: Common Regular Expression Operators (continued)

Operator Match Example

+ One or more [edit system login class test]

terms. user@host# set permissions configure
user@host# set deny-configuration "(system login class m+)"

With the above configuration, users assigned to the test login class whose login
username begins with m are denied configuration access.

. Any character [edit system login class test]

except for a user@host# set permissions configure
space " ". user@host# set deny-configuration "(system login class m.)"

With the above configuration, users assigned to the test login class whose login
username begins with m are denied configuration access.

.* Everything [edit system login class test]

from the user@host# set permissions configure
specified point user@host# set deny-configuration "(system login class m .*)"
onward.
With the above configuration, users assigned to the test login class whose login
username begins with m are denied configuration access.

Similarly, the deny-configuration "protocols .*" statement denies all configuration

access under the [edit protocols] hierarchy level.

NOTE:
• The *, +, and . operations can be achieved by using .*.
• The deny-commands .* and deny-configuration .* statements deny access to all
operational mode commands and configuration hierarchies, respectively.

NOTE: Junos OS does not support the ! regular expression operator.

Regular Expression Examples

Table 9 on page 103 lists the regular expressions used to allow configuration options under two configuration
hierarchies—[edit system ntp server] and [edit protocols rip]—as an example for specifying regular
expressions.
 103

NOTE: Table 9 on page 103 does not provide a comprehensive list of all regular expressions and
keywords for all configuration statements and hierarchies. The regular expressions listed in the
table are supported in Junos OS Release 16.1, and are validated only for the [edit system ntp
server] and [edit protocols rip] statement hierarchies.

Table 9: Regular Expressions Examples

Statement Allowed Denied

Hierarchy Regular Expressions Configuration Configuration

[edit system ntp

server]

key key-number [edit system login class test] • server IP • version

set permissions configure • server IP and key • prefer
set allow-configuration-regexps [ "system
ntp server .*" "system ntp server .* key
.*" ]
set deny-configuration-regexps [ "system
ntp server .* version .*" "system ntp
server .* prefer" ]

version [edit system login class test] • server IP • key

version-number set permissions configure • server IP and • prefer
set allow-configuration-regexps [ "system version
ntp server .*" "system ntp server .*
version .*" ]
set deny-configuration-regexps [ "system
ntp server .* key .*" "system ntp server
.* prefer" ]

prefer [edit system login class test] • server IP • key

set permissions configure • server IP and prefer • version
set allow-configuration-regexps [ "system
ntp server .*" "system ntp server .*
prefer" ];
set deny-configuration-regexps [ "system
ntp server .* key .*" "system ntp server
.* version .*" ]

[edit protocols rip]

 104

Table 9: Regular Expressions Examples (continued)

Statement Allowed Denied

Hierarchy Regular Expressions Configuration Configuration

message-size [edit system login class test] • message-size • metric-in

message-size set permissions configure • route-timeout
set allow-configuration-regexps "protocols
• update-interval
rip message-size .*"
set deny-configuration-regexps [ "protocols
rip metric-in .*" "protocols rip
route-timeout .*" "protocols rip
update-interval .*" ]

metric-in metric-in [edit system login class test] • metric-in • message-size

set permissions configure • route-timeout
set allow-configuration-regexps "protocols
• update-interval
rip metric-in .*"
set deny-configuration-regexps [ "protocols
rip message-size .*" "protocols rip
route-timeout .*" "protocols rip
update-interval .*" ]

route-timeout [edit system login class test] • route-timeout • message-size

route-timeout set permissions configure • metric-in
set allow-configuration-regexps "protocols
• update-interval
rip route-timeout .*"
set deny-configuration-regexps [ "protocols
rip metric-in .*" "protocols rip
message-size .*" "protocols rip
update-interval .*" ]

update-interval [edit system login class test] • update-interval • message-size

update-interval set permissions configure • metric-in
set allow-configuration-regexps "protocols
• route-timeout
rip update-interval .*"
set deny-configuration-regexps [ "protocols
rip metric-in .*" "protocols rip
route-timeout .*" "protocols rip
message-size .*" ]
 105

Examples of Defining Access Privileges Using allow-configuration and

deny-configuration Statements

You can define access privileges using a combination of the following types of statements:

• permission flags

• allow-configuration and deny-configuration statements

The permission flags define the larger boundaries of what a person or login class can access and control.
The allow-configuration and deny-configuration statements take precedence over permission flags and
give the administrator finer control over exactly what the user has access to.

This topic explains defining access privileges using allow-configuration and deny-configuration statements
by showing a series of examples of login class configuration using these statements. Examples 1 through
3 use both permission flags and deny-configuration statements to create login classes that allow users
access to all except something. Each allow-configuration or deny-configuration statement is configured
with one or more regular expressions to be allowed or denied.

Notice that permission bit and permission flag are used interchangeably.

Example 1

To create a login class that allows the user to configure everything except telnet parameters:

1. Set the user’s login class permission bit to all.

[edit system login]

user@host# set class all-except-telnet permissions all

2. Include the following deny-configuration statement.

[edit system login class all-except-telnet]

user@host# set deny-configuration "system services telnet"

Example 2
 106

To create a login class that allows the user to configure everything except anything within any login class
whose name begins with “m”:

1. Set the user’s login class permission bit to all.

[edit system login]

user@host# set class all-except-login-class-m permissions all

2. Include the following deny-configuration statement.

[edit system login class all-except-login-class-m]

user@host# set deny-configuration "system login class m.*"

Example 3

This next example shows the creation of a login class with the all permission bit that prevents the user
from editing a configuration or issuing commands (such as commit) at the [edit system login class] or [edit
system services] hierarchy levels:

To create a login class that allows the user to configure everything except at the [edit system login class]
or [edit system services] hierarchy levels:

1. Set the user’s login class permission bit to all.

[edit system login]

user@host# set class all-except-login-class-or-system-services permissions all

2. Include the following deny-configuration statement.

[edit system login class all-except-login-class-or-system-services]

user@host# set deny-configuration "(system login class) | (system services)"

The next two examples show how to use the allow-configuration and deny-configuration statements to
determine permissions inverse to each other for the [edit system services] hierarchy level.
 107

Example 4

To create a login class that allows the user to have full configuration privileges at the [edit system services]
hierarchy level and at only the [edit system services] hierarchy level:

1. Set the user’s login class permission bit to configure.

[edit system login]

user@host# set class configure-only-system-services permissions configure

2. Include the following allow-configuration statement.

[edit system login class configure-only-system-services]

user@host# set allow-configuration "system services"

Example 5

To create a login class that allows the user full permissions for all configuration mode hierarchies except
the [edit system services] hierarchy level:

1. Set the user’s login class permission bit to all.

[edit system login]

user@host# set class all-except-system-services permissions all

2. Include the following deny-configuration statement.

[edit system login class all-except-system-services]

user@host# set deny-configuration "system services"
 108

Example: Using Additive Logic With Regular Expressions to Specify Access

Privileges

IN THIS SECTION

Requirements | 108

Overview | 108

Configuration | 109

Examples | 109

This example shows how to use additive logic when using regular expressions to set up configuration
access privileges.

Requirements

This example uses the following hardware and software components:

• One Juniper Networks J Series, M Series, MX Series, or T Series device

• Junos OS Release 16.1 or later

• There must be at least one user assigned to a login class.

• There can be more than one login class, each with varying permission configurations, and more than
one user on the device.

Overview

To control who can make configuration changes to the system, and what specifically they can change, you
can create regular expressions that indicate specific portions of the configuration hierarchy that users in
a named user class are permitted to access. For example, you can create regular expressions that specify
a group of routing instances that users are allowed to modify, and prevent the users from making changes
to any other routing instances, or to any other configuration level.

You configure regular expressions using the allow-configuration-regexps and deny-configuration-regexps

statements. By default, deny-configuration-regexps statements take precedence over
allow-configuration-regexps statements for users in the named user class to which they are applied.

If a configuration hierarchy appears in a deny-configuration-regexps statement for a named user class, it

is not visible to the users, regardless of the contents of the allow-configuration-regexps statement. If a
 109

configuration hierarchy does not appear in a deny-configuration-regexps statement, it is visible if it appears

in an allow-configuration-regexps statement, or if there is no allow-configuration-regexps statement
configured for the user class..

You can optionally change this default behavior so additive logic (that is, deny all by default / allow some
as specified) is used in regular expressions. When additive logic is enabled, the behavior of existing regular
expressions changes so that all configuration hierarchies are denied unless they are included in an
allow-configuration-regexps statement for the named user class.

Configuration

To enable additive logic for regular expressions:

1. To explicitly allow one or more individual configuration mode hierarchies, include the
allow-configuration-regexps statement at the [edit system login class class-name] hierarchy level,
configured with the regular expressions to be allowed.

[edit system login class class-name]

user@host# set allow-configuration-regexps "regular expression 1" "regular expression 2" "regular expression
3" "regular expression 4" ...

2. Assign the login class to one or more users.

[edit system login]

user@host# set user username class class-name

3. Enable additive logic for regular expressions.

[edit system]
user@host# set regex-additive-logic

4. Commit your changes.

Users assigned this login class have access to the configuration hierarchies included in the
allow-configuration-regexps statement, but no others.

Examples

Using Regular Expressions with Additive Logic

Purpose
 110

This section provides examples of regular expressions that use additive logic to give you ideas for creating
configurations appropriate for your system.

Allow Specific Routing Instances

The following example login class includes a regular expression that allows configuration of routing instances
whose names start with CUST-VRF-; for example, CUST-VRF-1, CUST-VRF-25, CUST-VRF-100, and so
on:

[edit system login class class-name]

user@host# set permissions configure view view-configuration
user@host# set allow-configuration-regexps "routing-instances CUST-VRF-.* .*"

If the following statement is included in the configuration, it prevents the user from configuring any other
routing instances and denies access to any non-routing instance configuration hierarchy:

[edit system]
user@host# set regex-additive-logic

Allow BGP Peer Configuration Only

The following example login class includes a regular expression that allows configuration of BGP peers:

[edit system login class class-name]

user@host# set permissions configure view view-configuration
user@host# set allow-configuration-regexps "protocols bgp group *"

If the following statement is included in the configuration, it prevents the user from making any other
changes, such as deleting or disabling BGP statements:

[edit system]
user@host# set regex-additive-logic

Verification
 111

To verify that you have set the access privileges correctly:

1. Configure a login class and commit the changes.

2. Assign the login class to a username.

3. Log in as the username assigned with the new login class.

4. Attempt to perform the configurations that have been allowed.

• You should be able to perform configuration changes to hierarchy levels and regular expressions that
have been allowed.

• All other hierarchies should not be visible.

• Any allowed or denied expressions should take precedence over any permissions granted with the
permissions statement.

Example: Configuring User Permissions with Access Privileges for

Operational Mode Commands

IN THIS SECTION

Requirements | 112

Overview and Topology | 112

Configuration | 116

Verification | 122

This example shows how to configure custom login classes and assign access privileges for operational
mode commands. This enables users of the customized login class to execute only those operational
commands for which access privileges have been specified. This prevents unauthorized users from executing
sensitive commands that could potentially cause damage to the network.
 112

Requirements

This example uses the following hardware and software components:

• One Juniper Networks device

• One TACACS+ (or RADIUS) server

• Junos OS build running on the Juniper Networks device

Before you begin:

• Establish a TCP connection between the device and the TACACS+ server. In the case of the RADIUS
server, establish a UDP connection between the device and the RADIUS server.

For information on configuring a TACACS+ server, see “Configuring TACACS+ Authentication” on

page 228.

• Configure at least one user assigned to a login class on the Juniper Networks device. There can be more
than one login class, each with varying permission configurations, and more than one user on the device.

Overview and Topology

Each top-level command-line interface (CLI) command and each configuration statement in Junos OS has
an access privilege level associated with it. For each login class, you can explicitly deny or allow the use
of operational and configuration mode commands that would otherwise be permitted or not allowed by
a privilege level. Users can execute only those commands and configure and view only those statements
for which they have access privileges. To configure access privilege levels, include the permissions statement
at the [edit system login class class-name] hierarchy level.

The access privileges for each login class are defined by one or more permission flags specified in the
permissions statement. In addition to this, you can specify extended regular expressions with the following
statements:

• allow-commands and deny-commands—Allow or deny access to operational mode commands only.

• allow-configuration and deny-configuration—Allow or deny access to a particular configuration hierarchy

only.

• allow-configuration-regexps and deny-configuration-regexps—Allow or deny access to a particular

configuration hierarchy using strings of regular expressions.

• allow-commands-regexps and deny-commands-regexps—(TACACS+ authorization only) Allow or deny

access to a particular command using strings of regular expressions.

The above statements define a user’s access privileges to individual operational mode commands,
configuration statements, and hierarchies. These statements take precedence over the login class permissions
set for a user.
 113

Configuration Notes

When configuring the allow-commands, deny-commands, allow-configuration, and deny-configuration

statements with access privileges, take the following into consideration:

• You can include the allow/deny statement only once in each login class.

• If the exact same command is configured under both allow-commands and deny-commands statements,
or both allow-configuration and deny-configuration statements, then the allow operation takes
precedence over the deny statement.

For instance, with the following configuration, a user assigned to login class test is allowed to install
software using the request system software add command, although the deny-commands statement
also includes it:

[edit system login]

user@host# set class test permissions allow-commands "request system software add"
user@host# set class test permissions deny-commands "request system software add"

For instance, with the following configuration, a user assigned to login class test is allowed to access the
[edit system services] configuration hierarchy, although the deny-configuration statement also includes
it:

[edit system login]

user@host# set class test permissions allow-configuration "system services"
user@host# set class test permissions deny-configuration "system services"

• If you specify a regular expression for allow-commands and deny-commands statements with two
different variants of a command, the longest match is always executed.

For instance, for the following configuration, a user assigned to test login class is allowed to execute the
commit synchronize command and not the commit command. This is because commit-synchronize is
the longest match between commit and commit-synchronize, and it is specified for allow-commands.

[edit system login]

user@host# set class test allow-commands "commit-synchronize"
user@host# set class test deny-commands commit

• Regular expressions for allow-commands and deny-commands statements can also include the commit,
load, rollback, save, status, and update commands.

• Explicitly allowing configuration mode hierarchies or regular expressions using the allow-configuration
statement adds to the regular permissions set using the permissions statement. Likewise, explicitly
denying configuration mode hierarchies or regular expressions using the deny-configuration statement
removes permissions for the specified configuration mode hierarchy, from the default permissions
provided by the permissions statement.
 114

For example, for the following configuration, the login class user can edit the configuration at the [edit
system services] hierarchy level and issue configuration mode commands (such as commit), in addition
to just entering the configuration mode using the configure command, which is the permission specified
by the configure permission flag:

[edit system login]

user@host# set class test permissions configure allow-configuration "system services"

Likewise, for the following configuration, the login class user can perform all operations allowed by the
all permissions flag, except issuing configuration mode commands (such as commit) or modifying the
configuration at the [edit system services] hierarchy level:

[edit system login]

user@host# set class test permissions all deny-configuration "system services"

• The allow/deny-configuration statements are mutually exclusive with the

allow/deny-configuration-regexps statements, and the allow-deny-commands statements are mutually
exclusive with the allow/deny-commands-regexps statements. For example, you cannot configure both
allow-configuration and allow-configuration-regexps in the same login class.

• If you have existing configurations using the allow/deny-configuration or allow/deny-commands

statements, using the same configuration options with the allow/deny-configuration-regexps or
allow/deny-commands-regexps statements might not produce the same results, as the search and match
methods differ in the two forms of these statements.

• To define access privileges to parts of the configuration hierarchy, specify the full paths in the extended
regular expressions with the allow-configuration and deny-configuration statements. Use parentheses
around an extended regular expression that connects two or more expressions with the pipe (|) symbol.

For example:

[edit system login]

user@host# set class test deny-configuration "(system login class) | (system services)"

• If the regular expression contains any spaces, operators, or wildcard characters, enclose the expression
in quotation marks. Regular expressions are not case-sensitive; for example, allow-commands "show
interfaces".

• Modifiers such as set, log, and count are not supported within the regular expression string to be matched.
If a modifier is used, then nothing is matched.

Incorrect configuration:

[edit system login]

user@host# set class test permission deny-commands "set protocols"
 115

Correct configuration:

[edit system login]

user@host# set class test permission deny-commands protocols

• Anchors are required when specifying complex regular expressions with the allow-commands statement.

For example:

[edit system login]

user@host# set class test permissions allow-commands "(^monitor) | (^ping) | (^show) | (^exit)"

OR
set class test permissions allow-commands "allow-commands ="^(monitor | ping | show | exit)"

• When specifying extended regular expressions using the allow/deny-commands and

allow/deny-configuration statements, each expression separated by a pipe (|) symbol must be a complete
standalone expression, and must be enclosed in parentheses ( ). Do not use spaces between regular
expressions separated with parentheses and connected with the pipe (|) symbol.

For example:

[edit system login]

user@host# set class test allow-commands "(ping .*)|(traceroute .*)|(show .*)|(configure
.*)|(edit)|(exit)|(commit)|(rollback .*)"
user@host# set class test deny-configuration "(system login class)|(system services)"

• When specifying extended regular expressions using the allow/deny-configuration-regexps or

allow/deny-commands-regexps statement, each expression enclosed within quotes (") and separated
by a space must be enclosed in angular brackets [ ].

For example:

[edit system login]

user@host# set class test allow-configuration-regexps [ "interfaces .* description .*” “interfaces .* unit .* description
.*” “interfaces .* unit .* family inet address .*” “interfaces.* disable" ]

• You can use the * wildcard character when denoting regular expressions. However, it must be used as
a portion of a regular expression. You cannot use [ * ] or [ .* ] alone.

• You cannot configure the allow-configuration statement with the (interfaces (description (|.*)) regular
expression, as this evaluates to allow-configuration = .* regular expression.

• You can configure as many regular expressions as needed to be allowed or denied. Regular expressions
to be denied take precedence over configurations to be allowed.
 116

Topology

Figure 1: Configuring TACACS+ Server Authentication

10.209.1.66/24

TCP connection

g043487
R1 TACACS+
Server

Figure 1 on page 116 illustrates a simple topology, where Router R1 is a Juniper Networks device and has
a TCP connection established with a TACACS+ server.

In this example, R1 is configured with three customized login classes—Class1, Class2, and Class3—for
specifying access privileges with extended regular expressions using the allow-commands and
deny-commands statements differently.

The purpose of each login class is as follows:

• Class1—Defines access privileges for the user with the allow-commands statement only. This login class
provides operator-level user permissions, and should provide authorization for only rebooting the device.

• Class2—Defines access privileges for the user with the deny-commands statement only. This login class
provides operator-level user permissions, and should deny access to set commands.

• Class3—Defines access privileges for the user with both the allow-commands and deny-commands
statements. This login class provides superuser-level user permissions, and should provide authorization
for accessing interfaces and viewing device information. It should also deny access to edit and configure
commands.

Router R1 has three different users, User1, User2, and User3, assigned to Class1, Class2, and Class3 login
classes, respectively.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, copy and paste the
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

R1

set system authentication-order tacplus

set system authentication-order radius
 117

set system authentication-order password

set system radius-server 10.209.1.66 secret "$ABC123"
set system tacplus-server 10.209.1.66
set system radius-options enhanced-accounting
set system tacplus-options enhanced-accounting
set system accounting events login
set system accounting events change-log
set system accounting events interactive-commands
set system accounting traceoptions file auditlog
set system accounting traceoptions flag all
set system accounting destination tacplus server 10.209.1.66
set system login class Class1 permissions clear
set system login class Class1 permissions network
set system login class Class1 permissions reset
set system login class Class1 permissions trace
set system login class Class1 permissions view
set system login class Class1 allow-commands "request system reboot"
set system login class Class2 permissions clear
set system login class Class2 permissions network
set system login class Class2 permissions reset
set system login class Class2 permissions trace
set system login class Class2 permissions view
set system login class Class2 deny-commands set
set system login class Class3 permissions all
set system login class Class3 allow-commands configure
set system login class Class3 deny-commands .*
set system login user User1 uid 2001
set system login user User1 class Class1
set system login user User1 authentication encrypted-password "$ABC123"
set system login user User2 uid 2002
set system login user User2 class Class2
set system login user User2 authentication encrypted-password "$ABC123"
set system login user User3 uid 2003
set system login user User3 class Class3
set system login user User3 authentication encrypted-password "$ABC123"
set system syslog file messages any any

Configuring Authentication Parameters for Router R1

Step-by-Step Procedure
 118

The following example requires that you navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Router R1 authentication:

1. Configure the order in which authentication should take place for R1. In this example, TACACS+ server
authentication is first, followed by RADIUS server authentication, and then the local password.

[edit system]
user@R1# set authentication-order tacplus
user@R1# set authentication-order radius
user@R1# set authentication-order password

2. Establish R1 connection with the TACACS+ server.

[edit system]
user@R1# set tacplus-server 10.209.1.66
user@R1# set tacplus-options enhanced-accounting
user@R1# set accounting destination tacplus server 10.209.1.66

3. Configure RADIUS server authentication parameters.

[edit system]
user@R1# set radius-server 10.209.1.66 secret "$ABC123"
user@R1# set radius-options enhanced-accounting

4. Configure R1 accounting configuration parameters.

[edit system]
user@R1# set accounting events login
user@R1# set accounting events change-log
user@R1# set accounting events interactive-commands
user@R1# set accounting traceoptions file auditlog
user@R1# set accounting traceoptions flag all

Configuring Access Privileges with allow-commands Statement Only (Class1)

Step-by-Step Procedure
To specify regular expressions using the allow-commands statement only:

1. Configure Class1 custom login class and assign operator-level user permissions. For information on the
predefined system login classes, see the “Junos OS Login Classes Overview” on page 37.
 119

[edit system login]

user@R1# set class Class1 permissions clear
user@R1t# set class Class1 permissions network
user@R1# set class Class1 permissions reset
user@R1# set class Class1 permissions trace
user@R1# set class Class1 permissions view

2. Specify the command to enable rebooting of R1 in the allow-commands statement.

[edit system login]

user@R1# set class Class1 allow-commands "request system reboot"

3. Configure the user account for the Class1 login class.

[edit system login]

user@R1# set user User1 uid 2001
user@R1# set user User1 class Class1
user@R1# set user User1 authentication encrypted-password "$ABC123"

Configuring Access Privileges with deny-commands Statement Only (Class2)

Step-by-Step Procedure
To specify regular expressions using the deny-commands statement only:

1. Configure the Class2 custom login class and assign operator-level user permissions. For information
on the predefined system login classes, see the “Junos OS Login Classes Overview” on page 37.

[edit system login]

user@R1# set class Class1 permissions clear
user@R1# set class Class1 permissions network
user@R1# set class Class1 permissions reset
user@R1# set class Class1 permissions trace
user@R1# set class Class1 permissions view

2. Disable execution of any set commands in the deny-commands statement.

[edit system login]

user@R1# set class Class1 deny-commands "set"

3. Configure the user account for the Class2 login class.

 120

user@R1# set login user User2 uid 2002

user@R1# set login user User2 class Class2
user@R1# set login user User2 authentication encrypted-password "$ABC123"

Configuring Access Privileges with Both allow-commands and deny-commands Statements (Class3)

Step-by-Step Procedure
To specify regular expressions using both the allow-commands and deny-commands statements:

1. Configure the Class3 custom login class and assign superuser-level user permissions. For information
on the predefined system login classes, see the “Junos OS Login Classes Overview” on page 37.

[edit system login]

user@R1# set class Class3 permissions all

2. Specify the commands to enable only configure commands in the allow-commands statement.

[edit system login]

user@R1# set class Class3 allow-commands configure

3. Disable execution of all commands in the deny-commands statement.

[edit system login]

user@R1# set class Class3 deny-commands .*

4. Configure the user account for the Class1 login class.

[edit system login]

user@R1# set login user User3 uid 2003
user@R1# set login user User3 class Class3
user@R1# set login user User3 authentication encrypted-password "$ABC123"

Results

From configuration mode, confirm your configuration by entering the show system command. If the output
does not display the intended configuration, repeat the instructions in this example to correct the
configuration.

user@R1# show system

 121

authentication-order [ tacplus radius password ];

radius-server {
10.209.1.66 secret "$ABC123";
}
tacplus-server {
10.209.1.66;
}
radius-options {
enhanced-accounting;
}
tacplus-options {
enhanced-accounting;
}
accounting {
events [ login change-log interactive-commands ];
traceoptions {
file auditlog;
flag all;
}
destination {
tacplus {
server {
10.209.1.66;
}
}
}
}
login {
class Class1 {
permissions [ clear network reset trace view ];
allow-commands "request system reboot";
}
class Class2 {
permissions [ clear network reset trace view ];
deny-commands set;
}
class Class3 {
permissions all;
allow-commands configure;
deny-commands .*;
}
user User1 {
uid 2001;
class Class1;
 122

authentication {
encrypted-password "$ABC123";
}
}
user User2 {
uid 2002;
class Class2;
authentication {
encrypted-password "$ABC123";
}
}
user User3 {
uid 2003;
class Class3;
authentication {
encrypted-password “$ABC123”;
}
}
}
syslog {
file messages {
any any;
}
}

Verification

IN THIS SECTION

Verifying Class1 Configuration | 122

Verifying Class2 Configuration | 123

Verifying Class3 Configuration | 125

Log in as the username assigned with the new login class, and confirm that the configuration is working
properly.

Verifying Class1 Configuration

Purpose
Verify that the permissions and commands allowed in the Class1 login class are working.
 123

Action

From operational mode, run the show system users command.

User1@R1> show system users

12:39PM up 6 days, 23 mins, 6 users, load averages: 0.00, 0.01, 0.00

USER TTY FROM LOGIN@ IDLE WHAT
User1 p0 abc.example.net 12:34AM 12:04 cli
User2 p1 abc.example.net 12:36AM 12:02 -cli (cli)
User3 p2 abc.example.net 10:41AM 11 -cli (cli)

From operational mode, run the request system reboot command.

User1@R1> request system ?

Possible completions:
reboot Reboot the system

Meaning
The Class1 login class to which User1 is assigned has the operator-level user permissions, and is allowed
to execute the request system reboot command.

The predefined operator login class has the following permission flags specified:

• clear—Can clear (delete) information learned from the network that is stored in various network databases
by using the clear commands.

• network—Can access the network by using the ping, ssh, telnet, and traceroute commands.

• reset—Can restart software processes by using the restart command and can configure whether software
processes are enabled or disabled at the [edit system processes] hierarchy level.

• trace—Can view trace file settings and configure trace file properties.

• view—Can use various commands to display current system-wide, routing table, and protocol-specific
values and statistics. Cannot view the secret configuration.

For the Class1 login class, in addition to the above-mentioned user permissions, User1 can execute the
request system reboot command. The first output displays the view permissions as an operator, and the
second output shows that the only request command that User1 can execute as an operator is the request
system reboot command.

Verifying Class2 Configuration

Purpose
 124

Verify that the permissions and commands allowed for the Class2 login class are working.

Action

From the operational mode, run the ping command.

User2@R1> ping 10.209.1.66

ping 10.209.1.66
PING 10.209.1.66 (10.209.1.66): 56 data bytes
64 bytes from 10.209.1.66: icmp_seq=0 ttl=52 time=212.521 ms
64 bytes from 10.209.1.66: icmp_seq=1 ttl=52 time=212.844 ms
64 bytes from 10.209.1.66: icmp_seq=2 ttl=52 time=211.304 ms
64 bytes from 10.209.1.66: icmp_seq=3 ttl=52 time=210.963 ms
^C
--- 10.209.1.66 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 210.963/211.908/212.844/0.792 ms

From the CLI prompt, check the available permissions.

User2@R1> ?

Possible completions:
clear Clear information in the system
file Perform file operations
help Provide help information
load Load information from file
monitor Show real-time debugging information
mtrace Trace multicast path from source to receiver
op Invoke an operation script
ping Ping remote target
quit Exit the management session
request Make system-level requests
restart Restart software process
save Save information to file
show Show system information
ssh Start secure shell on another host
start Start shell
telnet Telnet to another host
 125

test Perform diagnostic debugging

traceroute Trace route to remote host

From the CLI prompt, execute any set command.

User2@R1> set

^
unknown command.

Meaning
The Class2 login class to which User2 is assigned has the operator-level user permissions, and is denied
access to all set commands. This is displayed in the command outputs.

The permission flags specified for the predefined operator login class are the same as that of Class1.

Verifying Class3 Configuration

Purpose
Verify that the permissions and commands allowed for the Class3 login class are working.

Action

From the CLI prompt, check the available permissions.

User3@R1> ?

Possible completions:
configure Manipulate software configuration information

From the operational mode, enter configuration mode.

User3@R1> configure

Entering configuration mode

[edit]
User3@R1#

Meaning
 126

The Class3 login class to which User3 is assigned has the superuser (all) user permissions, but is allowed
to execute the configure command only, and is denied access to all other operational mode commands.
Because the regular expressions specified in the allow/deny-commands statements take precedence over
the user permissions, User3 on R1 has access only to configuration mode, and is denied access to all other
operational mode commands.

Example: Configuring User Permissions with Access Privileges for

Configuration Statements and Hierarchies

IN THIS SECTION

Requirements | 126

Overview and Topology | 127

Configuration | 133

Verification | 138

This example shows how to configure custom login classes and assign access privileges to portions of the
configuration hierarchy. This enables users of the customized login class to execute only those configuration
statements and hierarchies for which access privileges have been specified. This prevents unauthorized
users from accessing device configurations that could potentially cause damage to the network.

Requirements

This example uses the following hardware and software components:

• One Juniper Networks device

• One TACACS+ (or RADIUS) server

• Junos OS build running on the Juniper Networks device

Before you begin:

• Establish a TCP connection between the device and the TACACS+ server. In the case of the RADIUS
server, establish a UDP connection between the device and the RADIUS server.

For information on configuring a TACACS+ server, see “Configuring TACACS+ Authentication” on

page 228.
 127

• Configure at least one user assigned to a login class on the Juniper Networks device. There can be more
than one login class, each with varying permission configurations, and more than one user on the device.

Overview and Topology

Each top-level command-line interface (CLI) command and each configuration statement in Junos OS has
an access privilege level associated with it. For each login class, you can explicitly deny or allow the use
of operational and configuration mode commands that would otherwise be permitted or not allowed by
a privilege level. Users can execute only those commands and configure and view only those statements
for which they have access privileges. To configure access privilege levels, include the permissions statement
at the [edit system login class class-name] hierarchy level.

The access privileges for each login class are defined by one or more permission flags specified in the
permissions statement. In addition to this, you can specify extended regular expressions with the following
statements:

• allow-commands and deny-commands—Allow or deny access to operational mode commands.

• allow-configuration and deny-configuration—Allow or deny access to parts of the configuration hierarchy.

These statements perform slower matching, with more flexibility, especially in wildcard matching.
However, it can take a very long time to evaluate all of the possible statements if a great number of
full-path regular expressions or wildcard expressions are configured, possibly impacting performance.

• allow-configuration-regexps and deny-configuration-regexps—Allow or deny access to a particular

configuration hierarchy using strings of regular expressions. These statements are similar to
allow-configuration and deny-configuration statements, except that in the
allow/deny-configuration-regexps statements you can configure sets of strings in which the strings
include spaces when using the first set of statements.

The above statements define a user’s access privileges to individual operational mode commands,
configuration statements, and hierarchies. These statements take precedence over a login class permissions
bit set for a user.

Difference between allow/deny-configuration and allow/deny-configuration-regexps statements

The allow-configuration and deny-configuration statements were introduced before Junos OS Release
7.4. The allow-configuration-regexps and deny-configuration-regexps statements were introduced in
Junos OS Release 11.2. In Junos OS Release 11.4, the allow-configuration and deny-configuration
statements were deprecated, but because these statements were useful in executing simple configurations,
these statements were undeprecated in Junos OS Release 11.4R6, and starting with the 11.4R6 release,
both the allow/deny-configuration and the allow/deny-configuration-regexps statements are supported.

The allow/deny-configuration-regexps statements split up the regular expression into tokens and match
each piece against each part of the specified configuration’s full path, whereas the allow/deny-configuration
statements match against the full string. For allow/deny-configuration-regexps statements, you configure
 128

a set of strings in which each string is a regular expression, with spaces between the terms of the string.
This provides very fast matching, but with less flexibility. For specifying wildcard expressions you must
set up wildcards for each token of the space-delimited string you want to match, and this makes it more
tedious to use wildcard expressions for these statements.

For example:

• Regular expression matching one token using allow-configuration-regexps

This example shows that options is the only matched expression against the first token of the statement.

[edit system]
login {
class test {
permissions configure;
allow-configuration-regexps .*options;
}
}

The above configuration matches the following statements:

• set policy-options condition condition dynamic-db

• set routing-options static route static-route next-hop next-hop

• set event-options generate-event event time-interval seconds

The above configuration does not match the following statements:

• system host-name host-options

• interfaces interface-name description options

• Regular expression matching three tokens using allow-configuration-regexps

This example shows that ssh is the only matched expression against the third token of the statement.

[edit system]
login {
class test {
permissions configure;
allow-configuration-regexps ".* .* .*ssh";
}
}

In the above example, the three tokens include .*, .*, and .*ssh, respectively.
 129

The above configuration matches the following statements:

• system host-name hostname-ssh

• system services ssh

• system services outbound-ssh

The above configuration does not match the following statement:

• interfaces interface-name description ssh

You can restrict configuration access easily using the deny-configuration statement as compared to using
the deny-configuration-regexps statement. Table 10 on page 129 illustrates the use of both the
deny-configuration and deny-configuration-regexps statements in different configurations to achieve the
same result of restricting access to a particular configuration.

Table 10: Restricting Configuration Access Using deny-configurtion and deny-configuration-regexps

Statements

Configuration Using: deny-configuration Using: deny-configuration-regexps Result

Denied

xnm-ssl [edit system] [edit system] The following

login { login { configuration
class test { class test { statement is
permissions configure; permissions configure; denied:
allow-configuration .*; allow-configuration .*;
deny-configuration deny-configuration-regexps ".* .* • system services
xnm-ssl
.*xnm-ssl; .*-ssl"";
} }
} }

ssh [edit system] [edit system] The following

login { login { configuration
class test { class test { statements are
permissions configure; permissions configure; denied:
allow-configuration .*; allow-configuration .*;
deny-configuration ".*ssh"; deny-configuration-regexps • system
host-name
} ".*ssh";
hostname-ssh
} deny-configuration-regexps ".*
.*ssh"; • system services
deny-configuration-regexps ".* .* ssh
.*ssh"; • system services
} outbound-ssh
}
• security
ssh-known-host
 130

Although the allow/deny-configuration statements are also useful when simple configuration is desired,
the allow/deny-configuration-regexps statements provide better performance and overcome the ambiguity
that existed when combining expressions set in the allow/deny-configuration statements.

NOTE: The allow/deny-configuration and allow/deny-configuration-regexps statements are

mutually exclusive and cannot be configured together for a login class. At a given point in time,
a login class can include either the allow/deny-configuration statement, or the
allow/deny-configuration-regexps statement. If you have existing configurations using the
allow/deny-configuration statements, using the same configuration options with the
allow/deny-configuration-regexps statements might not produce the same results, as the search
and match methods differ in the two forms of these statements.

Configuration Notes

When configuring the allow-configuration, deny-configuration, allow-configuration-regexps, and

deny-configuration-regexps statements with access privileges, take the following into consideration:

• You can include one deny-configuration and one allow-configuration statement in each login class.

• The allow/deny-configuration and allow/deny-configuration-regexps statements are mutually exclusive

and cannot be configured together for a login class. At a given point in time, a login class can include
either the allow/deny-configuration statement, or the allow/deny-configuration-regexps statement. If
you have existing configurations using the allow/deny-configuration statements, using the same
configuration options with the allow/deny-configuration-regexps statements might not produce the
same results, as the search and match methods differ in the two forms of these statements.

• Explicitly allowing configuration mode hierarchies or regular expressions using the allow-configuration
statement adds to the regular permissions set using the permissions statement. Likewise, explicitly
denying configuration mode hierarchies or regular expressions using the deny-configuration statement
removes permissions for the specified configuration mode hierarchy, from the default permissions
provided by the permissions statement.

For example, for the following configuration, the login class user can edit the configuration at the [edit
system services] hierarchy level and issue configuration mode commands (such as commit), in addition
to just entering the configuration mode using the configure command, which is the permission specified
by the configure permission flag:

[edit system login]

user@host# set class test permissions configure allow-configuration "system services"

Likewise, for the following configuration, the login class user can perform all operations allowed by the
all permissions flag, except issuing configuration mode commands (such as commit) or modifying the
configuration at the [edit system services] hierarchy level:
 131

[edit system login]

user@host# set class test permissions all deny-configuration "system services"

• To define access privileges to parts of the configuration hierarchy, specify the full paths in the extended
regular expressions with the allow-configuration and deny-configuration statements. Use parentheses
around an extended regular expression that connects two or more expressions with the pipe (|) symbol.

For example:

[edit system login]

user@host# set class test deny-configuration "(system login class)|(system services)"

• When specifying extended regular expressions using the allow/deny-commands and

allow/deny-configuration statements, each expression separated by a pipe (|) symbol must be a complete
standalone expression, and must be enclosed in parentheses ( ). Do not use spaces between regular
expressions separated with parentheses and connected with the pipe (|) symbol.

For example:

[edit system login]

user@host# set class test allow-commands "(ping .*)|(traceroute .*)|(show .*)|(configure
.*)|(edit)|(exit)|(commit)|(rollback .*)"
user@host# set class test deny-configuration "(system login class)|(system services)"

• When specifying extended regular expressions using the allow-deny-configuration-regexps statement,

each expression enclosed within quotes (") and separated by a space must be enclosed in angular brackets
[ ].

For example:

[edit system login]

user@host# set class test allow-configuration-regexps [ "interfaces .* description .*” “interfaces .* unit .* description
.*” “interfaces .* unit .* family inet address .*” “interfaces.* disable" ]

• If the exact same command is configured under both allow-configuration and deny-configuration
statements, then the allow operation takes precedence over the deny statement.

For instance, with the following configuration, a user assigned to login class test is allowed to access the
[edit system services] configuration hierarchy, although the deny-configuration statement also includes
it:

[edit system login]

user@host# set class test permissions allow-configuration "system services"
user@host# set class test permissions deny-configuration "system services"
 132

For instance, if a certain command or configuration is allowed, for example, using permission all, then
we can use the deny-configuration command to deny access to a particular hierarchy.

• Modifiers such as set, log, and count are not supported within the regular expression string to be matched.
If a modifier is used, then nothing is matched.

Incorrect configuration:

[edit system login]

user@host# set class test permission deny-configuration "set protocols"

Correct configuration:

[edit system login]

user@host# set class test permission deny-configuration protocols

• You can use the * wildcard character when denoting regular expressions. However, it must be used as
a portion of a regular expression. You cannot use [ * ] or [ .* ] alone.

• You cannot configure the allow-configuration statement with the (interfaces (description (|.*)) regular
expression, as this evaluates to allow-configuration = .* regular expression.

• You can configure as many regular expressions as needed to be allowed or denied. Regular expressions
to be denied take precedence over configurations to be allowed.

Topology

Figure 2: Configuring TACACS+ Server Authentication

10.209.1.66/24

TCP connection
g043487

R1 TACACS+
Server

Figure 2 on page 132 illustrates a simple topology, where Router R1 is a Juniper Networks device and has
a TCP connection established with a TACACS+ server.

In this example, R1 is configured with two customized login classes—Class1 and Class2—for specifying
access privileges with extended regular expressions using the allow-configuration, deny-configuration,
allow-configuration-regexps, and deny-configuration-regexps statements differently.

The purpose of the login classes is as follows:

• Class1—Define access privileges for the user with the allow-configuration and deny-configuration
statements. This login class should provide access to configure interfaces hierarchy only, and deny all
other access on the device. To do this, the user permissions should include configure to provide
 133

configuration access. In addition to this, the allow-configuration statement should allow interfaces
configuration, and the deny-configuration statement should deny access to all other configurations.
Because the allow statement takes precedence over the deny statement, the users assigned to the Class1
login class can access only the [edit interfaces] hierarchy level.

• Class2—Define access privileges for the user with the allow-configuration-regexps and
deny-configuration-regexps statements. This login class provides superuser-level user permissions, and
in addition, explicitly allows configuration under multiple hierarchy levels for interfaces. It also denies
configuration access to the [edit system] and [edit protocols] hierarchy levels.

Router R1 has two users, User1 and User2, assigned to the Class1 and Class2 login classes, respectively.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, copy and paste the
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

R1

set system authentication-order tacplus

set system authentication-order radius
set system authentication-order password
set system radius-server 10.209.1.66 secret "$ABC123"
set system tacplus-server 10.209.1.66
set system radius-options enhanced-accounting
set system tacplus-options enhanced-accounting
set system accounting events login
set system accounting events change-log
set system accounting events interactive-commands
set system accounting traceoptions file auditlog
set system accounting traceoptions flag all
set system accounting destination tacplus server 10.209.1.66
set system login class Class1 permissions configure
set system login class Class1 allow-configuration "interfaces .* unit .*"
set system login class Class1 deny-configuration .*
set system login class Class2 permissions all
set system login class Class2 allow-configuration-regexps [ "interfaces .* description .*" "interfaces .*
unit .* description .*" "interfaces .* unit .* family inet address .*" "interfaces.* disable" ]
set system login class Class2 deny-configuration-regexps [ "system" "protocols" ]
set system login user User1 uid 2004
set system login user User1 class Class1
 134

set system login user User1 authentication encrypted-password "$ABC123"

set system login user User2 uid 2006
set system login user User2 class Class2
set system login user User2 authentication encrypted-password "$ABC123"
set system syslog file messages any any

Configuring Authentication Parameters for Router R1

Step-by-Step Procedure
The following example requires that you navigate various levels in the configuration hierarchy. For
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Router R1 authentication:

1. Configure the order in which authentication should take place for R1. In this example, TACACS+ server
authentication is first, followed by RADIUS server authentication, then the local password.

[edit system]
user@R1# set authentication-order tacplus
user@R1# set authentication-order radius
user@R1# set authentication-order password

2. Establish R1 connection with the TACACS+ server.

[edit system]
user@R1# set tacplus-server 10.209.1.66
user@R1# set tacplus-options enhanced-accounting
user@R1# set accounting destination tacplus server 10.209.1.66

3. Configure RADIUS server authentication parameters.

[edit system]
user@R1# set radius-server 10.209.1.66 secret "$ABC123"
user@R1# set radius-options enhanced-accounting

4. Configure the R1 accounting configuration parameters.

[edit system]
user@R1# set accounting events login
 135

user@R1# set accounting events change-log

user@R1# set accounting events interactive-commands
user@R1# set accounting traceoptions file auditlog
user@R1# set accounting traceoptions flag all

Configuring Access Privileges with allow-configuration and deny-configuration Statements (Class1)

Step-by-Step Procedure
To specify regular expressions using the allow-configuration and deny-configuration statements:

1. Configure the Class1 custom login class and assign configuration user permissions.

[edit system login]

user@R1# set class Class1 permissions configure

2. Specify the regular expression in the allow-configuration statement to allow configuration at the [edit
interfaces] hierarchy level. To allow set commands at the [edit interfaces] hierarchy level, the regular
expression used is interfaces .* unit .*.

[edit system login]

user@R1# set class Class1 allow-configuration "interfaces .* unit .*"

3. Specify the regular expression in the deny-configuration statement to disable all configuration access.
The regular expression used to deny all configuration access is .*.

[edit system login]

user@R1# set class Class1 deny-configuration .*

4. Configure the user account for the Class1 login class.

[edit system login]

user@R1# set system login user User1 uid 2004
user@R1# set system login user User1 class Class1
user@R1# set system login user User1 authentication encrypted-password "$ABC123"

Configuring Access Privileges with allow-configuration-regexps and deny-configuration-regexps Statements

(Class2)

Step-by-Step Procedure
 136

To specify regular expressions using the allow-configuration-regexps and deny-configuration-regexps

statements:

1. Configure the Class2 custom login class and assign superuser (all) user permissions. For information on
the predefined system login classes, see “Junos OS Login Classes Overview” on page 37.

[edit system login]

user@R1# set class Class2 permissions all

2. Specify the regular expression to allow access to multiple hierarchies under the [edit interfaces] hierarchy
level.

[edit system login]

user@R1# set class Class2 allow-configuration-regexps [ "interfaces .* description .*" "interfaces .* unit .*
description .*" "interfaces .* unit .* family inet address .*" "interfaces.* disable" ]

3. Specify the regular expression to deny configuration at the [edit system] and [edit protocols] hierarchy
levels.

[edit system login]

user@R1# set class Class2 deny-configuration-regexps [ "system" "protocols" ]

4. Configure the user account for the Class2 login class.

[edit system login]

user@R1# set system login user User2 uid 2006
user@R1# set system login user User2 class Class2
user@R1# set system login user User2 authentication encrypted-password "$ABC123"

Results

From configuration mode, confirm your configuration by entering the show system command. If the output
does not display the intended configuration, repeat the instructions in this example to correct the
configuration.

user@R1# show system

authentication-order [ tacplus radius password ];
radius-server {
10.209.1.66 secret "$ABC123";
}
 137

tacplus-server {
10.209.1.66;
}
radius-options {
enhanced-accounting;
}
tacplus-options {
enhanced-accounting;
}
accounting {
events [ login change-log interactive-commands ];
traceoptions {
file auditlog;
flag all;
}
destination {
tacplus {
server {
10.209.1.66;
}
}
}
}
login {
class Class1 {
permissions configure;
allow-configuration "interfaces .* unit .*";
deny-configuration .*;
}
class Class2 {
permissions all;
allow-configuration-regexps [ "interfaces .* description .*" "interfaces .* unit .* description .*" "interfaces .*
unit .* family inet address .*" "interfaces.* disable" ];
deny-configuration-regexps [ "system" "protocols" ];
}
user User1 {
uid 2001;
class Class1;
authentication {
encrypted-password "$ABC123";
}
}
user User2 {
uid 2002;
 138

class Class2;
authentication {
encrypted-password "$ABC123";
}
}
}
syslog {
file messages {
any any;
}
}

Verification

IN THIS SECTION

Verifying Class1 Configuration | 138

Verifying Class2 Configuration | 139

Log in as the username assigned with the new login class, and confirm that the configuration is working
properly.

Verifying Class1 Configuration

Purpose
Verify that the permissions allowed in the Class1 login class are working.

Action

From the CLI prompt, check the available permissions.

User1@R1> ?

Possible completions:
clear Clear information in the system
configure Manipulate software configuration information
file Perform file operations
help Provide help information
load Load information from file
op Invoke an operation script
 139

quit Exit the management session

request Make system-level requests
save Save information to file
set Set CLI properties, date/time, craft interface message
start Start shell
test Perform diagnostic debugging

From the configuration mode, check the available configuration permissions.

User1@R1# edit ?

Possible completions:
> interfaces Interface configuration

Meaning
User1 has configure user permissions seen in the first output, and the only configuration access allowed
for User1 is at the interfaces hierarchy level. All other configuration is denied, as seen in the second output.

Verifying Class2 Configuration

Purpose
Verify that the Class2 configuration is working.

Action
From the configuration mode, access the interfaces configuration.

[edit interfaces]
User2@R1# set ?
Possible completions:
<interface-name> Interface name
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
ge-0/0/3 Interface name
> interface-range Interface ranges configuration
> interface-set Logical interface set configuration
> traceoptions Interface trace options

From the configuration mode, access the system and protocols configuration hierarchies.

User2@R1# edit system

 140

^
Syntax error, expecting <statement> or <identifier>.

User2@R1# edit protocols

^
Syntax error, expecting <statement> or <identifier>.

Meaning
User2 has permissions to configure interfaces of R1, but the [edit system] and [edit protocols] hierarchy
levels are denied access, as seen in the output.

SEE ALSO

Regular Expressions for Allowing and Denying Junos OS Operational Mode Commands, Configuration
Statements, and Hierarchies | 94

RELATED DOCUMENTATION

Junos OS Login Classes Overview | 37

Junos OS User Accounts | 57
3 CHAPTER

Passwords for User Access

Root Password | 142

Recovering Root Password | 148

Plain-Text Passwords | 161

Master Password for Configuration Encryption | 164

 142

Root Password

IN THIS SECTION

Configuring the Root Password | 142

Example: Configuring a Plain-Text Password for Root Logins | 144

Example: Configuring SSH Authentication for Root Logins | 147

When the router, switch, or security device is powered on first time, it is ready to be configured. Initially,
you log in as the user root with no password. Later, you must configure a plain-text password for the
root-level user (whose username is root). Configuring a plain-text password is one way to protect access
to the root level by unauthorized users. If you forget the root password for the router, you can use the
password recovery procedure to reset the root password. Read this topic for more information.

Configuring the Root Password

The Junos OS is preinstalled on the router or switch. When the router or switch is powered on, it is ready
to be configured. Initially, you log in as the user root with no password. The root directory of a UNIX device
is the entry point to all other folders and files on that device. As a result, access to the root directory is
restricted by default to a predefined user account known as the root user. The root user (also referred to
as superuser) has unrestricted access and full permissions within the system. The expression “log in as root”
is commonly used when an action requires the user to log into the device as the root user.

NOTE: If you configure a blank password using the encrypted-password statement at the [edit
system root-authentication] hierarchy level for root authentication, you can commit a
configuration but you cannot log in as the root user and gain root level access to the router or
switch.

After you log in, you should configure the root (superuser) password by including the root-authentication
statement at the [edit system] hierarchy level and configuring one of the password options:

[edit system]
 143

root-authentication {
(encrypted-password "password"| plain-text-password);
load-key-file URL filename;
ssh-dsa “public-key” <from hostname>;
ssh-ecdsa “public-key” <from hostname>;
ssh-rsa “public-key” <from hostname>;
}

If you configure the plain-text-password option, you are prompted to enter and confirm the password:

[edit system]
user@host# set root-authentication plain-text-password
New password: type password here
Retype new password: retype password here

The default requirements for plain-text passwords are:

• The password must be between 6 and 128 characters long

• You can include most character classes in a password (uppercase letters, lowercase letters, numbers,
punctuation marks, and other special characters). Control characters are not recommended.

• Valid passwords must contain at least one uppercase letter or one lowercase letter, or one character
class.

You can use the load-key-file URL filename statement to load an SSH key file that was previously generated
using ssh-keygen. The URL filename is the path to the file’s location and name. When using this option,
the contents of the key file are copied into the configuration immediately after entering the load-key-file
URL statement. This command loads RSA (SSH version 1 and SSH version 2) and DSA (SSH version 2)
public keys.

Starting in Junos OS Release 18.3R1, the ssh-dss and ssh-dsa hostkey algorithms are deprecated— rather
than immediately removed—to provide backward compatibility and a chance to bring your configuration
into compliance with the new configuration.

Optionally, you can use the ssh-dsa, ssh-ecdsa, or ssh-rsa statements to directly configure SSH RSA, DSA,
or ECDSA keys to authenticate root logins. You can configure more than one public key for SSH
authentication of root logins as well as for user accounts. When a user logs in as root, the public keys are
referenced to determine whether the private key matches any of them.

[edit system]
user@host# set root-authentication load-key-file my-host:.ssh/id_dsa.pub
.file.19692 | 0 KB | 0.3 kB/s | ETA: 00:00:00 | 100%
[edit system]
 144

From configuration mode, you can confirm your SSH key entries by entering the show command. It should
look something like this:

[edit system]
user@hos# show
root-authentication {
ssh-rsa "$ABC123"; #
SECRET-DATA
}

Junos-FIPS software has special password requirements. FIPS passwords must be between 10 and 20
characters in length. Passwords must use at least three of the five defined character sets (uppercase letters,
lowercase letters, digits, punctuation marks, and other special characters). If Junos-FIPS is installed on the
router or switch, you cannot configure passwords unless they meet this standard.

If you use the encrypted-password option, then a null-password (empty) is not permitted. You must
configure a password whose number of characters range from 1 through 128 characters and enclose the
password in quotation marks.

SEE ALSO

Protecting Network Security by Configuring the Root Password

Example: Changing the Requirements for Junos OS Plain-Text Passwords | 162

Example: Configuring a Plain-Text Password for Root Logins

IN THIS SECTION

Requirements | 145

Overview | 145

Configuration | 145

Verification | 146

This example shows how to configure a plain-text password for the root-level user (whose username is
root). Configuring a plain-text password is one way to protect access to the root level by unauthorized
 145

users. You must prevent unauthorized users from gaining access to superuser commands that can be used
to alter your system configuration.

Requirements

No special configuration beyond device initialization is required before configuring this example.

Make sure that you understand the requirements for a valid plain-text password. For Junos OS, the default
requirements for a plain-text password are as follows:

• Must be from 6 up to 128 characters long.

• Can include most character classes (uppercase letters, lowercase letters, numbers, punctuation marks,
and other special characters). Control characters are not recommended.

• Must contain at least one change of case or character class.

Overview

Junos OS is preinstalled on the router. When the router is powered on, it is ready to be configured. Initially,
you log in as the root-level user with no password. To set the root password, you have several options.
This example shows how to enter a plain-text password that Junos OS then encrypts for you.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following command and paste it into the window. When
prompted, type the new password, and then when prompted, retype it.

set system root-authentication plain-text-password

Configuring a Plain-Text Password for User Root

Step-by-Step Procedure
To configure a plain-text password for the root-level user:

1. Type the set command for the plain-text password and press Enter.

[edit]
user@host# set system root-authentication plain-text-password
New password:

2. Type the new password next to the New password prompt and press Enter.
 146

New password: new-password

Retype new password:

3. Retype the same password next to the Retype new password prompt and press Enter.

Results

From configuration mode, confirm your configuration by using the show command. It should look something
like this:

[edit ]
user@host# show system
root-authentication {
encrypted-password "$ABC123"; ## SECRET-DATA
}

If the output does not display the intended configuration, repeat the instructions in this example to correct
the configuration.

After you have confirmed that the configuration is correct, enter commit from configuration mode.

Verification

Verifying the Configuration of a Plain-Text Password for User Root

Purpose
Verify the configuration of a plain-text password for the root-level user.

Action
From operational mode, confirm your configuration by entering the show configuration system command.

user@host> show configuration system

root-authentication {
encrypted-password "$ABC123"; ## SECRET-DATA
}

Meaning
If you use a clear-text password, Junos OS displays the password as an encrypted string so that users
viewing the configuration cannot see the unencrypted password. That is, as you enter the password in
plain text, Junos OS encrypts it immediately. You do not have to configure Junos OS to encrypt the
password as in some other systems. Plain-text passwords are hidden and marked as ## SECRET-DATA in
the configuration.
 147

SEE ALSO

root-authentication | 1246
Changing the Requirements for Junos OS Plain-Text Passwords | 161

Example: Configuring SSH Authentication for Root Logins

The following example shows how to configure two public DSA keys for SSH authentication of root logins:

[edit system]
root-authentication {
encrypted-password "$ABC123";
## SECRET-DATA;
ssh-dsa "2354 95 [email protected]";
ssh-dsa "0483 02 [email protected]";
}

Release History Table

Release Description

18.3R1 Starting in Junos OS Release 18.3R1, the ssh-dss and ssh-dsa hostkey algorithms are
deprecated— rather than immediately removed—to provide backward compatibility and a
chance to bring your configuration into compliance with the new configuration.

RELATED DOCUMENTATION

Protecting Network Security by Configuring the Root Password

Plain-Text Passwords | 161
Release Information for Junos OS with Upgraded FreeBSD
 148

Recovering Root Password

IN THIS SECTION

Recovering the Root Password on Routers | 148

Recovering the Root Password on Junos OS with Upgraded FreeBSD | 151

Recovering the Root Password for Junos OS Evolved | 154

Recovering the Root Password on Switches | 158

If you forget the root password for a device running Junos OS, you can use the password recovery procedure
to reset the root password. Read this topic to understand how to recover root password.

Recovering the Root Password on Routers

If you forget the root password for the router, you can use the password recovery procedure to reset the
root password.

Before you begin, note the following:

• You need console access to recover the root password.

• This password recovery procedure does not apply to devices running Junos OS with Upgraded FreeBSD.
See “Recovering the Root Password on Junos OS with Upgraded FreeBSD” on page 151. For the list of
Junos OS devices with upgraded FreeBSD, see Junos kernel upgrade to FreeBSD 10+.

• For MX80 Series routers, try this procedure first, but if it does not work you can manually delete the
root-authentication settings from the Junos configuration file and reset the password, as explained here:
Recovering the Root Password for MX80

Video: How to Recover the Root Password in Junos OS

To recover the root password:

1. Power off the router by pressing the power button on the front panel.

2. Turn off the power to the management device, such as a PC or laptop computer, that you want to use
to access the CLI.
 149

3. Plug one end of the Ethernet rollover cable supplied with the router into the RJ-45–to–DB-9 serial
port adapter supplied with the router.

4. Plug the RJ-45–to–DB-9 serial port adapter into the serial port on the management device.

5. Connect the other end of the Ethernet rollover cable to the console port on the router.

6. Turn on the power to the management device.

7. On the management device, start your asynchronous terminal emulation application (such as Microsoft
Windows Hyperterminal) and select the appropriate COM port to use (for example, COM1).

8. Configure the port settings as follows:

• Bits per second: 9600

• Data bits: 8

• Parity: None

• Stop bits: 1

• Flow control: None

9. Power on the router by pressing the power button on the front panel.

Verify that the POWER LED on the front panel turns green.

The terminal emulation screen on your management device displays the router’s boot sequence.

10. When the following prompt appears, press the Spacebar to access the router’s bootstrap loader command
prompt:

Depending on your device hardware, the bootstrap loader might proceed quite quickly at this step
without pausing for input. Therefore, you might need to press the spacebar multiple times at the
beginning of the boot sequence.

Hit [Enter] to boot immediately, or space bar for command prompt.

Booting [kernel] in 9 seconds...

11. At the following prompt, type boot -s to start the system in single-user mode.

ok boot -s

12. At the following prompt, type recovery to start the root password recovery procedure.
 150

Enter full pathname of shell or 'recovery' for root password recovery or

RETURN for /bin/sh: recovery

13. Enter configuration mode in the CLI.

14. Set the root password.

[edit]
user@host# set system root-authentication plain-text-password

When you configure a plain-text password, Junos OS encrypts the password for you.

CAUTION: Do not use the encrypted-password option unless the password is

already encrypted, and you are entering the encrypted version of the password. If
you commit the encrypted-password option with a plain-text password or with
blank quotation marks (" "), you will not be able to log in to the device as root, and
you will need to repeat this password recovery process.

15. At the following prompt, enter the new root password, for example:

New password: password

Retype new password:

16. At the second prompt, reenter the new root password.

17. After you have finished configuring the password, commit the configuration.

root@host# commit

commit complete

18. Exit configuration mode in the CLI.

19. Exit operational mode in the CLI.

20. At the prompt, type y to reboot the router.

Reboot the system? [y/n] y

 151

SEE ALSO

Configuring the Root Password | 142

Recovering the Root Password on Junos OS with Upgraded FreeBSD | 151

Recovering the Root Password on Junos OS with Upgraded FreeBSD

If you forget the root password for a device running Junos OS with Upgraded FreeBSD, you can use the
password recovery procedure to reset the root password.

For the list of Junos OS devices with upgraded FreeBSD, see Junos kernel upgrade to FreeBSD 10+

Video: How to Recover the Root Password in Junos OS with Upgraded FreeBSD

NOTE: You need console access to recover the root password.

NOTE: This password recovery procedure only applies to devices running Junos OS with
Upgraded FreeBSD. For password recovery on Junos OS devices, see “Recovering the Root
Password on Routers” on page 148.

To recover the root password:

1. Power off the router by pressing the power button on the front panel.

2. Turn off the power to the management device, such as a PC or laptop computer, that you want to use
to access the CLI.

3. Plug one end of the Ethernet rollover cable supplied with the router into the RJ-45–to–DB-9 serial
port adapter supplied with the router.

4. Plug the RJ-45–to–DB-9 serial port adapter into the serial port on the management device.

5. Connect the other end of the Ethernet rollover cable to the console port on the router.

6. Turn on the power to the management device.

 152

7. On the management device, start your asynchronous terminal emulation application (such as Microsoft
Windows Hyperterminal) and select the appropriate COM port to use (for example, COM1).

8. Configure the port settings as follows:

• Bits per second: 9600

• Data bits: 8

• Parity: None

• Stop bits: 1

• Flow control: None

9. Power on the router by pressing the power button on the front panel.

Verify that the POWER LED on the front panel turns green.

The terminal emulation screen on your management device displays the router’s boot sequence.

10. Access the Junos Main Menu.

• Prior to Junos OS Release 17.3, the Junos Main Menu appears for 3 seconds on startup before
automatically booting the Junos volume. Press any key within the 3 second window to stop the
autotmatic boot sequence and display the Junos Main Menu.

NOTE: The Junos Main Menu will appear every time you reboot the router while connected
to the console.

• Starting in Junos OS Release 17.3, press Ctrl+c at the following part in the reboot to bring up the
Junos Main Menu:

FreeBSD/x86 bootstrap loader, Revision 1.1

([email protected], Sun Feb 4 13:06:24 PST 2018)
/
Autoboot in 1 seconds... (press Ctrl-C to interrupt)

1. Boot [J]unos volume

2. Boot Junos volume in [S]afe mode

3. [R]eboot
 153

4. [B]oot menu
5. [M]ore options

11. At the Junos Main Menu, press the M or 5 key to activate the 5. [M]ore options menu:

1. Recover [J]unos volume

2. Recovery mode - [C]LI

3. Check [F]ile system

4. Enable [V]erbose boot

5. [B]oot prompt

6. [M]ain menu

12. Press the C or 2 key to access the 2. Recovery mode - [C]LI option. The router will reboot into CLI
recovery mode.

13. When prompted, press the Enter key to immediately boot the router, or press any other key to bring
up the command prompt.

14. Enter configuration mode in the CLI.

root># configure

Entering configuration mode

15. Set the root password.

When you configure a plain-text password, Junos OS encrypts the password for you.

[edit]
root# set system root-authentication plain-text-password

CAUTION: Do not use the encrypted-password option unless the password is

already encrypted, and you are entering the encrypted version of the password. If
you commit the encrypted-password option with a plain-text password or with
blank quotation marks (" "), you will not be able to log in to the router as root, and
you will need to repeat this password recovery process.
 154

16. At the following prompt, enter the new root password, for example:

New password: password

Retype new password:

17. At the second prompt, reenter the new root password.

Recovering the Root Password for Junos OS Evolved

IN THIS SECTION

Connecting to the Serial Port | 154

Recovering the Root Password | 156

This procedure resets the root password without resetting the device configuration to the factory default
configuration. Only the root password is reset to a value you enter. None of the other functions nor the
state of the device are affected.

Video: How to Recover the Root Password in Junos OS Evolved

Connecting to the Serial Port

The first task in the password reset operation is to connect to the serial port of the device.

To connect to the serial port:

1. Power off the router by pressing the power button on the front panel.

2. Turn off the power to the management device, such as a PC or laptop computer, that you want to use
to access the CLI.

3. Plug one end of the Ethernet rollover cable supplied with the router into the RJ-45–to–DB-9 serial
port adapter supplied with the router.

4. Plug the RJ-45–to–DB-9 serial port adapter into the serial port on the management device.
 155

5. Connect the other end of the Ethernet rollover cable to the console port on the router.

6. Turn on the power to the management device.

7. On the management device, start your asynchronous terminal emulation application (such as Microsoft
Windows Hyperterminal) and select the appropriate COM port to use (for example, COM1).

8. Configure the port settings as follows:

• Bits per second: 9600

• Data bits: 8

• Parity: None

• Stop bits: 1

• Flow control: None

9. Power on the router by pressing the power button on the front panel.

Verify that the POWER LED on the front panel turns green. The terminal emulation screen on your
management device displays the router’s boot sequence.
 156

Recovering the Root Password

The password reset operation is triggered early in the boot process, The actual password reset is done in
the shell.

To recover the root password for Junos OS Evolved:

1. Do a hard reboot of the Routing Engine (that is, reboot a device that is not running) .

On the terminal, you see this screen:

GNU GRUB version 2.02~beta3

+--------------------------------------------------------------------+
|*Primary ptx-fixed-19.1-16 |
| Primary [Recover password] |
| Primary-Rollback ptx-fixed-19.1-15 |
| Primary-Rollback [Recover password] |
| |
| |
| |
| |
| |
| |
| |
| |
+--------------------------------------------------------------------+

Use the ^ and v keys to select which entry is highlighted.

Press enter to boot the selected OS, `e' to edit the commands
before booting or `c' for a command-line.

2. Use the arrow keys to scroll down to the Primary [Recover password] option and press Enter.

Disk boot ...

IMA is 0
Loading kernel ...ok.
Loading initrd ...ok.
Booting ...
[ 0.791088] Failed to find cpu0 device node
Processing /dev/sda2 for mount on /soft ...[checking]..ok [mounting]..done
Processing /dev/sda5 for mount on /data ...[checking]..ok [mounting]..done
Processing /dev/sda6 for mount on /data/config ...[checking]..ok [mounting]..done
 157

Processing /dev/sda7 for mount on /data/var ...[checking]..ok [mounting]..done

mkswap: /dev/sda3: warning: wiping old swap signature.
Setting up swapspace version 1, size = 4 GiB (4294963200 bytes)
no label, UUID=7d905478-773b-41e5-8f1d-8166ec03f93a
Processing /dev/sda1 for mount on /boot ...[checking]..ok [mounting]..done
Done with local filesystems setup.
Mounting version
junos-linux-install-ptx-x86-64-16.2I20180502181332_evo-builder...done.
System is running with minimal count of software versions
modprobe: FATAL: Module jnx_cbd_fpga_ptx21k not found in directory
/lib/modules/4.8.24-WR2.2.1_standard
Installing kexec kernel...Cannot get kernel page_offset_base symbol address
done
Password recovery in progress. Please enter new password.

3. Enter the new password, and then retype the new password and Enter.

New password:
Retype new password:
passwd: password updated successfully
Password recovery done

Welcome to Linux!

The reboot will proceed until the login prompt is displayed.

[ OK ] Started Serial Getty on ttyS0.

[ OK ] Reached target Login Prompts.
[ OK ] Started Vsftpd ftp daemon.
[ OK ] Started Network Time Service.
[ OK ] Started strongSwan IPsec IKEv1/IKEv2 daemon using swanctl.
[ OK ] Started Arp filtering arptables.
[ OK ] Started Management Ethernet Interface Manager Service.
[ OK ] Started OFP on RE.
Starting MGD initialization of schema and database on RE...

Juniper Linux Distribution 2.2.1 re0 ttyS0

re0 login:

4. Enter your login ID, and then your password.

You will see a shell prompt.

 158

Last login: Mon May 7 13:09:08 PDT 2018 from xxxx

--- JUNOS builder Linux re0 4.8.24-WR2.2.1_standard #1 SMP PREEMPT Mon Apr 9
13:21:32 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux
remote@RE0:~$

5. To start the CLI, enter cli.

Recovering the Root Password on Switches

Problem
Description: If you forget the root password for a switch, use the password recovery procedure to reset
the root password.
Before you being, note the following:

• You need physical access to the switch to recover the root password.

• This password recovery procedure does not apply to devices running Junos OS with Upgraded FreeBSD.
See “Recovering the Root Password on Junos OS with Upgraded FreeBSD” on page 151. For the list of
Junos OS devices with upgraded FreeBSD, see Junos kernel upgrade to FreeBSD 10+.

TIP: For a video on recovering the root password for routers, see “Recovering the Root Password
on Routers” on page 148. The procedure is similar for switches.

Solution
To recover the root password:

1. Power off your switch by unplugging the power cord or turning off the power at the wall switch.

2. Insert one end of the Ethernet cable into the serial port on the management device and connect the
other end to the console port on the back of the switch. See Figure 3 on page 159.
 159

Figure 3: Connecting to the Console Port on the EX Series Switch

3. On the management device, start your asynchronous terminal emulation application (such as Microsoft
Windows Hyperterminal) and select the appropriate COM port to use (for example, COM1).

4. Configure the port settings as follows:

• Bits per second: 9600

• Data bits: 8

• Parity: None

• Stop bits: 1

• Flow control: None

5. Power on your switch by plugging in the power cord or turning on the power at the wall switch.

6. When the following prompt appears, press the Spacebar to access the switch's bootstrap loader
command prompt:

Hit [Enter] to boot immediately, or space bar for command prompt.

Booting [kernel] in 1 second...

NOTE: If the switch is in unattended mode for U-Boot, access to the bootstrap loader
command prompt is blocked. If the root password is lost, you must reset the switch to the
factory default configuration using the LCD panel. For more information, see Reverting to the
Default Factory Configuration for the EX Series Switch.

7. At the following prompt, type boot -s to start up the system in single-user mode:
 160

loader> boot -s

8. At the following prompt, type recovery to start the root password recovery procedure:
Enter full path name of shell or ’recovery’ for root password recovery or RETURN for /bin/sh: recovery

A series of messages describe consistency checks, mounting of filesystems, and initialization and
checkout of management services. Then the CLI prompt appears.

9. Enter configuration mode in the CLI:

user@switch> configure

10. Set the root password. For example:

user@switch# set system root-authentication plain-text-password

11. At the following prompt, enter the new root password. For example, juniper1:
user@switch# juniper1

Retype new password:

12. At the second prompt, reenter the new root password.

13. If you are finished configuring the network, commit the configuration.
root@switch# commit

commit complete

14. Exit configuration mode in the CLI.

root@switch# exit

15. Exit operational mode in the CLI.

root@switch> exit

16. At the prompt, enter y to reboot the switch.

Reboot the system? [y/n] y

SEE ALSO

Connecting and Configuring an EX Series Switch (CLI Procedure)

Connecting and Configuring an EX Series Switch (J-Web Procedure)
 161

Plain-Text Passwords

IN THIS SECTION

Changing the Requirements for Junos OS Plain-Text Passwords | 161

Example: Changing the Requirements for Junos OS Plain-Text Passwords | 162

Changing the Requirements for Junos OS Plain-Text Passwords

For plain-text password requirements, see Special Requirements for Junos OS Plain-Text Passwords.

To change the requirements for plain-text passwords, include the password statement at the [edit system
login] hierarchy level:

[edit system login]

password {
change-type (set-transitions | character-set);
format (sha1 | sha256 | sha512);
maximum-length length;
maximum-lifetime days
minimum-changes number;
minimum-character-changes number
minimum-length length;
minimum-lifetime days
minimum-lower-cases number;
minimum-numerics number;
minimum-reuse number
minimum-punctuations number;
minimum-upper-cases number;
}

NOTE: These statements apply to plain-text passwords only, not encrypted passwords.
 162

SEE ALSO

Configuring the Root Password | 142

Example: Changing the Requirements for Junos OS Plain-Text Passwords | 162

Example: Changing the Requirements for Junos OS Plain-Text Passwords

IN THIS SECTION

Requirements | 162

Overview | 162

Configuration | 162

This example shows how to set various maximum and minimum requirements for plain-text passwords to
increase password strength.

Requirements

This example requires a device running Junos 12.2 or greater. The minimum-length and maximum-length
password requirements statements are available in earlier releases, however, you must have Junos OS
Release 12.2 or greater to configure minimum-lower-cases, minimum-numerics, minimum-punctuations,
or minimum-upper-cases.

Overview

You can use a variety of requirements to strengthen plain-text passwords for greater security. Junos OS
provides a number of possible configurations at the [edit system login password] hierarchy level that allow
you to require users to create plain-text passwords that conform to a particular set of requirements that
may include such things as length, number of changes, type of characters, numbers, or letter case.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
 163

set system login password minimum-length 12

set system login password maximum-length 22
set system login password minimum-numerics 1
set system login password minimum-upper-cases 1
set system login password minimum-lower-cases 1
set system login password minimum-punctuations 1

Configuring Requirements for Plain-Text Passwords

Step-by-Step Procedure
This example configures password requirements that require the user to creat a password that has a
minimum length of 12 characters, a maximum length of 22 characters, and that includes at least one
lower-case letter, at least one upper-case letter, at least one punctuation character, and at least one numeric
character.

1. Navigate to configuration mode in the [system login password] hierarchy level.

user@host> edit
[edit]
user@host# edit system login password

2. Set a minimum length requirement of 12 characters and a maximum length requirement of 22 characters
for user passwords.

[edit system login password]

user@host# set minimum-length 12
[edit system login password]
user@host# set maximum-length 22

3. Require users to set a password that has at least one lower-case letter and at least one upper-case
letter.

[edit system login password]

user@host# set minimum-lower-cases 1
[edit system login password]
user@host# set minimum-upper-cases 1

4. Require users to set a password that has at least one punctuation-class character and at least one
number.

[edit system login password]

 164

user@host# set minimum-punctuations 1

[edit system login password]
user@host# set minimum-numerics 1

Results

From configuration mode, confirm your configuration by entering the show command at the edit system
login password hierarchy level. if the output does not display the intended configuration, repeat the
instructions in this example to correct the configuration.

[edit system login password]

user@host# show
minimum-length 12;
maximum-length 22;
minimum-numerics 1;
minimum-upper-cases 1;
minimum-lower-cases 1;

SEE ALSO

password (Login) | 1209

Master Password for Configuration Encryption

IN THIS SECTION

Hardening Shared Secrets in Junos OS | 165

Using Trusted Platform Module to Bind Secrets on SRX Series Devices | 167

Junos OS supports encryption method for configuration secrets using a master password. The master
password derives an encryption key that uses AES256-GCM to protect certain secrets such as private
keys, system master passwords, and other sensitive data by storing it in an AES256 encrypted format. For
more information, read this topic.
 165

Hardening Shared Secrets in Junos OS

IN THIS SECTION

Understanding Hardening Shared Secrets | 165

Understanding Hardening Shared Secrets

Existing shared secrets ($9$ format) in Junos OS currently use an obfuscation algorithm, which is not a
very strong encryption for configuration secrets. If you want a strong encryption for your configuration
secrets, you can configure a master password. The master password is used to derive an encryption key
that is used with AES256-GCM to encrypt configuration secrets. This new encryption method uses the
$8$ formatted strings.

Starting with Junos OS Release 15.1X49-D50, new CLI commands are introduced to configure a system
master password to provide stronger encryption for configuration secrets. The master password encrypts
secrets like the RADIUS password, IKE preshared keys, and other shared secrets in the Junos OS
management process (mgd) configuration. The master password itself is not saved as part of the
configuration. The password quality is evaluated for strength, and the device gives feedback if weak
passwords are used.

The master password is used as input to the password based key derivation function (PBKDF2) to generate
an encryption key. the key is used as input to the Advanced Encryption Standard in Galois/Counter Mode
(AES256-GCM). The plain text that the user enters is processed by the encryption algorithm (with key) to
produce the encrypted text (cipher text). See Figure 4 on page 165

Figure 4: Master Password Encryption

Master
PBKDF2
Password
Key

Plaintext AES256-GCM ciphertext

g043440

The $8$ configuration secrets can only be shared between devices using the same master password.

The $8$-encrypted passwords have the following format:

 166

$8$crypt-algo$hash-algo$iterations$salt$iv$tag$encrypted. See Table 11 on page 166 for the master

password format details.

Table 11: $8$-encrypted Password Format

Format Description

crypt-algo Encryption/decryption algorithm to be used. Currently only AES256-GCM is supported.

hash-algo Hash (prf) algorithm to be used for the PBKDF2 key derivation.

iterations The number of iterations to use for the PBKDF2 hash function. Current iteration-count
default is 100. The iteration count slows the hashing count, thus slowing attacker guesses.

salt Sequence of ASCII64-encoded pseudorandom bytes generated during encryption that are
to be used to salt (a random, but known string) the password and input to the PBKDF2 key
derivation.

iv A sequence of ASCII64-encoded pseudorandom bytes generated during encryption that are

to be used as initialization vector for the AES256-GCM encryption function.

tag ASCII64-encoded representation of the tag.

encrypted ASCII64-encoded representation of the encrypted password.

The ASCII64 encoding is Base64 (RFC 4648) compatible, except no padding (character “=”) is used to keep
the strings short. For example:
$8$aes256-gcm$hmac-sha2-256$100$y/4YMC4YDLU$fzYDI4jjN6YCyQsYLsaf8A$Ilu4jLcZarD9YnyD
/Hejww$okhBlc0cGakSqYxKww

Chassis Cluster Considerations

When defining a chassis cluster on SRX Series devices, be aware of the following restrictions:

• For SRX Series devices, first configure the master password on each node, and then build the cluster.
The same master password should be configured on each node.

• In chassis cluster mode, the master password cannot be deleted.

NOTE: A change in the master password would mean disruption in chassis clustering; therefore
you must change the password on both nodes independently.
 167

Using Trusted Platform Module to Bind Secrets on SRX Series Devices

IN THIS SECTION

Limitations | 168

Configuring Master Encryption Password | 168

Verifying the Status of the TPM | 169

Changing the Master Encryption Password | 169

By enabling the Trusted Platform Module (TPM) on the SRX Series devices, the software layer leverages
the use of the underlying TPM chip. TPM is a specialized chip that protects certain secrets at rest such as
private keys, system master passwords, and other sensitive data by storing it in an AES256 encrypted
format (instead of storing sensitive data in a clear text format). The device also generates a new SHA256
hash of the configuration each time the administrator commits the configuration. This hash is verified each
time the system boots up. If the configuration has been tampered with, the verification fails and the device
will not continue to boot. Both the encrypted data and the hash of the configuration is protected by the
TPM module using the master encryption password.

NOTE: Hash validation is performed during any commit operation by performing a validation
check of the configuration file against the saved hash from previous commits. In a chassis cluster
system, hash is independently generated on the backup system as part of the commit process.
A commit from any mode, that is, batch-config, dynamic-config, exclusive-config, or private
config generates the integrity hash.

NOTE: Hash is saved only for the current configuration and not for any rollback configurations.
Hash is not generated during reboot or shutdown of the device.

The TPM encrypts the following secrets:

• SHA256 hash of the configuration

• device master-password

• all key-pairs on the device

The TPM chip is available on the SRX300, SRX320, SRX340, SRX345, SRX5400, SRX5600, and SRX5800
devices. On SRX5400, SRX5600, and SRX5800 devices, TPM is supported only with SRX5K-RE3-128G
 168

Routing Engine (RE3). The TPM chip is enabled by default to make use of TPM functionality. You must
configure master encryption password to encrypt PKI key-pairs and configuration hash. To configure
master encryption password, see “Configuring Master Encryption Password” on page 168.

Limitations

The following limitations and exceptions apply to the configuration file integrity feature using TPM:

• This feature is supported only on the SRX300, SRX320, SRX340, SRX345, SRX5400, SRX5600, and
SRX5800 devices. On SRX5400, SRX5600, and SRX5800 devices, TPM is supported only with RE3.

• If the master encryption password is not set, data is stored unencrypted.

• The file integrity feature is not supported along with the configuration file encryption feature that uses
keys saved in EEPROM. You can enable only one function at a time.

• In a chassis cluster, both nodes must have the same TPM settings. This means that both nodes in the
chassis cluster must have TPM enabled, or both nodes in the chassis cluster must have TPM disabled.
The chassis cluster must not have one node set to TPM enabled and the another node set to TPM
disabled.

Configuring Master Encryption Password

NOTE: Before configuring master encryption password, ensure that you have configured set
system master-password plain-text-password otherwise, certain sensitive data will not be
protected by the TPM.

Set the master encryption password using the following CLI command:

request security tpm master-encryption-password set plain-text-password

You will be prompted to enter the master encryption password twice, to make sure that these passwords
match. The master encryption password is validated for required password strength.

After master encryption password is set, the system proceeds to encrypt the sensitive data with the master
encryption password which is encrypted by the Master Binding Key that is owned and protected by the
TPM chip.

NOTE: If there is any issue with setting the master encryption password, a critical ERROR
message is logged on the console and the process is aborted.
 169

Verifying the Status of the TPM

You can use the show security tpm status command to verify the status of the TPM. The following
information is displayed:

• TPM enabled/disabled

• TPM ownership

• TPM’s Master Binding Key status (created or not created)

• master encryption password status (set or not set)

Starting with Junos OS Release 15.1X49-D120 and Junos OS Release 17.4R1, Trusted Platform Module
(TPM) firmware has been updated. The upgraded firmware version provides additional secure cryptography
and improves security. Updated TPM firmware is available along with the Junos OS package. For updating
TPM Firmware, see Upgrading TPM Firmware on SRX-Devices. To confirm the TPM firmware version, use
the show security tpm status command. TPM Family and TPM Firmware version output fields are
introduced.

Changing the Master Encryption Password

Changing the master encryption password is done using the CLI.

To change the master encryption password, enter the following command from operational mode:

request security tpm master-encryption-password set plain-text-password

NOTE: It is recommended that no configuration changes are made while you are changing the
master encryption password.

The system checks if the master encryption password is already configured. If master encryption password
is configured, then you are prompted to enter the current master encryption password.

The entered master encryption password is validated against the current master encryption password to
make sure these master encryption passwords match. If the validation succeeds, you will be prompted to
enter the new master encryption password as plain text. You will be asked to enter the key twice to validate
the password.

The system then proceeds to re-encrypt the sensitive data with the new master encryption password. You
must wait for this process of re-encryption to complete before attempting to change the master encryption
password again.

If for some reason, the encrypted master encryption password file is lost or corrupted, the system will not
be able to decrypt the sensitive data. The system can only be recovered by re-importing the sensitive data
in clear text, and re-encrypting them.
 170

If the system is compromised, the administrator can recover the system using of the following method:

• Clear the TPM ownership in u-boot and then install the image in boot loader using TFTP or USB (if USB
port is not restricted).

NOTE: If the installed software version is older than Junos OS Release 15.1X49-D110 and the
master encryption password is enabled, then installation of Junos OS Release 15.1X49-D110
will fail. You must backup the configuration, certificates, key-pairs, and other secrets and use
the TFTP/USB installation procedure.

Release History Table

Release Description

17.4R1 Starting with Junos OS Release 15.1X49-D120 and Junos OS Release 17.4R1, Trusted Platform
Module (TPM) firmware has been updated. The upgraded firmware version provides additional
secure cryptography and improves security. Updated TPM firmware is available along with the
Junos OS package. For updating TPM Firmware, see Upgrading TPM Firmware on SRX-Devices.
To confirm the TPM firmware version, use the show security tpm status command. TPM Family
and TPM Firmware version output fields are introduced.

15.1X49-D50 Starting with Junos OS Release 15.1X49-D50, new CLI commands are introduced to configure a
system master password to provide stronger encryption for configuration secrets.

RELATED DOCUMENTATION

master-password | 1188
Root Password | 142
Plain-Text Passwords | 161
4 CHAPTER

User Authentication

Junos OS User Authentication Overview | 172

Authentication Order for RADIUS, TACACS+, and Local Password | 182

RADIUS Authentication | 197

RADIUS over TLS (RADSEC) | 223

TACACS+ Authentication | 227

Authentication for Routing Protocols | 247

 172

Junos OS User Authentication Overview

IN THIS SECTION

Junos OS User Authentication Methods | 172

Configuring Local User Template Accounts for User Authentication | 173

Configuring Remote Template Accounts for User Authentication | 175

Example: Creating Template Accounts | 176

Understanding Remote Authentication Servers | 180

Local Password Authentication with Remote Authorization on TACACS+ Server | 181

Junos OS supports different methods such as local password authentication, RADIUS and TACACS+ to
control access to the network. Authentication methods are used for validating users who attempt to access
the router or switch using telnet. Authentication prevents unauthorized devices and users from gaining
access to your LAN. For more information, read this topic.

Junos OS User Authentication Methods

The Junos OS supports three methods of user authentication: local password authentication, Remote
Authentication Dial-In User Service (RADIUS), and Terminal Access Controller Access Control System Plus
(TACACS+).

With local password authentication, you configure a password for each user allowed to log in to the router
or switch.

RADIUS and TACACS+ are authentication methods for validating users who attempt to access the router
or switch using telnet. They are both distributed client-server systems—the RADIUS and TACACS+ clients
run on the router or switch, and the server runs on a remote network system.

You can configure the router or switch to be both a RADIUS and TACACS+ client, and you can also configure
authentication passwords in the Junos OS configuration file. You can prioritize the methods to configure
the order in which the software tries the different authentication methods when verifying user access.

You can control access to your network using several different authentication methods—media access
control (MAC) RADIUS, for example. Authentication prevents unauthorized devices and users from gaining
access to your LAN. For MAC RADIUS authentication, end devices must be authenticated before they
receive an IP address from a DHCP server.
 173

NOTE: Note about the MAC RADIUS authentication:

• You can enable end devices to access the network without authenticating on the RADIUS
server by configuring the MAC address of the end device in the static MAC bypass list by
configuring the MAC address using the authentication-whitelist statement.

• You can configure one or more authentication methods on a single interface and thereby
enable fallback to the next method if the first or second method is unsuccessful.

• On a single interface you can configure one or a combination of several authentication methods.

• The EAP method supported for MAC RADIUS authentication is EAP-MD5.

• You can configure MAC RADIUS authentication on interfaces that are connected to end
devices.

• When you configure the mac-radius restrict option, the switch immediately attempts a MAC-
RADIUS authentication by sending a request to the RADIUS server for authentication of the
MAC address of the end device. If MAC address of the end device is configured for RADIUS
authentication, LAN access between the two switches is created.

SEE ALSO

Configuring RADIUS Server Authentication | 197

Configuring TACACS+ Authentication | 228
Junos OS Authentication Order for RADIUS, TACACS+, and Password Authentication | 182

Configuring Local User Template Accounts for User Authentication

You use local user template accounts when you need different types of templates for authentication. Each
template can define a different set of permissions appropriate for the group of users who use that template.
These templates are defined locally on the router or switch and referenced by the TACACS+ and RADIUS
authentication servers.

When you configure local user templates and a user logs in, Junos OS issues a request to the authentication
server to authenticate the user’s login name. If a user is authenticated, the server returns the local username
to Junos OS, which then determines whether a local username is specified for that login name
(local-username for TACACS+, Juniper-Local-User for RADIUS). If so, Junos OS selects the appropriate
local user template locally configured on the router or switch. If a local user template does not exist for
the authenticated user, the router or switch defaults to the remote template.
 174

To configure different access privileges for users who share the local user template account, include the
allow-commands and deny-commands commands in the authentication server configuration file.

To configure a local user template, include the user local-username statement at the [edit system login]
hierarchy level and specify the privileges you want to grant to the local users to whom the template applies:

[edit system login]

user local-username {
full-name "Local user account";
uid uid-value;
class class-name;
}

This example configures the sales and engineering local user templates:

[edit]
system {
login {
user sales {
uid uid-value;
class class-name;
}
user engineering {
uid uid-value;
class class-name;
}
}
}

user = simon {
...
service = junos-exec {
local-user-name = sales
allow-commands = "configure"
deny-commands = "shutdown"
}
}
user = rob {
...
service = junos-exec {
local-user-name = sales
allow-commands = "(request system) | (show rip neighbor)"
deny-commands = "clear"
 175

}
}
user = harold {
...
service = junos-exec {
local-user-name = engineering
allow-commands = "monitor | help | show | ping | traceroute"
deny-commands = "configure"
}
}
user = jim {
...
service = junos-exec {
local-user-name = engineering
allow-commands = "show bgp neighbor"
deny-commands = "telnet | ssh"
}
}

When the login users Simon and Rob are authenticated, the router or switch applies the sales local user
template. When login users Harold and Jim are authenticated, the router or switch applies the engineering
local user template.

SEE ALSO

Example: Configuring Authentication Order | 191

user (Access) | 1326

Configuring Remote Template Accounts for User Authentication

By default, the Junos OS uses remote template accounts for user authentication when:

• The authenticated user does not exist locally on the router or switch.

• The authenticated user’s record in the authentication server specifies local user, or the specified local
user does not exist locally on the router or switch.

To configure the remote template account, include the user remote statement at the [edit system login]
hierarchy level and specify the privileges you want to grant to remote users:
 176

[edit system login]

user remote {
full-name "All remote users";
uid uid-value;
class class-name;
}

To configure different access privileges for users who share the remote template account, include the
allow-commands and deny-commands statements in the authentication server configuration file.

SEE ALSO

Example: Configuring Authentication Order | 191

user (Access) | 1326

Example: Creating Template Accounts

IN THIS SECTION

Requirements | 176

Overview | 176

Configuration | 177

Verification | 179

This example shows how to create template accounts.

Requirements

No special configuration beyond device initialization is required before configuring this feature.

Overview

You can create template accounts that are shared by a set of users when you are using RADIUS or TACACS+
authentication. When a user is authenticated by a template account, the CLI username is the login name,
and the privileges, file ownership, and effective user ID are inherited from the template account.
 177

By default, Junos OS uses the remote template account when:

• The authenticated user does not exist locally on the device.

• The authenticated user's record in the RADIUS or TACACS+ server specifies local user, or the specified
local user does not exist locally on the device.

In this example, you create a remote template account and set the username to remote and the login class
for the user as operator. You create a remote template that is applied to users authenticated by RADIUS
or TACACS+ that do not belong to a local template account.

You then create a local template account and set the username as admin and the login class as superuser.
You use local template accounts when you need different types of templates. Each template can define a
different set of permissions appropriate for the group of users who use that template.

Configuration

IN THIS SECTION

Creating a Remote Template Account | 177

Creating a Local Template Account | 178

Creating a Remote Template Account

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, copy and paste the
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

set system login user remote class operator

Step-by-Step Procedure
 178

The following example requires you to navigate various levels in the configuration hierarchy. For instructions
on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To create a remote template account:

• Set the username and the login class for the user.

[edit system login]

user@host# set user remote class operator

Results
From configuration mode, confirm your configuration by entering the show system login command. If the
output does not display the intended configuration, repeat the configuration instructions in this example
to correct it.

[edit]
user@host# show system login
user remote {
class operator;
}

If you are done configuring the device, enter commit from configuration mode.

Creating a Local Template Account

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, copy and paste the
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

set system login user admin class superuser

Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions
on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To create a local template account:

1. Set the username and the login class for the user.

[edit system login]

user@host# set user admin class superuser
 179

Results
From configuration mode, confirm your configuration by entering the show system login command. If the
output does not display the intended configuration, repeat the configuration instructions in this example
to correct it.

[edit]
user@host# show system login
user admin {
class super-user;
}

If you are done configuring the device, enter commit from configuration mode.

NOTE: To completely set up RADIUS or TACACS+ authentication, you must configure at least
one RADIUS or TACACS+ server and specify a system authentication order. Do one of the
following tasks:

• Configure a RADIUS server. See “Example: Configuring a RADIUS Server for System
Authentication” on page 203.

• Configure a TACACS+ server. See “Example: Configuring a TACACS+ Server for System
Authentication” on page 232.

• Configure system authentication order. See “Example: Configuring Authentication Order” on

page 191.

Verification

Confirm that the configuration is working properly.

Verifying the Template Accounts Creation

Purpose
Verify that the template accounts have been created.

Action
From operational mode, enter the show system login command.

SEE ALSO

Junos OS User Accounts Overview | 57

 180

Understanding Remote Authentication Servers

You probably already use a remote authentication server (or servers) in your network. It is a recommended
best practice, because the servers allow you to centrally create a consistent set of user accounts for all
devices in your network. There are many good reasons for implementing a authentication, authorization,
and accountability (AAA) solution in your network, not the least of which is to make the management of
user accounts easier.

There are two basic methods of remote authentication in use by most enterprises today—RADIUS and
TACACS+. Junos OS supports both types and can be configured to query multiple remote authentication
servers of both types. The idea behind a RADIUS or TACACS+ server is simple, a central authentication
server that routers, switches, security devices, and even servers can use to authenticate users as they
attempt to gain access to these systems. Think of the advantages that a central user directory brings for
authentication auditing and access control in a client server model, and you have your justification for
RADIUS or TACACS+ for your networks infrastructure.

Using a central server has multiple advantages over the alternative of creating local users on each device,
a time-consuming and error-prone task. A central authentication system also simplifies the use of one-time
password systems such as SecureID, which offer protection against password sniffing and password replay
attacks, in which someone uses a captured password to pose as a system administrator.

• RADIUS—You should use RADIUS when your priorities are interoperability and performance.

• Interoperability—RADIUS is more interoperable than TACACS+, primarily because of the proprietary

nature of TACACS+. While TACACS+ supports more protocols, RADIUS is universally supported.

• Performance—RADIUS is much lighter on your routers and switches and for this reason, network
engineers generally prefer RADIUS over TACACS+.

• TACACS+—You should use TACACS+ when your priorities are security and flexibility.

• Security—TACACS+ is more secure than RADIUS. Not only is the full session encrypted, but
authorization and authentication are done separately to prevent someone from trying to force their
way into your network.

• Flexibility—TCP is a more flexible transport protocol than UDP. You can do more with it in more
advanced networks. In addition, TACACS+ supports more of the enterprise protocols like NetBios or
Appletalk.
 181

Local Password Authentication with Remote Authorization on TACACS+

Server

By default, Junos OS supports local authorization for locally authenticated users and remote authorization
for users remotely authenticated on TACACS+ or RADIUS servers.

Starting in Release 19.3R1, Junos OS supports remote authorization on TACACS+ servers for locally
authenticated users. After users have successfully authenticated and logged in locally, Junos fetches their
remotely configured authorization parameters on TACACS+ server and combine them with their locally
configured parameters.

To enable the feature, include the tacplus-authorization option at the [edit system password-options]
hierarchy level.

[edit system password-options]

tacplus-authorization;

NOTE:
• In Junos OS Release 19.3R1, remote authorization on TACACS+ server through local
authentication is supported on MX Series routers.

• You must configure password under authentication-order when password-options is configured.

• The feature does not work in a local fallback scenario because password is not configured
under authentication-order for a local fallback scenario.

RELATED DOCUMENTATION

Authentication Order for RADIUS, TACACS+, and Local Password | 182

RADIUS Authentication | 197
TACACS+ Authentication | 227
 182

Authentication Order for RADIUS, TACACS+, and

Local Password

IN THIS SECTION

Junos OS Authentication Order for RADIUS, TACACS+, and Password Authentication | 182

Configuring the Junos OS Authentication Order for RADIUS, TACACS+, and Local Password
Authentication | 189

Example: Configuring Authentication Order | 191

Example: Configuring System Authentication for RADIUS, TACACS+, and Password Authentication | 194

Junos OS supports different methods such as local password authentication, RADIUS and TACACS+ to
control access to the network. Authentication methods are used for validating users who attempt to access
the router or switch using telnet. You can prioritize the methods to configure the order in which the Junos
OS tries the different authentication methods when verifying user access to a router or switch or security
device. For more information, read this topic.

Junos OS Authentication Order for RADIUS, TACACS+, and Password

Authentication

Using the authentication-order statement, you can prioritize the order in which the Junos OS tries the
different authentication methods when verifying user access to a router or switch.

If RADIUS and/or TACACS+ servers are configured in the authentication order but there is no response
from them to a request, the Junos OS always defaults to trying local password authentication as a last
resort. If the authentication order is set to authentication-order password, that will be the only
authentication method attempted.

NOTE: It is not possible and would make no sense to try to configure local password
authentication ahead of RADIUS or TACACS+ in the order because “no response” cannot happen.
A local authentication request will always either be accepted or rejected.
 183

The handling of a rejected authentication request when RADIUS or TACACS+ are present is more
complicated.

• If password (local password authentication) is not in the authentication order, a RADIUS and/or TACACS+
rejection ends with the rejection.

• If password is included at the end of the authentication order and RADIUS and/or TACACS+ rejects the
authentication, the Junos OS tries for a local authentication check.

In other words, including password as a final authentication order option is a means by which you can
choose whether a RADIUS and/or TACACS+ rejection ends there or if the request is to be given one last
chance for authentication locally.

Using RADIUS or TACACS+ Authentication

You can configure the Junos OS to be both a RADIUS and TACACS+ authentication client.

If an authentication method included in the [authentication-order] statement is not available, or if the

authentication is available but returns a reject response, the Junos OS tries the next authentication method
included in the authentication-order statement.

The RADIUS or TACACS+ server authentication might fail because of the following reasons:

• The authentication method is configured, but the corresponding authentication servers are not configured.
For instance, the RADIUS and TACACS+ authentication methods are included in the authentication-order
statement, but the corresponding RADIUS or TACACS+ servers are not configured at the respective
[edit system radius-server] and [edit system tacplus-server] hierarchy levels.

• The RADIUS or TACACS+ server does not respond within the timeout period configured at the [edit
system radius-server] or [edit system tacplus-server] hierarchy levels.

• The RADIUS or TACACS+ server is not reachable because of a network problem.

The RADIUS or TACACS+ server authentication might return a reject response because of the following
reasons:

• The user profiles of users accessing a router or switch might not be configured on the RADIUS or
TACACS+ server.

• The user enters incorrect logon credentials.

Using Local Password Authentication

You can explicitly configure the password authentication method or use this method as a fallback mechanism
when remote authentication servers fail. The password authentication method consults the local user
profiles configured at the [edit system login] hierarchy level. Users can log in to a router or switch using
their local username and password in the following scenarios:
 184

• The password authentication method (password) is explicitly configured as one of the authentication
methods in the [authentication-order authentication-methods] statement. In this case, the password
authentication method is tried if no previous authentication accepts the logon credentials. This is true
whether the previous authentication method fails to respond or returns a reject response because of
an incorrect username or password.

• The password authentication method is not explicitly configured as one of the authentication methods
in the authentication-order authentication-methods statement. In this case, the password authentication
method is tried only if all configured authentication methods fail to respond. It is not consulted if any
configured authentication method returns a reject response because of an incorrect username or
password.

Order of Authentication Attempts

Table 12 on page 184 describes how the authentication-order statement at the [edit system] hierarchy
level determines the procedure that the Junos OS uses to authenticate users for access to a router or
switch.

Table 12: Order of Authentication Attempts

Syntax Order of Authentication Attempts

authentication-order radius; 1. Try configured RADIUS authentication servers.

2. If RADIUS server is available and authentication is

accepted, grant access.

3. If RADIUS server is available but authentication is

rejected, deny access.

4. If RADIUS servers are not available, try password

authentication.

NOTE: If a RADIUS server is available, password

authentication is not attempted, because it is not
explicitly configured in the authentication order.

authentication-order [ radius password ]; 1. Try configured RADIUS authentication servers.

2. If RADIUS servers fail to respond or return a reject

response, try password authentication, because it is
explicitly configured in the authentication order.
 185

Table 12: Order of Authentication Attempts (continued)

Syntax Order of Authentication Attempts

authentication-order [ radius tacplus ]; 1. Try configured RADIUS authentication servers.

2. If RADIUS server is available and authentication is

accepted, grant access.

3. If RADIUS servers fail to respond or return a reject

response, try configured TACACS+ servers.

4. If TACACS+ server is available and authentication is

accepted, grant access.

5. If TACACS+ server is available but authentication is

rejected, deny access.

6. If both RADIUS and TACACS+ servers are not available,

try password authentication.

NOTE: If either RADIUS or TACACS+ servers are

available, password authentication is not attempted,
because it is not explicitly configured in the
authentication order.

authentication-order [ radius tacplus password ]; 1. Try configured RADIUS authentication servers.

2. If RADIUS server is available and authentication is

accepted, grant access.

3. If RADIUS servers fail to respond or return a reject

response, try configured TACACS+ servers.

4. If TACACS+ server is available and authentication is

accepted, grant access.

5. If TACACS+ servers fail to respond or return a reject

response, try password authentication, because it is
explicitly configured in the authentication order.
 186

Table 12: Order of Authentication Attempts (continued)

Syntax Order of Authentication Attempts

authentication-order tacplus; 1. Try configured TACACS+ authentication servers.

2. If TACACS+ server is available and authentication is

accepted, grant access.

3. If TACACS+ server is available but authentication is

rejected, deny access.

4. If TACACS+ servers are not available, try password

authentication.

NOTE: If a TACACS+ server is available, password

authentication is not attempted, because it is not
explicitly configured in the authentication order.

authentication-order [ tacplus password ]; 1. Try configured TACACS+ authentication servers.

2. If TACACS+ servers fail to respond or return a reject

response, try password authentication, because it is
explicitly configured in the authentication order.
 187

Table 12: Order of Authentication Attempts (continued)

Syntax Order of Authentication Attempts

authentication-order [ tacplus radius ]; 1. Try configured TACACS+ authentication servers.

2. If TACACS+ server is available and authentication is

accepted, grant access.

3. If TACACS+ servers fail to respond or return a reject

response, try configured RADIUS servers.

4. If RADIUS server is available and authentication is

accepted, grant access.

5. If RADIUS server is available but authentication is

rejected, deny access.

6. If both TACACS+ and RADIUS servers are not available,

try password authentication.

NOTE: If either TACACS+ or RADIUS servers are

available, password authentication is not attempted,
because it is not explicitly configured in the
authentication order.

authentication-order [ tacplus radius password ]; 1. Try configured TACACS+ authentication servers.

2. If TACACS+ server is available and authentication is

accepted, grant access.

3. If TACACS+ servers fail to respond or return a reject

response, try configured RADIUS servers.

4. If RADIUS server is available and authentication is

accepted, grant access.

5. If RADIUS servers fail to respond or return a reject

response try password authentication, because it is
explicitly configured in the authentication order.
 188

Table 12: Order of Authentication Attempts (continued)

Syntax Order of Authentication Attempts

authentication-order password; 1. Try to authenticate the user, using the password

configured at the [edit system login] hierarchy level.

2. If the authentication is accepted, grant access.

3. If the authentication is rejected, deny access.

NOTE: If SSH public keys are configured, SSH user authentication first tries to perform public
key authentication before using the authentication methods configured in the
authentication-order statement. If you want SSH logins to use the authentication methods
configured in the authentication-order statement without first trying to perform public key
authentication, do not configure SSH public keys.

In a routing matrix based on a TX Matrix router, the authentication order must be configured
only at the configuration groups re0 and re1. The authentication order must not be configured
at the [edit system] hierarchy. This is because the authentication order for the routing matrix is
controlled on the switch-card chassis (or TX Matrix router) or switch-fabric chassis (for TX Matrix
Plus router) only.

In Junos OS Release 10.0 and later, the superuser (belonging to the super-user login class) is also
authenticated based on the authentication order that is configured for TACACS+, RADIUS, or
password authentication using the authentication-order statement. For example, if the only
configured authentication order is TACACS+, the superuser can only be authenticated by the
TACACS+ server and password authentication cannot be used as an alternative. However, in
Junos OS Release 9.6 and earlier, the superuser can use password authentication to login, even
if password authentication is not configured explicitly using the authentication-order statement.

SEE ALSO

Limiting the Number of User Login Attempts for SSH and Telnet Sessions | 50
Example: Configuring System Authentication for RADIUS, TACACS+, and Password Authentication | 194
 189

Configuring the Junos OS Authentication Order for RADIUS, TACACS+,

and Local Password Authentication

Using the authentication-order statement, you can prioritize the order in which the Junos OS tries the
different authentication methods when verifying user access to a router or switch. If you do not set the
authentication order, by default users are verified based on their configured passwords.

When configuring a password using plain text and relying on Junos OS to encrypt it, you are still sending
the password over the internet in plain text. Using pre-encrypted passwords is more secure because it
means that the plain text of the password never has to be sent over the internet. Also, with passwords,
only one user can be assigned to a password at a time.

On the other hand, both RADIUS and TACACS+ pre-ecrypt passwords. Both let you assign a set of users
at a time instead of one by one. But here are how these authentication systems differ:

• RADIUS uses UDP, while TACACS+ uses TCP.

• RADIUS encrypts only the password during transmission whereas TACACS+ encrypts the entire session.

• RADIUS combines authentication (device) and authorization (user) whereas TACACS+ separates
authentication, authorization, and accountability.

In short, TACACAS+ is the more secure of the two. However, RADIUS has better performance and is more
interoperable. RADIUS is widely supported, whereas TACACS+ is a Cisco proprietary product and not
widely supported outside of Cisco.

You can configure the authentication order based on your system, its restrictions, and your IT policy and
operational preferences.

To configure the authentication order, include the authentication-order statement at the [edit system]
hierarchy level:

[edit system]
authentication-order (System) [ authentication-methods ];

For a list of hierarchy levels at which you can include this statement, see the statement summary section
for this statement.
 190

Following are the possible authentication order entry options:

• radius—Verify the user using RADIUS authentication servers.

• tacplus—Verify the user using TACACS+ authentication servers.

• password—Verify the user using the username and password configured locally by including the
authentication statement at the [edit system login user] hierarchy level.

If RADIUS and/or TACACS+ servers are configured in the authentication order but there is no response
from them to a request, the Junos OS always defaults to trying local password authentication as a last
resort. If the authentication order is set to authentication-order password, that will be the only
authentication method attempted.

NOTE: It is not possible and would make no sense to try to configure local password
authentication ahead of RADIUS or TACACS+ in the order because “no response” cannot happen.
A local authentication request will always either be accepted or rejected.

The handling of a rejected authentication request when RADIUS or TACACS+ are present is more
complicated.

• If password (local password authentication) is not in the authentication order, a RADIUS and/or TACACS+
rejection ends with the rejection.

• If password is included at the end of the authentication order and RADIUS and/or TACACS+ rejects the
authentication, the Junos OS tries for a local authentication check.

In other words, including password as a final authentication order option is a means by which you can
choose whether a RADIUS and/or TACACS+ rejection ends there or if the request is to be given one last
chance for authentication locally.

For more details, see “Junos OS Authentication Order for RADIUS, TACACS+, and Password Authentication”
on page 182.

The CHAP authentication sequence cannot take more than 30 seconds. If it takes longer to authenticate
a client, the authentication is abandoned and a new sequence is initiated.

For example, if you configure three RADIUS servers so that the router or switch attempts to contact each
server three times, and with each retry the server times out after 3 seconds, then the maximum time given
to the RADIUS authentication method before CHAP considers it a failure is 27 seconds. If you add more
RADIUS servers to this configuration, they might not be contacted because the authentication process
might be abandoned before these servers are tried.

The Junos OS enforces a limit on the number of standing authentication server requests that the CHAP
authentication can have at one time. Thus, an authentication server method—RADIUS, for example—might
fail to authenticate a client when this limit is exceeded. If it fails, the authentication sequence is reinitiated
 191

by the router or switch until authentication succeeds and the link is brought up. However, if the RADIUS
servers are not available and if additional authentication methods such as tacplus or password are configured
along with radius, the next authentication method is tried.

The following example shows how to configure radius and password authentication:

[edit system]
user@switch# authentication-order [ radius password ];

The following example shows how to delete the radius statement from the authentication order:

[edit system]
user@switch# delete authentication-order radius

The following example shows how to insert the tacplus statement after the radius statement:

[edit system]
user@switch# insert authentication-order tacplus after radius

SEE ALSO

Using Regular Expressions on a RADIUS or TACACS+ Server to Allow or Deny Access to Commands | 237
authentication-order (System) | 1061

Example: Configuring Authentication Order

IN THIS SECTION

Requirements | 192

Overview | 192

Configuration | 192

Verification | 194

This example shows how to configure authentication order.

 192

Requirements

Before you begin, perform the initial device configuration. See the Getting Started Guide for your device.

Overview

You can configure the authentication methods that the device uses to verify that a user can gain access.
For each login attempt, the device tries the authentication methods in order, starting with the first one,
until the password matches. If you do not configure system authentication, users are verified based on
their configured local passwords.

This example configures the device to attempt user authentication with the local password first, then with
the RADIUS server, and finally with the TACACS+ server.

When you use local password authentication, you must create a local user account for every user who
wants to access the system. However, when you are using RADIUS or TACACS+ authentication, you can
create single accounts (for authorization purposes) that are shared by a set of users. You create these
accounts using the remote and local user template accounts. When a user is using a template account, the
command-line interface (CLI) username is the login name; however, the privileges, file ownership, and
effective user ID are inherited from the template account.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, copy and paste the
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

insert system authentication-order radius after password

insert system authentication-order tacplus after radius

GUI Step-by-Step Procedure

To configure authentication order:

1. In the J-Web user interface, select Configure>System Properties>User Management.

2. Click Edit. The Edit User Management dialog box appears.

3. Select the Authentication Method and Order tab.

4. Under Available Methods, select the authentication method the device should use to authenticate
users, and use the arrow button to move the item to the Selected Methods list. Available methods
include:
 193

• RADIUS

• TACACS+

• Local Password

If you want to use multiple methods to authenticate users, repeat this step to add the additional methods
to the Selected Methods list.

5. Under Selected Methods, use the Up Arrow and Down Arrow to specify the order in which the device
should execute the authentication methods.

6. Click OK to check your configuration and save it as a candidate configuration.

7. If you are done configuring the device, click Commit Options>Commit.

Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions
on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure authentication order:

1. Add RADIUS authentication to the authentication order.

[edit]
user@host# insert system authentication-order radius after password

2. Add TACACS+ authentication to the authentication order.

[edit]
user@host# insert system authentication-order tacplus after radius

Results
From configuration mode, confirm your configuration by entering the show system authentication-order
command. If the output does not display the intended configuration, repeat the configuration instructions
in this example to correct it.

[edit]
user@host# show system authentication-order
authentication-order [password, radius, tacplus];

If you are done configuring the device, enter commit from configuration mode.
 194

NOTE: To completely set up RADIUS or TACACS+ authentication, you must configure at least
one RADIUS or TACACS+ server and create user template accounts. Do one of the following
tasks:

• Configure a RADIUS server. See “Example: Configuring a RADIUS Server for System
Authentication” on page 203.

• Configure a TACACS+ server. See “Example: Configuring a TACACS+ Server for System
Authentication” on page 232.

• Configure a user. See “Example: Configuring New Users” on page 61.

• Configure template accounts. See “Example: Creating Template Accounts” on page 176.

Verification

Confirm that the configuration is working properly.

Verifying the Authentication Order Configuration

Purpose
Verify that the authentication order has been configured.

Action
From operational mode, enter the show system authentication-order command.

SEE ALSO

Junos OS User Accounts Overview | 57

Junos OS User Authentication Methods | 172

Example: Configuring System Authentication for RADIUS, TACACS+, and

Password Authentication

The following example shows how to configure system authentication for RADIUS, TACACS+, and password
authentication.

In this example, only the user Philip and users authenticated by a remote RADIUS server can log in. If a
user logs in and is not authenticated by the RADIUS server, the user is denied access to the router or
switch. If the RADIUS server is not available, the user is authenticated using the password authentication
 195

method and allowed access to the router or switch. For more information about the password authentication
method, see “Junos OS Authentication Order for RADIUS, TACACS+, and Password Authentication” on
page 182.

When Philip tries to log in to the system, if the RADIUS server authenticates him, he is given access and
privileges for the super-user class. Local accounts are not configured for other users. When they log in to
the system and the RADIUS server authenticates them, they are given access using the same user ID (UID)
9999 and the privileges associated with the operator class.

[edit]
system {
authentication-order radius;
login {
user philip {
full-name "Philip";
uid 1001;
class super-user;
}
user remote {
full-name "All remote users";
uid 9999;
class operator;
}
}
}

NOTE: For authorization purposes, you can use a template account to create a single account
that can be shared by a set of users at the same time. For example, when you create a remote
template account, a set of remote users can concurrently share a single UID. For more information
about template accounts, see “Example: Configuring Authentication Order” on page 191.

When a user logs in to a device, the user’s login name is used by the RADIUS or TACACS+ server for
authentication. If the user is authenticated successfully by the authentication server and the user is not
configured at the [edit system login user] hierarchy level, the device uses the default remote template
user account for the user, provided a remote template account is configured at the edit system login user
remote hierarchy level. The remote template account serves as a default template user account for all
users that are authenticated by the authentication server but not having a locally configured user account
on the device. Such users share the same login class and UID.

To configure an alternate template user, specify the user-name parameter returned in the RADIUS
authentication response packet. Not all RADIUS servers allow you to change this parameter. The following
shows a sample Junos OS configuration:
 196

[edit]
system {
authentication-order radius;
login {
user philip {
full-name "Philip";
uid 1001;
class super-user;
}
user operator {
full-name "All operators";
uid 9990;
class operator;
}
user remote {
full-name "All remote users";
uid 9999;
class read-only;
}
}
}

Assume your RADIUS server is configured with the following information:

• User Philip with password “olympia”

• User Alexander with password “bucephalus” and username “operator”

• User Darius with password “redhead” and username “operator”

• User Roxane with password “athena”

Philip would be given access as a superuser (super-user) because he has his own local user account.
Alexander and Darius share UID 9990 and have access as operators. Roxane has no template-user override,
so she shares access with all the other remote users, getting read-only access.

SEE ALSO

Configuring the Junos OS Authentication Order for RADIUS, TACACS+, and Local Password
Authentication | 189

RELATED DOCUMENTATION

Junos OS User Authentication Overview | 172

 197

RADIUS Authentication | 197

TACACS+ Authentication | 227

RADIUS Authentication

IN THIS SECTION

Configuring RADIUS Server Authentication | 197

Example: Configuring a RADIUS Server for System Authentication | 203

Example: Configuring RADIUS Authentication | 206

Configuring RADIUS Authentication (QFX Series or OCX Series) | 208

Juniper Networks Vendor-Specific RADIUS Attributes | 211

Juniper-Switching-Filter VSA Match Conditions and Actions | 215

Understanding RADIUS Accounting | 218

Configuring RADIUS System Accounting | 219

The Junos OS supports RADIUS for central authentication of users on multiple routers or switches or
security devices. To use RADIUS authentication on the device, you must configure information about one
or more RADIUS servers on the network. You can also configure RADIUS accounting on the device to
collect statistical data about the users logging in to or out from a LAN and sending the data to a RADIUS
accounting server. For more information, read this topic.

Configuring RADIUS Server Authentication

IN THIS SECTION

Why Use RADIUS | 198

Configuring RADIUS Server Details | 198

Configuring RADIUS To Use the Management Instance | 202

 198

RADIUS authentication is a method of authenticating users who attempt to access the router or switch.

Why Use RADIUS

The Junos OS supports two protocols for central authentication of users on multiple routers: RADIUS and
TACACS+. We recommend RADIUS because it is a multivendor IETF standard, and its features are more
widely accepted than those of TACACS+ or other proprietary systems. In addition, we recommend using
a one-time-password system for increased security, and all vendors of these systems support RADIUS.

You should use RADIUS when your priorities are interoperability and performance:

• Interoperability—RADIUS is more interoperable than TACACS+, primarily because of the proprietary

nature of TACACS+. While TACACS+ supports more protocols, RADIUS is universally supported.

• Performance—RADIUS is much lighter on your routers and switches and for this reason, network engineers
generally prefer RADIUS over TACACS+.

Configuring RADIUS Server Details

To use RADIUS authentication on the device, configure information about one or more RADIUS servers
on the network by including one radius-server statement at the [edit system] hierarchy level for each
RADIUS server.

Because remote authentication is configured on multiple devices, it is commonly configured inside of a

configuration group. As such, the steps shown here are in a configuration group called global. Using a
configuration group is optional.

NOTE: The remote statement must always be lowercase.

NOTE: This feature is supported on SRX1500, SRX5400, SRX5600, and SRX5800 devices.
 199

To configure authentication by a RADIUS server:

1. Add an IPv4 or IPv6 server address.

• Configure an IPv4 source-address and server-address:

[edit groups global]

user@host# set system radius-server server-address source-address source-address

For example:

[edit groups global]

user@host# set system radius-server 192.168.17.28 source-address 192.168.17.1

• Configure an IPv6 source-address and server address:

[edit groups global system radius-server server-address]

user@host# set server-address secret “secretkey” source-address-inet6 source-address

For example:

[edit groups global system radius-server ::17.22.22.162]

user@host# set secret $9$lPOv87ZGiH.5JGn/AtOB7-dVgo source-address-inet6 ::17.22.22.1

Source address is a valid IPv4 or IPv6 address configured on one of the router or switch interfaces.
This sets a fixed address as the source address for locally generated IP packets.

Server address is a unique IPv4 or IPv6 address that is assigned to a particular server and used to
route information to the server. If the Junos OS device has several interfaces that can reach the
RADIUS server, assign an IP address that Junos OS can use for all its communication with the RADIUS
server.

2. Include a shared secret password.

You must specify a password in the secret password statement. If the password contains spaces, enclose
it in quotation marks. The secret password used by the local router or switch must match that used by
the server. The secret password configures the password that the Junos OS device uses to access the
RADIUS server.

[edit groups global system radius-server server-address]

user@host# set secret password
 200

For example:

[edit groups global system radius-server 192.168.69.162]

user@host# set secret $9$gQ4UHf5F36CiH.5Tz9CuO1hreM8xw2oIENVwgZG

3. If necessary, specify a port on which to contact the RADIUS server.

By default, port number 1812 is used (as specified in RFC 2865).

NOTE: You can also specify an accounting port to send accounting packets with the
accounting-port statement. The default is 1813 (as specified in RFC 2866).

[edit groups global system radius-server server-address]

user@host# set port port-number

For example:

[edit groups global system radius-server 192.168.69.162]

user@host# set port 1845

4. Specify the order in which Junos OS attempts authentication.

You must include the authentication-order statement in your remote authentication configuration.

The example assumes your network includes both RADIUS and TACACS+ servers. In this example,
whenever a user attempts to log in, Junos OS begins by querying the RADIUS server for authentication.
If it fails, it next attempts authentication with locally configured user accounts. Finally the TACACS+
server is tried.

[edit groups global system]

user@host# set authentication-order [ authentication-methods ]

For example:

[edit groups global system]

user@host# set authentication-order [ radius password tacplus ]

5. Assign a login class to RADIUS-authenticated users.

 201

You can assign different user templates and login classes to RADIUS-authenticated users. This allows
RADIUS-authenticated users to be granted different administrative permissions on the Junos OS device.
By default, RADIUS-authenticated users use the remote user template and are assigned to the associated
class, which is specified in the remote user template, if the remote user template is configured. The
username remote is a special case in Junos OS. It acts as a template for users who are authenticated
by a remote server, but do not have a locally configured user account on the device. In this method,
Junos OS applies the permissions of the remote template to those authenticated users without a locally
defined account. All users mapped to the remote template are of the same login class.

In the Junos OS configuration, a user template is configured in the same way as a regular local user
account, except that no local authentication password is configured because the authentication is
remotely performed on the RADIUS server.

• To use the same permissions for all RADIUS-authenticated users:

[edit groups global system login]

user@host# set user remote class class

For example:

[edit groups global system login]

user@host# set user remote class super-user

• To have different login classes be used for different RADIUS-authenticated users, granting them
different permissions:

a. Create multiple user templates in the Junos OS configuration.

Every user template can be assigned a different login class.

For example:

[edit groups global system login]

set user RO class read-only
set user OP class operator
set user SU class super-user
set user remote full-name "default remote access user template"
set user remote class read-only

b. Have the RADIUS server specify the name of the user template to be applied to the authenticated
user.

For a RADIUS server to indicate which user template is to be applied, it needs to include the
Juniper-Local-User-Name attribute (Vendor 2636, type 1, string) Juniper VSA (vendor-specific
attribute) in the RADIUS Access-Accept message. The string value in the Juniper-Local-User-Name
 202

must correspond to the name of a configured user template on the device. For a list of relevant
Juniper RADIUS VSAs, see “Juniper Networks Vendor-Specific RADIUS Attributes” on page 211.

If the Juniper-Local-User-Name is not included in the Access-Accept message or the string contains
a user template name that does not exist on the device, the user is assigned to the remote user
template, if configured. If it is not configured, authentication fails for the user.

After logging in, the remotely authenticated user retains the same username that was used to log
in. However, the user inherits the user class from the assigned user template.

In a RADIUS server, users can be assigned a Juniper-Local-User-Name string, which indicates the
user template to be used in the Junos OS device. From the previous example, the string would
be RO, OP, or SU. Configuration of the RADIUS server depends on the server being used.

Configuring RADIUS To Use the Management Instance

By default, Junos OS routes authentication, authorization, and accounting packets for RADIUS through
the default routing instance. Starting in Junos OS Release 18.1R1, existing RADIUS behavior is enhanced
to support a management interface in a non-default VRF instance.

When the routing-instance mgmt_junos option is configured in both the radius-server server-ip-address
and the radius server server-ip-address statements, provided the management-instance statement is also
configured, RADIUS packets are routed through the management instance mgmt_junos.

[edit system]
radius-server server-address {
accounting-port port-number;
port number;
retry number;
routing-instance routing-instance-name; #use “mgmt_junos” for RI name
secret password;
source-address source-address;
timeout seconds;
}

[edit system accounting destination radius]

server {
server-address {
accounting-port port-number;
retry number;
routing-instance routing-instance; #use “mgmt_junos” for RI name
secret password;
source-address address;
timeout seconds;
 203

}
}

NOTE: The routing-instance mgmt_junos option must be configured in both the radius-server
and the radius server statements. If not, even if the management-instance statement is set,
RADIUS packets will still be sent using the default routing instance only.

For more details on this management instance, see management-instance.

SEE ALSO

Juniper Networks Vendor-Specific RADIUS Attributes | 211

Configuring RADIUS System Accounting | 219
Example: Configuring RADIUS Authentication | 206

Example: Configuring a RADIUS Server for System Authentication

IN THIS SECTION

Requirements | 203

Overview | 204

Configuration | 204
Verification | 206

This example shows how to configure a RADIUS server for system authentication.

Requirements

Before you begin:

• Perform the initial device configuration. See the Getting Started Guide for your device.
 204

• Configure at least one RADIUS server. For more details, see RADIUS Authentication and Accounting
Servers Configuration Overview.

Overview

In this example, you add a new RADIUS server with an IP address of 172.16.98.1 and specify the shared
secret password of the RADIUS server as Radiussecret1. The secret is stored as an encrypted value in the
configuration database. Finally, you specify the source address to be included in the RADIUS server requests
by the device. In most cases you can use the loopback address of the device, which in this example is
10.0.0.1.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, copy and paste the
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

set system radius-server address 172.16.98.1

set system radius-server 172.16.98.1 secret Radiussecret1
set system radius-server 172.16.98.1 source-address 10.0.0.1

GUI Step-by-Step Procedure

To configure a RADIUS server for system authentication:

1. In the J-Web user interface, select Configure>System Properties>User Management.

2. Click Edit. The Edit User Management dialog box appears.

3. Select the Authentication Method and Order tab.

4. In the RADIUS section, click Add. The Add Radius Server dialog box appears.

5. In the IP Address box, type the server’s 32–bit IP address.

6. In the Password and Confirm Password boxes, type the secret password for the server and verify your
entry.

7. In the Server Port box, type the appropriate port.

8. In the Source Address box, type the source IP address of the server.
 205

9. In the Retry Attempts box, specify the number of times that the server should try to verify the user’s
credentials.

10. In the Time Out box, specify the amount of time (in seconds) the device should wait for a response
from the server.

11. Click OK to check your configuration and save it as a candidate configuration.

12. If you are done configuring the device, click Commit Options>Commit.

Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions
on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure a RADIUS server for system authentication:

1. Add a new RADIUS server and set its IP address.

[edit system]
user@host# set radius-server address 172.16.98.1

2. Specify the shared secret (password) of the RADIUS server.

[edit system]
user@host# set radius-server 172.16.98.1 secret Radiussecret1

3. Specify the device’s loopback address source address.

[edit system]
user@host# set radius-server 172.16.98.1 source-address 10.0.0.1

Results
From configuration mode, confirm your configuration by entering the show system radius-server command.
If the output does not display the intended configuration, repeat the configuration instructions in this
example to correct it.

[edit]
user@host# show system radius-server
radius-server 172.16.98.1 {
secret Radiussecret1;
 206

source-address 10.0.0.1;
}

If you are done configuring the device, enter commit from configuration mode.

NOTE: To completely set up RADIUS authentication, you must create user template accounts
and specify a system authentication order. Do one of the following tasks:

• Configure a system authentication order. See “Example: Configuring Authentication Order”

on page 191.

• Configure a user. See “Example: Configuring New Users” on page 61.

• Configure local user template accounts. See “Example: Creating Template Accounts” on page 176.

Verification

Confirm that the configuration is working properly.

Verifying the RADIUS Server System Authentication Configuration

Purpose
Verify that the RADIUS server has been configured for system authentication.

Action
From operational mode, enter the show system radius-server command.

SEE ALSO

Junos OS User Authentication Methods | 172

Junos OS User Accounts Overview | 57
Configuring Local User Template Accounts for User Authentication | 173
Example: Configuring a TACACS+ Server for System Authentication | 232

Example: Configuring RADIUS Authentication

The Junos OS supports two protocols for central authentication of users on multiple routers: RADIUS and
TACACS+. We recommend RADIUS because it is a multivendor IETF standard, and its features are more
 207

widely accepted than those of TACACS+ or other proprietary systems. In addition, we recommend using
a one-time-password system for increased security, and all vendors of these systems support RADIUS.

The Junos OS uses one or more template accounts to perform user authentication. You create the template
account or accounts, and then configure the user access to use that account. If the RADIUS server is
unavailable, the fallback is for the login process to use the local account that set up on the router or switch.

The following example shows how to configure RADIUS authentication:

[edit]
system {
authentication-order [ radius password ];
root-authentication {
encrypted-password "$ABC123; # SECRET-DATA
}
name-server {
10.1.1.1;
10.1.1.2;
}
}

The following example shows how to enable RADIUS authentication and define the shared secret between
the client and the server. The secret enables the client and server to determine that they are talking to
the trusted peer.

Define a timeout value for each server, so that if there is no response within the specified number of
seconds, the router can try either the next server or the next authentication mechanism.

[edit]
system {
radius-server {
10.1.2.1 {
secret "$ABC123”; # SECRET-DATA
timeout 5;
}
10.1.2.2 {
secret "$ABC123"; # SECRET-DATA
timeout 5;
}
}
}

The following example shows how to configure RADIUS template accounts for different users or groups
of users:
 208

[edit]
system {
login {
user observation {
uid 1001;
class observation;
}
user operation {
uid 1002;
class operation;
}
user engineering {
uid 1003;
class engineering;
}
}
}

Configuring RADIUS Authentication (QFX Series or OCX Series)

IN THIS SECTION

Configuring RADIUS Server Details | 209

Configuring MS-CHAPv2 for Password-Change Support | 210

Specifying a Source Address for the Junos OS to Access External RADIUS Servers | 211

RADIUS authentication is a method of authenticating users who attempt to access the router or switch.
Tasks to configure RADIUS authentication are:
 209

NOTE: The source-address statement is not supported at the [edit system radius-options or
[edit system-radius-server name] hierarchies on the QFabric system.

Configuring RADIUS Server Details

To use RADIUS authentication on the router or switch, configure information about one or more RADIUS
servers on the network by including one radius-server statement at the [edit system] hierarchy level for
each RADIUS server:

[edit system]
radius-server server-address {
accounting-port port-number;
port number;
retry number;
secret password;
source-address source-address;
timeout seconds;
}

server-address is the address of the RADIUS server.

You can specify a port on which to contact the RADIUS server. By default, port number 1812 is used (as
specified in RFC 2865). You can also specify an accounting port to send accounting packets. The default
is 1813 (as specified in RFC 2866).

You must specify a password in the secret password statement. If the password contains spaces, enclose
it in quotation marks. The secret used by the local router or switch must match that used by the server.

Optionally, you can specify the amount of time that the local router or switch waits to receive a response
from a RADIUS server (in the timeout statement) and the number of times that the router or switch
attempts to contact a RADIUS authentication server (in the retry statement). By default, the router or
switch waits 3 seconds. You can configure this to be a value from 1 through 90 seconds. By default, the
router or switch retries connecting to the server three times. You can configure this to be a value from 1
through 10 times.

You can use the source-address statement to specify a logical address for individual or multiple RADIUS
servers.

To configure multiple RADIUS servers, include multiple radius-server statements.

 210

To configure a set of users that share a single account for authorization purposes, you create a template
user. To do this, include the user statement at the [edit system login] hierarchy level, as described in
“Example: Configuring Authentication Order” on page 191.

You can also configure RADIUS authentication at the [edit access] and [edit access profile] hierarchy level.
Junos OS uses the following search order to determine which set of servers are used for authentication:

1. [edit access profile profile-name radius-server server-address]

2. [edit access radius-server server-address]

3. [edit system radius-server server-address]

Configuring MS-CHAPv2 for Password-Change Support

You can configure the Microsoft implementation of the Challenge Handshake Authentication Protocol
version 2 (MS-CHAPv2) on the router or switch to support changing of passwords. This feature provides
users accessing a router or switch the option of changing the password when the password expires, is
reset, or is configured to be changed at the next login.

Before you configure MS-CHAPv2 for password-change support, ensure that you:

• Configure the RADIUS server authentication parameters

• Set the authentication-order to use the RADIUS server for the initial password attempt

To configure MS-CHAP-v2, include the following statements at the [edit system radius-options] hierarchy
level:

[edit system radius-options]

password-protocol mschap-v2;

The following example shows statements for configuring the MS-CHAPv2 password protocol, password
authentication order, and user accounts:

[edit]
system {
authentication-order [ radius password ];
radius-server {
192.168.69.149 secret "$ABC123"; ## SECRET-DATA
}
radius-options {
password-protocol mschap-v2;
}
login {
user bob {
 211

class operator;
}
}
}

Specifying a Source Address for the Junos OS to Access External RADIUS Servers

You can specify which source address Junos OS uses when accessing your network to contact an external
RADIUS server for authentication. You can also specify which source address Junos OS uses when contacting
a RADIUS server for sending accounting information.

To specify a source address for a RADIUS server, include the source-address statement at the [edit system
radius-server server-address] hierarchy level:

[edit system radius-server server-address]

source-address source-address;

source-address is a valid IP address configured on one of the router or switch interfaces.

SEE ALSO

Juniper Networks Vendor-Specific RADIUS Attributes | 211

Example: Configuring Authentication Order | 191
Example: Configuring RADIUS Authentication | 206
Using Regular Expressions on a RADIUS or TACACS+ Server to Allow or Deny Access to Commands | 237
Junos OS User Authentication Methods | 172

Juniper Networks Vendor-Specific RADIUS Attributes

Junos OS supports the configuration of Juniper Networks RADIUS vendor-specific attributes (VSAs). These
VSAs are encapsulated in a RADIUS vendor-specific attribute with the vendor ID set to the Juniper Networks
ID number, 2636. Table 13 on page 212 lists the Juniper Networks VSAs you can configure.
 212

Table 13: Juniper Networks Vendor-Specific RADIUS Attributes

Name Description Type Length String

Juniper-Local-User-Name Indicates the name of the 1 ≥3 One or more octets

user template used by this containing printable
user when logging in to a ASCII characters.
device. This attribute is used
only in Access-Accept
packets.

Juniper-Allow-Commands Contains an extended regular 2 ≥3 One or more octets

expression that enables the containing printable
user to run operational mode ASCII characters, in the
commands in addition to the form of an extended
commands authorized by the regular expression. See
user’s login class permission “Regular Expressions for
bits. This attribute is used Allowing and Denying
only in Access-Accept Junos OS Operational
packets. Mode Commands,
Configuration
Statements, and
Hierarchies” on
page 94.

Juniper-Deny-Commands Contains an extended regular 3 ≥3 One or more octets

expression that denies the containing printable
user permission to run ASCII characters, in the
operation mode commands form of an extended
authorized by the user’s login regular expression. See
class permission bits. This “Regular Expressions for
attribute is used only in Allowing and Denying
Access-Accept packets. Junos OS Operational
Mode Commands,
Configuration
Statements, and
Hierarchies” on
page 94.
 213

Table 13: Juniper Networks Vendor-Specific RADIUS Attributes (continued)

Name Description Type Length String

Juniper-Allow-Configuration Contains an extended regular 4 ≥3 One or more octets

expression that enables the containing printable
user to run configuration ASCII characters, in the
mode commands in addition form of an extended
to the commands authorized regular expression. See
by the user’s login class “Regular Expressions for
permission bits. This attribute Allowing and Denying
is used only in Access-Accept Junos OS Operational
packets. Mode Commands,
Configuration
Statements, and
Hierarchies” on
page 94.

Juniper-Deny-Configuration Contains an extended regular 5 ≥3 One or more octets

expression that denies the containing printable
user permission to run ASCII characters, in the
configuration commands form of an extended
authorized by the user’s login regular expression. See
class permission bits. This “Regular Expressions for
attribute is used only in Allowing and Denying
Access-Accept packets. Junos OS Operational
Mode Commands,
Configuration
Statements, and
Hierarchies” on
page 94.

Juniper-Interactive-Command Indicates the interactive 8 ≥3 One or more octets

command entered by the containing printable
user. This attribute is used ASCII characters.
only in Accounting-Request
packets.

Juniper-Configuration-Change Indicates the interactive 9 ≥3 One or more octets

command that results in a containing printable
configuration (database) ASCII characters.
change. This attribute is used
only in Accounting-Request
packets.
 214

Table 13: Juniper Networks Vendor-Specific RADIUS Attributes (continued)

Name Description Type Length String

Juniper-User-Permissions Contains information the 10 ≥3 One or more octets

server uses to specify user containing printable
permissions. This attribute is ASCII characters.
used only in Access-Accept
The string is a list of
packets.
permission flags
NOTE: When the separated by a space.
Juniper-User-Permissions The exact name of each
attribute is configured to flag must be specified in
grant the Junos OS its entirety. See “Login
maintenance or all Class Permission Flags”
permissions on a RADIUS on page 85.
server, the UNIX wheel group
membership is not
automatically added to a
user’s list of group
memberships. Some
operations such as running
the su root command from a
local shell require wheel
group membership
permissions. However, when
a user is configured locally
with the permissions
maintenance or all, the user
is automatically granted
membership to the UNIX
wheel group. Therefore, we
recommend that you create
a template user account with
the required permissions and
associate individual user
accounts with the template
user account.
 215

Table 13: Juniper Networks Vendor-Specific RADIUS Attributes (continued)

Name Description Type Length String

Juniper-Authentication-Type Indicates the authentication 11 ≥5 One or more octets

method (local database, or containing printable
RADIUS server) used to ASCII characters.
authenticate a user. If the
user is authenticated using a
local database, the attribute
value shows ’local’. If the user
is authenticated using
RADIUS server, the attribute
value shows ’remote’.

Juniper-Session-Port Indicates the source port 12 size of Integer

number of the established integer
session.

For more information about the VSAs, see RFC 2138, Remote Authentication Dial In User Service (RADIUS).

Juniper-Switching-Filter VSA Match Conditions and Actions

Devices support the configuration of RADIUS server attributes specific to Juniper Networks. These
attributes are known as vendor-specific attributes (VSAs) and are described in RFC 2138, Remote
Authentication Dial In User Service (RADIUS).

Through VSAs, you can configure port-filtering attributes on the RADIUS server. VSAs are cleartext fields
sent from the RADIUS server to the device as a result of authentication success or failure. Authentication
prevents unauthorized user access by blocking a supplicant at the port until the device is authenticated
by the RADIUS server. The VSA attributes are interpreted by the device during authentication, and the
device takes appropriate actions. Implementing port-filtering attributes with authentication on the RADIUS
server provides a central location for controlling LAN access for supplicants.

These port-filtering attributes specific to Juniper Networks are encapsulated in a RADIUS server VSA with
the vendor ID set to the Juniper Networks ID number, 2636.

As well as configuring port-filtering attributes through VSAs, you can apply a port firewall filter that has
already been configured on the device directly to the RADIUS server. Like port-filtering attributes, the
filter is applied during the authentication process, and its actions are applied at the device port. Adding a
port firewall filter to a RADIUS server eliminates the need to add the filter to multiple ports and devices.
 216

The Juniper-Switching-Filter VSA works in conjunction with 802.1X authentication to centrally control
access of supplicants to the network. You can use this VSA to configure filters on the RADIUS server,
which are sent to the switch and applied to users that have been authenticated using 802.1X authentication.

The Juniper-Switching-Filter VSA can contain one or more filter terms. Filter terms are configured using
one or more match conditions with a resulting action. Match conditions are the criteria that a packet must
meet for a configured action to be applied on it. The action is the action that the switch takes if a packet
meets the criteria in the match conditions. The action that the switch can take is either accept or deny a
packet.

The following guidelines apply when you specify match conditions and actions for VSAs:

• Both match and action statements are mandatory.

• If no match condition is specified, any packet is considered a match by default.

• If no action is specified, the default action is to deny the packet.

• Any or all options can be included in each match and action statement.

• The AND operation is performed on fields that are of a different type, which are separated by commas.
Fields of the same type cannot be repeated.

• For the forwarding-class option to be applied, the forwarding class must be configured on the switch.
If the forwarding class is not configured on the switch, this option is ignored.

Table 14 on page 216 describes the match conditions that you can specify when you configure a VSA
attribute as a firewall filter by using the match command on the RADIUS server. The string that defines a
match condition is called a match statement.

Table 14: Match Conditions

Option Description

destination-mac mac-address Destination media access control (MAC) address of the packet.

source-dot1q-tag tag Tag value in the 802.1Q header, in the range 0 through 4095.

destination-ip ip-address Address of the final destination node.

ip-protocol protocol-id IPv4 protocol value. In place of the numeric value, you can specify one
of the following text synonyms:

ah, egp (8), esp (50, gre (47), icmp (1), igmp (2), ipip (4), ipv6 (41), ospf
(89), pim (103), rsvp (46), tcp (6), or udp (17)
 217

Table 14: Match Conditions (continued)

Option Description

source-port port TCP or User Datagram Protocol (UDP) source port field. Normally, you
specify this match statement in conjunction with the ip-protocol match
statement to determine which protocol is being used on the port. In
place of the numeric field, you can specify one of the text options listed
under destination-port.

destination-port port TCP or UDP destination port field. Normally, you specify this match
statement in conjunction with the ip-protocol match statement to
determine which protocol is being used on the port. In place of the
numeric value, you can specify one of the following text synonyms (the
port numbers are also listed):

afs (1483), bgp (179), biff (512), bootpc (68), bootps (67), cvspserver
(2401), cmd (514), dhcp (67), domain (53), eklogin (2105), ekshell (2106),
exec (512), finger (79), ftp (21), ftp-data (20), http (80), https (443), ident
(113), imap (143), kerberos-sec (88), klogin (543), kpasswd (761),
krb-prop (754), krbupdate (760), kshell (544), ldap (389), login (513),
mobileip-agent (434), mobilip-mn (435), msdp (639), netbios-dgm (138),
netbios-ns (137), netbios-ssn (139), nfsd (2049), nntp (119), ntalk (518),
ntp (123), pop3 (110), pptp (1723), printer (515), radacct (1813), radius
(1812), rip (520), rkinit (2108), smtp (25), snmp (161), snmptrap (162),
snpp (444), socks (1080), ssh (22), sunrpc (111), syslog (514), telnet (23),
tacacs-ds (65), talk (517), tftp (69), timed (525), who (513), xdmcp (177),
zephyr-clt (2103), zephyr-hm (2104)

When you define one or more terms that specify the filtering criteria, you also define the action to take
if the packet matches all criteria. Table 15 on page 217 shows the actions that you can specify in a term.

Table 15: Actions for VSAs

Option Description

(allow | deny) Accept a packet or discard a packet silently without sending an Internet
Control Message Protocol (ICMP) message.

forwarding-class class-of-service (Optional) Classify the packet in one of the following forwarding classes:

• assured-forwarding
• best-effort
• expedited-forwarding
• network-control
 218

Table 15: Actions for VSAs (continued)

Option Description

loss-priority (low | medium | high) (Optional) Set the packet loss priority (PLP) to low, medium, or high.
Specify both the forwarding class and the loss priority.

SEE ALSO

Filtering 802.1X Supplicants by Using RADIUS Server Attributes | 360

Understanding Dynamic Filters Based on RADIUS Attributes | 370

Understanding RADIUS Accounting

Devices support IETF RFC 2866, RADIUS Accounting. Configuring RADIUS accounting on the device
supports collecting statistical data about users logging in to or out from a LAN and sending the data to a
RADIUS accounting server. The statistical data gathered can be used for general network monitoring,
analyzing and tracking usage patterns, or billing a user based upon the amount of time or type of services
accessed.

To configure RADIUS accounting, specify one or more RADIUS accounting servers to receive the statistical
data from the device, and select the type of accounting data to be collected.

The RADIUS accounting server you specify can be the same server used for RADIUS authentication, or it
can be a separate RADIUS server. You can specify a list of RADIUS accounting servers. If the primary
server (the first one configured) is unavailable, each RADIUS server in the list is tried in the order in which
they are configured in the Junos OS.

The RADIUS accounting process between the device and a RADIUS server works like this:

1. A RADIUS accounting server listens for User Datagram Protocol (UDP) packets on a specific port. For
example, on FreeRADIUS, the default port is 1813.

2. The device forwards an accounting-request packet containing an event record to the accounting server.
The event record associated with this supplicant contains an Acct-Status-Type attribute whose value
indicates the beginning of user service for this supplicant. When the supplicant’s session ends, the
accounting request contains an Acct-Status-Type attribute value indicating the end of user service. The
RADIUS accounting server records this as a stop-accounting record containing session information and
the length of the session.
 219

3. The RADIUS accounting server logs these events in a file as start-accounting or stop-accounting records.
On FreeRADIUS, the filename is the server’s address; for example, 192.0.2.0.

4. The accounting server sends an accounting-response packet back to the device confirming it has received
the accounting request.

5. If the device does not receive a response from the server, it continues to send accounting requests
until an accounting response is returned from the accounting server.

The statistics collected through this process can be displayed from the RADIUS server; to see those
statistics, the user accesses the log file configured to receive them.

SEE ALSO

Configuring RADIUS System Accounting | 219

Configuring RADIUS System Accounting

With RADIUS accounting enabled, Juniper Networks routers or switches, acting as RADIUS clients, can
notify the RADIUS server about user activities such as software logins, configuration changes, and interactive
commands. The framework for RADIUS accounting is described in RFC 2866.

Tasks for configuring RADIUS system accounting are:

1. Configuring Auditing of User Events on a RADIUS Server | 219

2. Specifying RADIUS Server Accounting and Auditing Events | 220
3. Configuring RADIUS Server Accounting | 220

Configuring Auditing of User Events on a RADIUS Server

To audit user events, include the following statements at the [edit system accounting] hierarchy level:

[edit system accounting]

events [ events ];
destination {
radius {
server {
server-address {
 220

accounting-port port-number;
retry number;
routing-instance routing-instance;
secret password;
source-address address;
timeout seconds;
}
}
}
}

Specifying RADIUS Server Accounting and Auditing Events

To specify the events you want to audit when using a RADIUS server for authentication, include the events
statement at the [edit system accounting] hierarchy level:

[edit system accounting]

events [ events ];

events is one or more of the following:

• login—Audit logins

• change-log—Audit configuration changes

• interactive-commands—Audit interactive commands (any command-line input)

Configuring RADIUS Server Accounting

To configure RADIUS server accounting, include the server statement at the [edit system accounting
destination radius] hierarchy level:

server {
server-address {
accounting-port port-number;
retry number;
routing-instance routing-instance;
secret password;
source-address address;
timeout seconds;
}
}
 221

server-address specifies the address of the RADIUS server. To configure multiple RADIUS servers, include
multiple server statements.

NOTE: If no RADIUS servers are configured at the [edit system accounting destination radius]
statement hierarchy level, the Junos OS uses the RADIUS servers configured at the [edit system
radius-server] hierarchy level.

accounting-port port-number specifies the RADIUS server accounting port number.

The default port number is 1813.

NOTE: If you enable RADIUS accounting at the [edit access profile profile-name accounting-order]
hierarchy level, accounting is triggered on the default port of 1813 even if you do not specify a
value for the accounting-port statement.

routing-instance routing-instance is the name of the non-default management instance. Use mgmt_junos
as the routing-instance name. See Management Interface in a Nondefault Instance.

You must specify a secret (password) that the local router or switch passes to the RADIUS client by including
the secret statement. If the password contains spaces, enclose the entire password in quotation marks (“
“).

In the source-address statement, specify a source address for the RADIUS server. Each RADIUS request
sent to a RADIUS server uses the specified source address. The source address is a valid IPv4 address (in
case if radius-server address is IPv4) or IPv6 address (in case if radius-server address is IPv6) configured
on one of the router or switch interfaces.

Optionally, you can specify the number of times that the router or switch attempts to contact a RADIUS
authentication server by including the retry statement. By default, the router or switch retries three times.
You can configure the router or switch to retry from 1 through 10 times.

Optionally, you can specify the length of time that the local router or switch waits to receive a response
from a RADIUS server by including the timeout statement. By default, the router or switch waits 3 seconds.
You can configure the timeout to be from 1 through 90 seconds.

Starting with Junos OS Release 14.1 and Junos OS Release 17.3R1, you can configure the
enhanced-accounting statement to view the attribute values of a logged in user. If you use the
enhanced-accounting statement at the [edit system radius-options] hierarchy level, the RADIUS attributes
such as access method, remote port, and access privileges can be audited. You can limit the number of
attribute values to be displayed for auditing by using the enhanced-avs-max <number> statement at the
[edit system accounting] hierarchy level.
 222

[edit system radius-options]

enhanced-accounting;

[edit system accounting]

enhanced-avs-max <number>;

When a Juniper Networks router or switch is configured with RADIUS accounting, it sends Accounting-Start
and Accounting-Stop messages to the RADIUS server. These messages contain information about user
activities such as software logins, configuration changes, and interactive commands. This information is
typically used for monitoring a network, collecting usage statistics, and ensuring that users are billed
properly.

The following example shows three servers (10.5.5.5, 10.6.6.6, and 10.7.7.7) configured for RADIUS
accounting:

system {
accounting {
events [ login change-log interactive-commands ];
destination {
radius {
server {
10.5.5.5 {
accounting-port 3333;
secret $ABC123;
source-address 10.1.1.1;
retry 3;
timeout 3;
}
10.6.6.6 secret $ABC123;
10.7.7.7 secret $ABC123;
}
}
}
}
}
 223

Release History Table

Release Description

17.4R1 Starting in Junos OS Release 18.1R1, existing RADIUS behavior is enhanced to support a
management interface in a non-default VRF instance.

14.1 Starting with Junos OS Release 14.1 and Junos OS Release 17.3R1, you can configure the
enhanced-accounting statement to view the attribute values of a logged in user.

RELATED DOCUMENTATION

Junos OS User Authentication Overview | 172

Authentication Order for RADIUS, TACACS+, and Local Password | 182
TACACS+ Authentication | 227

RADIUS over TLS (RADSEC)

IN THIS SECTION

Configure the RADSEC Destination | 224

Configure TLS Connection Parameters | 225

Example: Simple RADSEC Configuration | 226

Monitoring Certificates | 226

Monitoring RADSEC Destinations | 227

RADIUS over TLS is designed to provide secure communication of RADIUS requests using the Transport
Secure Layer (TLS) protocol. RADIUS over TLS, also known as RADSEC, redirects regular RADIUS traffic
to remote RADIUS servers connected over TLS. RADSec allows RADIUS authentication, authorization and
accounting data to be passed safely across untrusted networks.

RADSEC uses TLS in combination with the Transmission Control Protocol (TCP). This transport profile
provides stronger security than the User Datagram Protocol (UDP) which was originally used for RADIUS
transmission. RADIUS over UDP encrypts the shared secret password using the MD5 algorithm, which is
 224

vulnerable to attacks. RADSEC mitigates the risk of attacks on MD5 by exchanging RADIUS packet payloads
over an encrypted TLS tunnel.

NOTE: Due to limitations of the TCP protocol, RADSEC can have no more than 255 RADIUS
messages in flight.

Configure the RADSEC Destination

RADSEC servers are represented by RADSEC destination objects. To configure RADSEC, you must define
the RADSEC server as a destination, and direct RADIUS traffic to that destination.

You define the RADSEC server as a destination using the radsec statement at the [edit access] hierarchy
level. RADSEC destinations are identified by a unique numeric ID. You can configure multiple RADSEC
destinations with different parameters pointing to the same RADSEC server.

To redirect traffic from a standard RADIUS server to a RADSEC server, associate the RADIUS server with
a RADSEC destination. For example, the RADIUS server 1.1.1.1 is associated with RADSEC destination
10:

access {
radius-server 1.1.1.1 {
secret zzz;
radsec-destination 10;
}
}

You can also associate the RADIUS server with a RADSEC destination inside an access profile. For example,
RADIUS server 2.2.2.2 in profile acc_profile is associated with RADSEC destination 10:

access {
profile acc_profile {
secret zzz;
radsec-destination 10;
}
}

NOTE: You can redirect more than one RADIUS server to the same RADSEC destination.
 225

To configure RADSEC:

1. Configure the RADSEC destination with a unique ID and an IP address.

[edit access]
user@host# radsec destination id-number address server-address

2. Configure the port of the RADSEC server. If no port is configured, the default RADSEC port 2083 is
used.

[edit access radsec destination id-number]

user@host# port port-number

3. Redirect traffic from a RADIUS server to the RADSEC destination:

[edit access]
user@host# radius-server server-address radsec-destination id-number

Configure TLS Connection Parameters

The TLS connection provides encryption, authentication, and data integrity for the exchange of RADIUS
messages. TLS relies on certificates and private-public key exchange pairs to secure the transmission of
data between the RADSEC client and server. The RADSEC destination uses local certificates that are
dynamically acquired from the Junos PKI infrastructure.

To enable RADSEC, you must specify the name of the local certificate. For information on configuring the
local certificate and certificate authority (CA), see Configuring Digital Certificates.

1. Specify the name of the local certificate to be used for TLS communications.

[edit access]
user@host# radsec destination id-number tls-certificate certificate-name

2. Configure the certified name of the RADSEC server.

[edit access]
user@host# radsec destination id-number tls-peer-name cert-server-name
 226

3. (Optional) Configure the TLS connection timeout (default is 5 seconds).

[edit access]
user@host# radsec destination id-number tls-timeout seconds

Example: Simple RADSEC Configuration

The following example is a simple RADSEC configuration with one RADIUS server and one RADSEC
destination. RADIUS traffic is redirected from RADIUS server 1.1.1.1 to RADSEC destination 10.

access {
radius-server 1.1.1.1 {
secret zzz;
radsec-destination 10;
}
radsec {
destination 10 {
address 10.1.1.1;
max-tx-buffers 1000;
id-reuse-timeout 30;
port 1777;
source-address 1.1.1.2;
tls-certificate my_cert;
tls-force-ciphers { medium | low };
tls-min-version { v1.1 | v1.2 };
tls-peer-name x0.radsec.com
tls-timeout 10;
}
}
}

Monitoring Certificates

To view information about the state and statistics of local certificate acquisition: show network-access
radsec local-certificate.
 227

Monitoring RADSEC Destinations

To view statistics for the RADSEC destinations: show network-access radsec statistics.

To view the state of the RADSEC destinations: show network-access radsec state.

RELATED DOCUMENTATION

Example: Configuring RADIUS Authentication | 206

Example: Configuring System Authentication for RADIUS, TACACS+, and Password Authentication | 194
Example: Configuring Authentication Order | 191
Example: Configuring RADIUS Authentication | 206

TACACS+ Authentication

IN THIS SECTION

Configuring TACACS+ Authentication | 228

Example: Configuring a TACACS+ Server for System Authentication | 232

Configuring Periodic Refresh of the TACACS+ Authorization Profile | 235

Using Regular Expressions on a RADIUS or TACACS+ Server to Allow or Deny Access to Commands | 237

Juniper Networks Vendor-Specific TACACS+ Attributes | 240

Configuring TACACS+ System Accounting | 242

The Junos OS supports TACACS+ for central authentication of users on multiple routers or switches or
security devices. To use TACACS+ authentication on the device, you must configure information about
one or more TACACS+ servers on the network. You can also configure TACACS+ accounting on the device
to collect statistical data about the users logging in to or out from a LAN and sending the data to a TACACS+
accounting server. For more information, read this topic.
 228

Configuring TACACS+ Authentication

IN THIS SECTION

Configuring TACACS+ Server Details | 228

Configuring TACACS+ to Use the Management Instance | 230

Specifying a Source Address for the Junos OS to Access External TACACS+ Servers | 230

Configuring the Same Authentication Service for Multiple TACACS+ Servers | 231

Configuring Juniper Networks Vendor-Specific TACACS+ Attributes | 231

TACACS+ authentication is a method of authenticating users who attempt to access the router or switch.

NOTE: Starting with Release 13.3, Junos OS supports IPv6 along with the existing IPv4 support
for user authentication using TACACS+ servers.

Tasks to configure TACACS+ configuration are:

Configuring TACACS+ Server Details

To use TACACS+ authentication on the router or switch, configure information about one or more TACACS+
servers on the network by including the tacplus-server statement at the [edit system] hierarchy level:

[edit system]
tacplus-server server-address {
port port-number;
routing-instance routing-instance;
secret password;
single-connection;
timeout seconds;
}

server-address is the address of the TACACS+ server.

port-number is the TACACS+ server port number.

routing-instance routing-instance is the name of the routing instance used to send and receive TACACS+
packets. By default, Junos OS routes authentication, authorization, and accounting packets for TACACS+
 229

through the default routing instance. Starting in Junos OS Release 17.4R1, existing TACACS+ behavior is
enhanced to support routing TACACS+ packets through a management interface in a non-default VRF
instance named mgmt_junos. For more information on this VRF management instance, see “Configuring
TACACS+ to Use the Management Instance” on page 230. Starting in Junos OS Release 18.2R1, you can
route TACACS+ traffic through any routing instance you configure in authentication.

You must specify a secret (password) that the local router or switch passes to the TACACS+ client by
including the secret statement. If the password included spaces, enclose the password in quotation marks.
The secret used by the local router or switch must match that used by the server.

Optionally, you can specify the length of time that the local router or switch waits to receive a response
from a TACACS+ server by including the timeout statement. By default, the router or switch waits 3 seconds.
You can configure this to be a value in the range from 1 through 90 seconds.

Optionally, you can have the software maintain one open Transmission Control Protocol (TCP) connection
to the server for multiple requests, rather than opening a connection for each connection attempt by
including the single-connection statement.

NOTE: Early versions of the TACACS+ server do not support the single-connection option. If
you specify this option and the server does not support it, the Junos OS will be unable to
communicate with that TACACS+ server.

To configure multiple TACACS+ servers, include multiple tacplus-server statements.

On a TX Matrix router, TACACS+ accounting should be configured only under the groups re0 and re1.

NOTE: Accounting should not be configured at the [edit system] hierarchy level; on a TX Matrix
router, control is done under the switch-card chassis only.

To configure a set of users that share a single account for authorization purposes, you create a template
user. To do this, include the user statement at the [edit system login] hierarchy level, as described in
“Example: Configuring Authentication Order” on page 191.

SEE ALSO

routing-instance (Accounting and Authentication) | 1250

 230

Configuring TACACS+ to Use the Management Instance

By default, Junos OS routes authentication, authorization, and accounting packets for TACACS+ through
the default routing instance. Starting in Junos OS Release 17.4R1, existing TACACS+ behavior is enhanced
to support a management interface in a non-default VRF instance.

[edit system]
tacplus-server server-address {
routing-instance routing-instance;
}

When the routing-instance mgmt_junos option is configured in both the tacplus-server server-address
and the tacplus server server-ip statements (see tacplus), provided the management-instance statement
is also configured, TACACS+ packets are routed through the management instance mgmt_junos.

NOTE: The routing-instance mgmt_junos option must be configured in both the tacplus-server
and the tacplus server statements. If not, even when the management-instance statement is
configured, TACACS+ packets use the default routing instance only.

Before Junos OS Release 17.4R1, there is no option for configuring a routing instance for
TACACS+. Therefore, even if management-instance is configured, there is no TACACS+ routing
instance functionality, until Junos OS Release 17.4R1.

For more details on the management instance mgmt_junos, see management-instance.

Specifying a Source Address for the Junos OS to Access External TACACS+ Servers

You can specify which source address the Junos OS uses when accessing your network to contact an
external TACACS+ server for authentication. You can also specify which source address the Junos OS
uses when contacting a TACACS+ server for sending accounting information.

To specify a source address for a TACACS+ server for authentication, include the source-address statement
at the [edit system tacplus-server server-address] hierarchy level:

[edit system tacplus-server server-address]

source-address source-address;

source-address is a valid IP address configured on one of the router or switch interfaces.

To specify a source address for a TACACS+ server for system accounting, include the source-address
statement at the [edit system accounting destination tacplus server server-address] hierarchy level:
 231

[edit system accounting destination tacplus server server-address]

source-address source-address;

source-address is a valid IP address configured on one of the router or switch interfaces.

Configuring the Same Authentication Service for Multiple TACACS+ Servers

To configure the same authentication service for multiple TACACS+ servers, include statements at the
[edit system tacplus-server] and [edit system tacplus-options] hierarchy levels. For information about
how to configure a TACACS+ server at the [edit system tacplus-server] hierarchy level, see “Configuring
TACACS+ Authentication” on page 228.

To assign the same authentication service to multiple TACACS+ servers, include the service-name statement
at the [edit system tacplus-options] hierarchy level:

[edit system tacplus-options]

service-name service-name;

service-name is the name of the authentication service. By default, the service name is set to junos-exec.

The following example shows how to configure the same authentication service for multiple TACACS+
servers:

[edit system]
tacplus-server {
10.2.2.2 secret "$ABC123"; ## SECRET-DATA
10.3.3.3 secret "$ABC123";## SECRET-DATA
}
tacplus-options {
service-name bob;
}

Configuring Juniper Networks Vendor-Specific TACACS+ Attributes

The Juniper Networks Vendor-Specific TACACS+ Attributes enable you to configure access privileges for
users on a TACACS+ server. They are specified in the TACACS+ server configuration file on a per-user
basis. The Junos OS retrieves these attributes through an authorization request of the TACACS+ server
after authenticating a user. You do not need to configure these attributes to run the Junos OS with
TACACS+.

To specify these attributes, include a service statement of the following form in the TACACS+ server
configuration file:
 232

service = junos-exec {
local-user-name = <username-local-to-router>
allow-commands = "<allow-commands-regex>"
allow-configuration-regexps = "<allow-configuration-regex>"
deny-commands = "<deny-commands-regex>"
deny-configuration-regexps = "<deny-configuration-regex>"
}

This service statement can appear in a user or group statement.

Example: Configuring a TACACS+ Server for System Authentication

IN THIS SECTION

Requirements | 232

Overview | 232

Configuration | 233

Verification | 235

This example shows how to configure a TACACS+ server for system authentication.

Requirements

Before you begin:

• Perform the initial device configuration. See the Getting Started Guide for your device.

• Configure at least one TACACS+ server.

Overview

In this example, you set the IP address to 172.16.98.24 and the shared secret password of the TACACS+
server to Tacacssecret1. The secret password is stored as an encrypted value in the configuration database.
You then set the loopback source address as 10.0.0.1
 233

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, copy and paste the
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

set system tacplus-server address 172.16.98.24

set system tacplus-server 172.16.98.24 secret Tacacssecret1
set system tacplus-server 172.16.98.24 source-address 10.0.0.1

GUI Step-by-Step Procedure

To configure a TACACS+ server for system authentication:

1. In the J-Web user interface, select Configure>System Properties>User Management.

2. Click Edit. The Edit User Management dialog box appears.

3. Select the Authentication Method and Order tab.

4. In the TACACS section, click Add. The Add TACACS Server dialog box appears.

5. In the IP Address box, type the server’s 32–bit IP address.

6. In the Password and Confirm Password boxes, type the secret password for the server and verify your
entry.

7. In the Server Port box, type the appropriate port.

8. In the Source Address box, type the locally configured interface address, which is used as the source
address for TACACS+ packets.

NOTE: The Source Address box can accept either a hostname or an IP address.

9. In the Retry Attempts box, specify the number of times that the server should try to verify the user’s
credentials.

10. In the Time Out box, specify the amount of time (in seconds) the device should wait for a response
from the server.
 234

11. Click OK to check your configuration and save it as a candidate configuration.

12. If you are done configuring the device, click Commit Options>Commit.

Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions
on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure a TACACS+ server for system authentication:

1. Add a new TACACS+ server and set its IP address.

[edit system]
user@host# set tacplus-server address 172.16.98.24

2. Specify the shared secret (password) of the TACACS+ server.

[edit system]
user@host# set tacplus-server 172.16.98.24 secret Tacacssecret1

3. Specify the device’s loopback address as the source address.

[edit system]
user@host# set tacplus-server 172.16.98.24 source-address 10.0.0.1

Results
From configuration mode, confirm your configuration by entering the show system tacplus-server command.
If the output does not display the intended configuration, repeat the configuration instructions in this
example to correct it.

[edit]
user@host# show system tacplus-server
tacplus-server 172.16.98.24 {
secret Tacacssecret1;
source-address 10.0.0.1;
}

If you are done configuring the device, enter commit from configuration mode.
 235

NOTE: To completely set up TACACS+ authentication, you must create user template accounts
and specify a system authentication order. Do one of the following tasks:

• Configure a system authentication order. See “Example: Configuring Authentication Order”

on page 191.

• Configure a user. See “Example: Configuring New Users” on page 61.

• Configure local user template accounts. See “Example: Creating Template Accounts” on page 176.

Verification

Confirm that the configuration is working properly.

Verifying the TACACS+ Server System Authentication Configuration

Purpose
Verify that the TACACS+ server has been configured for system authentication.

Action
From configuration mode, enter the show system tacplus-server command.

SEE ALSO

Junos OS User Authentication Methods | 172

Junos OS User Accounts Overview | 57
Configuring Local User Template Accounts for User Authentication | 173

Configuring Periodic Refresh of the TACACS+ Authorization Profile

When you configure a Junos OS device to use a TACACS+ server for authentication, the device prompts
users for login information, which is verified by the TACACS+ server. After the user is successfully
authenticated, the Junos OS device sends an authorization request to the TACACS+ server to obtain the
authorization profile for the user. Authorization profiles specify the access permissions for authenticated
users or devices.

The TACACS+ server sends the authorization profile as part of an authorization response message. The
remote user configured on the TACACS+ server is mapped to a local user configured on the Junos OS
 236

device. The Junos OS device combines the remote authorization profile with the locally-configured
authorization profile for the user, which is configured at the [edit system login class] hierarchy level.

The exchange of authorization request and response messages occurs only once, after successful
authentication, by default. You can configure the Junos OS device to periodically fetch the remote
authorization profile from the TACACS+ server and refresh the authorization profile stored locally. This
ensures that any change in the authorization parameters are reflected on the local device without the user
having to restart the authentication process.

To enable periodic refresh of the authorization profile, you must set the time interval at which the Junos
OS device checks the authorization profile configured remotely on the TACACS+ server. If there is a change
in the remote authorization profile, the device fetches the authorization profile from the TACACS+ server
and the authorization profile configured under the login class hierarchy. The device refreshes the
authorization profile stored locally by combining the remote and locally-configured authorization profiles.

The time interval can be configured directly on the TACACS+ server or locally on the Junos OS device
using the CLI. The time interval is configured in minutes, in the range of 15 to 1440 minutes.

• To configure periodic refresh of the authorization profile on the local device using the CLI, include the
authorization-time-interval statement at the [edit system tacplus-options] hierarchy level:

[edit system tacplus-options]

authorization-time-interval [minutes];

• To configure the time interval for periodic refresh on the TACACS+ server, add the time interval as a
parameter in the authorization profile using the following syntax:

refresh-time-interval=minutes
 237

Use the following guidelines to determine which time interval configuration takes precedence:

• If there is no refresh time interval configured on the TACACS+ server for periodic refresh, the Junos OS
device does not receive the time interval value in the authorization response. In this case, the value
configured locally on the Junos OS device will take effect.

• If the refresh time interval is configured on the TACACS+ server and there is no refresh time interval
configured locally on the Junos OS device, the value configured on the TACACS+ server will take effect.

• If refresh time interval is configured on the TACACS+ server and also on the Junos OS device locally,
the value configured on the TACACS+ server will take precedence.

• If there is no refresh time interval configured on the TACACS+ server and there is no refresh time interval
configured on the Junos OS device, there will be no periodic refresh.

• If the refresh time interval configured on the TACACS+ server is out of range or invalid, the refresh time
interval value configured locally will take effect.

• If the refresh time interval configured on the TACACS+ server is out of range or invalid and there is no
refresh time interval configured locally, there will be no periodic refresh.

After the periodic refresh time interval is set, if the user changes the refresh interval before the authorization
request is sent from the Junos OS device, the updated refresh interval takes effect after the next immediate
periodic refresh.

SEE ALSO

Defining Junos OS Login Classes | 41

tacplus-options | 1291

Using Regular Expressions on a RADIUS or TACACS+ Server to Allow or

Deny Access to Commands

Use regular expressions to specify which operational or configuration mode commands are allowed or
denied when you use a RADIUS or TACACS+ server for user authentication. You can specify the regular
expressions using the appropriate Juniper Networks vendor-specific RADIUS or TACACS+ attributes in
your authentication server configuration.

The following attributes are supported for configuring authorizations on RADIUS and TACACS+ servers:

• user-permissions

• allow-configuration

• deny-configuration
 238

• allow-commands

• deny-commands

• allow-configuration-regexp

• deny-configuration-regexp

• (TACACS+ only) allow-commands-regexp

• (TACACS+ only) deny-commands-regexp

You can specify allow-configuration, deny-configuration, allow-commands, or deny-commands in a single

extended regular expression, enclosing multiple commands in parentheses and separating them using the
pipe symbol. For example, you can specify multiple allow-commands parameters using: allow-commands=
(cmd1 | cmd2 | cmdn). You can specify user-permissions as a list of comma-separated values, and not as
a regular expression.

To configure authorizations using the allow/deny-configuration-regexps or allow/deny-commands-regexps

attributes, you configure a set of strings in which each string is a regular expression, enclosed in double
quotes and separated with a space operator. For example, you can specify multiple parameters for
allow-commands-regexp using the following syntax: allow-commands-regexps = (“regexp1” “regexp2”...).

On a RADIUS or TACACS+ server, you can also use a simplified version for regular expressions where you
specify each individual expression on a separate line. The simplified version is valid for allow-commands,
deny-commands, allow-configuration, deny-configuration, and permissions vendor-specific attributes.

For a RADIUS server, specify the individual regular expressions using the following syntax:

Juniper-Allow-Commands+="cmd1"
Juniper-Allow-Commands+="cmd2"
Juniper-Allow-Commands+="cmdn"
Juniper-Deny-Commands+="cmd1"
Juniper-Deny-Commands+="cmd2"
Juniper-Deny-Commands+="cmdn"
Juniper-Allow-Configuration+="regex1"
Juniper-Allow-Configuration+="regex2"
Juniper-Allow-Configuration+="regexn"
Juniper-Deny-Configuration+="regex1"
Juniper-Deny-Configuration+="regex2"
Juniper-Deny-Configuration+="regexn"
Juniper-User-Permissions+="permission-flag1"
Juniper-User-Permissions+="permission-flag2"
Juniper-User-Permissions+="permission-flagn"

For TACACS+ server, specify the individual regular expressions using the following syntax:
 239

allow-commands1="cmd1"
allow-commands2="cmd2"
allow-commandsn="cmdn"
deny-commands1="cmd1"
deny-commands2="cmd2"
deny-commandsn="cmdn"
allow-configuration1="regex1"
allow-configuration2="regex2"
allow-configurationn="regexn"
deny-configuration1="regex1"
deny-configuration2="regex2"
deny-configurationn="regexn"
user-permissions1="permission-flag1"
user-permissions2="permission-flag2"
user-permissionsn="permission-flagn "

NOTE:
• Numeric values 1 to n in the syntax (for TACACS+ server) must be unique but need not be
sequential. For example, the following syntax is valid:

allow-commands1="cmd1"
allow-commands3="cmd3"
allow-commands2="cmd2"
deny-commands3="cmd3"
deny-commands2="cmd2"
deny-commands1="cmd1"

• The limit on the number of lines of individual regular expressions is imposed by the TACACS+
or RADIUS server.

• When you issue the show cli authorization command, the command output displays the regular
expression in a single line, even if you specify each individual expression on a separate line.

For more information about Juniper Networks vendor-specific RADIUS and TACACS+ attributes, see
“Juniper Networks Vendor-Specific RADIUS Attributes” on page 211 and “Juniper Networks Vendor-Specific
TACACS+ Attributes” on page 240.
 240

NOTE: When RADIUS or TACACS+ authentication is configured for a router, regular expressions
configured on the RADIUS or TACACS+ server merge with any regular expressions configured
on the local router at the [edit system login class] hierarchy level using the allow-commands,
deny-commands, allow-configuration, deny-configuration, or permissions statements. If the
final expression has a syntax error, the overall result is an invalid regular expression.

SEE ALSO

Junos OS Authentication Order for RADIUS, TACACS+, and Password Authentication | 182

Juniper Networks Vendor-Specific TACACS+ Attributes

Junos OS supports the configuration of Juniper Networks TACACS+ vendor-specific attributes (VSAs).
These VSAs are encapsulated in a TACACS+ vendor-specific attribute with the vendor ID set to the Juniper
Networks ID number, 2636. Table 16 on page 240 lists the Juniper Networks VSAs you can configure.

Table 16: Juniper Networks Vendor-Specific TACACS+ Attributes

Name Description Length String

local-user-name Indicates the name of the user template used by ≥3 One or more octets
this user when logging in to a device. containing printable ASCII
characters.

allow-commands Contains an extended regular expression that ≥3 One or more octets

enables the user to run operational mode containing printable ASCII
commands in addition to those commands characters, in the form of an
authorized by the user’s login class permission extended regular
bits. expression. See “Regular
Expressions for Allowing
and Denying Junos OS
Operational Mode
Commands, Configuration
Statements, and
Hierarchies” on page 94.
 241

Table 16: Juniper Networks Vendor-Specific TACACS+ Attributes (continued)

Name Description Length String

allow-configuration Contains an extended regular expression that ≥3 One or more octets

enables the user to run configuration mode containing printable ASCII
commands in addition to those commands characters, in the form of an
authorized by the user’s login class permission extended regular
bits. expression. See “Regular
Expressions for Allowing
and Denying Junos OS
Operational Mode
Commands, Configuration
Statements, and
Hierarchies” on page 94.

deny-commands Contains an extended regular expression that ≥3 One or more octets

denies the user permission to run operational containing printable ASCII
mode commands authorized by the user’s login characters, in the form of an
class permission bits. extended regular
expression. See “Regular
Expressions for Allowing
and Denying Junos OS
Operational Mode
Commands, Configuration
Statements, and
Hierarchies” on page 94.

deny-configuration Contains an extended regular expression that ≥3 One or more octets

denies the user permission to run configuration containing printable ASCII
mode commands authorized by the user’s login characters, in the form of an
class permission bits. extended regular
expression. See “Regular
Expressions for Allowing
and Denying Junos OS
Operational Mode
Commands, Configuration
Statements, and
Hierarchies” on page 94.
 242

Table 16: Juniper Networks Vendor-Specific TACACS+ Attributes (continued)

Name Description Length String

user-permissions Contains information the server uses to specify ≥3 One or more octets
user permissions. containing printable ASCII
characters. See
NOTE: When the user-permissions attribute is
“Understanding Junos OS
configured to grant the Junos OS maintenance
Access Privilege Levels” on
or all permissions on an IPv4 or IPv6 TACACS+
page 84.
server, the UNIX wheel group membership is not
automatically added to a user’s list of group
memberships. Some operations such as running
the su root command from a local shell require
wheel group membership permissions. However,
when a user is configured locally with the
permissions maintenance or all, the user is
automatically granted membership to the UNIX
wheel group. Therefore, we recommend that you
create a template user account with the required
permissions and associate individual user
accounts with the template user account.

authentication-type Indicates the authentication method (local ≥5 One or more octets

database, or TACACS+ server) used to containing printable ASCII
authenticate a user. If the user is authenticated characters.
using a local database, the attribute value shows
’local’. If the user is authenticated using TACACS+
server, the attribute value shows ’remote’.

session-port Indicates the source port number of the size of Integer

established session. integer

Configuring TACACS+ System Accounting

You can use TACACS+ to track and log software logins, configuration changes, and interactive commands.
To audit these events, include the following statements at the [edit system accounting] hierarchy level:

[edit system accounting]

events [ events ];
destination {
tacplus {
 243

server {
server-address {
port port-number;
routing-instance routing-instance;
secret password;
single-connection;
timeout seconds;
}
}
}
}

Tasks for configuring TACACS+ system accounting are:

1. Specifying TACACS+ Auditing and Accounting Events | 243

2. Configuring TACACS+ Server Accounting | 243
3. Configuring TACACS+ To Use the Management Instance | 245
4. Configuring TACACS+ Accounting on a TX Matrix Router | 246

Specifying TACACS+ Auditing and Accounting Events

To specify the events you want to audit when using a TACACS+ server for authentication, include the
events statement at the [edit system accounting] hierarchy level:

[edit system accounting]

events [ events ];

events is one or more of the following:

• login—Audit logins

• change-log—Audit configuration changes

• interactive-commands—Audit interactive commands (any command-line input)

Configuring TACACS+ Server Accounting

To configure TACACS+ server accounting, include the server statement at the [edit system accounting
destination tacplus] hierarchy level:

[edit system accounting destination tacplus]

server {
 244

server-address {
port port-number;
routing-instance routing-instance;
secret password;
single-connection;
timeout seconds;
}
}

server-address specifies the address of the TACACS+ server. To configure multiple TACACS+ servers,
include multiple server statements.

NOTE: If no TACACS+ servers are configured at the [edit system accounting destination tacplus]
statement hierarchy level, the Junos OS uses the TACACS+ servers configured at the [edit system
tacplus-server] hierarchy level.

We recommend that you add the following configuration at the [edit system accounting
destination tacplus] statement hierarchy level to identify a destination and help avoid generating
an error condition:

accounting {
events [ login change-log interactive-commands ];
destination {
tacplus;
}
}

port-number specifies the TACACS+ server port number.

routing-instance routing-instance is the name of the routing instance used to send and receive TACACS+
packets. By default, Junos OS routes authentication, authorization, and accounting packets for TACACS+
through the default routing instance. Starting in Junos OS Release 17.4R1, existing TACACS+ behavior is
enhanced to support routing TACACS+ packets through a management interface in a non-default VRF
instance named mgmt_junos. For more information on this VRF management instance, see “Configuring
TACACS+ To Use the Management Instance” on page 245. Starting in Junos OS Release 18.2R1, you can
route TACACS+ traffic through any routing instance you configure in accounting.

You must specify a secret (password) that the local router or switch passes to the TACACS+ client by
including the secret statement. If the password contains spaces, enclose the entire password in quotation
marks (“ ”). The password used by the local router or switch must match that used by the server.
 245

Optionally, you can specify the length of time that the local router or switch waits to receive a response
from a TACACS+ server by including the timeout statement. By default, the router or switch waits 3 seconds.
You can configure this to be a value in the range from 1 through 90 seconds.

Optionally, you can maintain one open TCP connection to the server for multiple requests, rather than
opening a connection for each connection attempt, by including the single-connection statement.

To ensure that start and stop requests for accounting of login events are correctly logged in the Accounting
file instead of the Administration log file on a TACACS+ server, include either the no-cmd-attribute-value
statement or the exclude-cmd-attribute at the [edit system tacplus-options] hierarchy level.

If you use the no-cmd-attribute-value statement, the value of the cmd attribute is set to a null string in
the start and stop requests. If you use the exclude-cmd-attribute statement, the cmd attribute is totally
excluded from the start and stop requests. Both statements support the correct logging of accounting
requests in the Accounting file, instead of the Administration file.

[edit system tacplus-options]

(no-cmd-attribute-value | exclude-cmd-attribute);

Configuring TACACS+ To Use the Management Instance

By default, Junos OS routes authentication, authorization, and accounting packets for TACACS+ through
the default routing instance. Starting in Junos OS Release 17.4R1, existing TACACS+ behavior is enhanced
to support a management interface in a non-default VRF instance.

[edit system accounting destination tacplus]

server {
server-address {
routing-instance routing-instance;
}
}

When the routing-instance mgmt_junos option is configured in both the tacplus-server server-address
and the tacplus server server-ip statements, provided the management-instance statement is also configured,
TACACS+ packets are routed through the management instance mgmt_junos.

NOTE: The routing-instance mgmt_junos option must be configured in both the tacplus-server
and the tacplus server statements. If not, even if the management-instance statement is set,
TACACS+ packets will still be sent using the default routing instance only.

For more details on this management instance, see management-instance.

 246

Configuring TACACS+ Accounting on a TX Matrix Router

On a TX Matrix router, TACACS+ accounting should be configured only under the groups re0 and re1.

NOTE: Accounting should not be configured at the [edit system] hierarchy; on a TX Matrix
router, control is done under the switch-card chassis only.

Release History Table

Release Description

18.2R1 Starting in Junos OS Release 18.2R1, you can route TACACS+ traffic through any routing
instance you configure in authentication.

18.2R1 Starting in Junos OS Release 18.2R1, you can route TACACS+ traffic through any routing
instance you configure in accounting.

17.4R1 Starting in Junos OS Release 17.4R1, existing TACACS+ behavior is enhanced to support routing
TACACS+ packets through a management interface in a non-default VRF instance named
mgmt_junos.

17.4R1 Starting in Junos OS Release 17.4R1, existing TACACS+ behavior is enhanced to support a
management interface in a non-default VRF instance.

17.4R1 Starting in Junos OS Release 17.4R1, existing TACACS+ behavior is enhanced to support routing
TACACS+ packets through a management interface in a non-default VRF instance named
mgmt_junos.

17.4R1 Starting in Junos OS Release 17.4R1, existing TACACS+ behavior is enhanced to support a
management interface in a non-default VRF instance.

RELATED DOCUMENTATION

Junos OS User Authentication Overview | 172

Authentication Order for RADIUS, TACACS+, and Local Password | 182
RADIUS Authentication | 197
 247

Authentication for Routing Protocols

IN THIS SECTION

Junos OS Authentication Methods for Routing Protocols | 247

Example: Configuring the Authentication Key for BGP and IS-IS Routing Protocols | 248

Configuring the Authentication Key Update Mechanism for BGP and LDP Routing Protocols | 250

You can configure an authentication method and password for routing protocol messages for IGPs, IS-IS,
OSPF, and RIP, and RSVP. To prevent exchange of unauthenticated or forged packets, routers must ensure
that they form routing protocol relationships (peering or neighboring relationships) to trusted peers. One
way of doing this is by authenticating routing protocol messages. Neighboring routers use the password
to verify the authenticity of packets sent by the protocol from the router or from a router interface. Read
this topic for more information.

Junos OS Authentication Methods for Routing Protocols

Some interior gateway protocols (IGPs)—Intermediate System-to-Intermediate System (IS-IS), Open Shortest
Path First (OSPF), and Routing Information Protocol (RIP)—and Resource Reservation Protocol (RSVP)
allow you to configure an authentication method and password. Neighboring routers use the password to
verify the authenticity of packets sent by the protocol from the router or from a router interface. The
following authentication methods are supported:

• Simple authentication (IS-IS, OSPF, and RIP)—Uses a simple text password. The receiving router uses an
authentication key (password) to verify the packet. Because the password is included in the transmitted
packet, this method of authentication is relatively insecure. We recommend that you not use this
authentication method.

• MD5 and HMAC-MD5 (IS-IS, OSPF, RIP, and RSVP)—Message Digest 5 (MD5) creates an encoded
checksum that is included in the transmitted packet. HMAC-MD5, which combines HMAC authentication
with MD5, adds the use of an iterated cryptographic hash function. With both types of authentication,
the receiving router uses an authentication key (password) to verify the packet. HMAC-MD5
authentication is defined in RFC 2104, HMAC: Keyed-Hashing for Message Authentication.

In general, authentication passwords are text strings consisting of a maximum of 16 or 255 letters and
digits. Characters can include any ASCII strings. If you include spaces in a password, enclose all characters
in quotation marks (“ ”).
 248

Junos-FIPS has special password requirements. FIPS passwords must be between 10 and 20 characters
in length. Passwords must use at least three of the five defined character sets (uppercase letters, lowercase
letters, digits, punctuation marks, and other special characters). If Junos-FIPS is installed on the router,
you cannot configure passwords unless they meet this standard.

Example: Configuring the Authentication Key for BGP and IS-IS Routing
Protocols

The main task of a router is to use its routing and forwarding tables to forward user traffic to its intended
destination. Attackers can send forged routing protocol packets to a router with the intent of changing or
corrupting the contents of its routing table or other databases, which in turn can degrade the functionality
of the router and the network. To prevent such attacks, routers must ensure that they form routing protocol
relationships (peering or neighboring relationships) to trusted peers. One way of doing this is by
authenticating routing protocol messages. We strongly recommend using authentication when configuring
routing protocols. The Junos OS supports HMAC-MD5 authentication for BGP, Intermediate
System-to-Intermediate System (IS-IS), Open Shortest Path First (OSPF), Routing Information Protocol
(RIP), and Resource Reservation Protocol (RSVP). HMAC-MD5 uses a secret key that is combined with
the data being transmitted to compute a hash. The computed hash is transmitted along with the data. The
receiver uses the matching key to recompute and validate the message hash. If an attacker has forged or
modified the message, the hash will not match and the data will be discarded.

In the following examples, we configure BGP as the exterior gateway protocol (EGP) and IS-IS as the
interior gateway protocol (IGP). If you use OSPF, configure it similarly to the IS-IS configuration shown.

Configuring BGP

The following example shows the configuration of a single authentication key for the BGP peer group
internal peers. You can also configure BGP authentication at the neighbor or routing instance levels, or
for all BGP sessions. As with any security configuration, there is a trade-off between the degree of
granularity (and to some extent the degree of security) and the amount of management necessary to
maintain the system. This example also configures a number of tracing options for routing protocol events
and errors, which can be good indicators of attacks against routing protocols. These events include protocol
authentication failures, which might point to an attacker that is sending spoofed or otherwise malformed
routing packets to the router in an attempt to elicit a particular behavior.

[edit]
protocols {
bgp {
group ibgp {
type internal;
 249

traceoptions {
file bgp-trace size 1m files 10;
flag state;
flag general;
}
local-address 10.10.5.1;
log-updown;
neighbor 10.2.1.1;
authentication-key "$9$aH1j8gqQ1gjyjgjhgjgiiiii";
}
group ebgp {
type external;
traceoptions {
file ebgp-trace size 10m files 10;
flag state;
flag general;
}
local-address 10.10.5.1;
log-updown;
peer-as 2;
neighbor 10.2.1.2;
authentication-key "$9$aH1j8gqQ1gjyjgjhgjgiiiii";
}
}
}

Configuring IS-IS

Although all IGPs supported by the Junos OS support authentication, some are inherently more secure
than others. Most service providers use OSPF or IS-IS to allow fast internal convergence and scalability
and to use traffic engineering capabilities with Multiprotocol Label Switching (MPLS). Because IS-IS does
not operate at the network layer, it is more difficult to spoof than OSPF, which is encapsulated in IP and
is therefore subject to remote spoofing and DoS attacks.

The following example also shows how to configure a number of tracing options for routing protocol
events and errors, which can be good indicators of attacks against routing protocols. These events include
protocol authentication failures, which might point to an attacker that is sending spoofed or otherwise
malformed routing packets to the router in an attempt to elicit a particular behavior.

[edit]
protocols {
isis {
authentication-key "$9$aH1j8gqQ1gjyjgjhgjgiiiii"; # SECRET-DATA
 250

authentication-type md5;
traceoptions {
file isis-trace size 10m files 10;
flag normal;
flag error;
}
interface at-0/0/0.131 {
lsp-interval 50;
level 2 disable;
level 1 {
metric 3;
hello-interval 5;
hold-time 60;
}
}
interface lo0.0 {
passive;
}
}
}

Configuring the Authentication Key Update Mechanism for BGP and LDP
Routing Protocols

You can configure an authentication key update mechanism for the Border Gateway Protocol (BGP) and
Label Distribution Protocol (LDP) routing protocols. This mechanism allows you to update authentication
keys without interrupting associated routing and signaling protocols such as Open Shortest Path First
(OSPF) and Resource Reservation Setup Protocol (RSVP).

To configure this feature, include the authentication-key-chains statement at the [edit security] level, and
include the authentication-algorithm algorithm and authentication-key-chain statements for the BGP or
LDP routing protocols at the [edit protocols] level .

The following topics provide more details about configuring authentication key updates for BGP and LDP
Routing Protocols:

• Configuring Authentication Key Updates on page 251

 251

• Configuring BGP and LDP for Authentication Key Updates on page 251

Configuring Authentication Key Updates

To configure the authentication key update mechanism, include the key-chain statement at the [edit
security authentication-key-chains] hierarchy level, and specify the key option to create a keychain
consisting of several authentication keys.

[edit security authentication-key-chains]

key-chain key-chain-name {
key key {
secret secret-data;
start-time yyyy-mm-dd.hh:mm:ss;
}
}

key-chain—Assigns a name to the keychain mechanism. This name is also configured at the [edit protocols
bgp] or the [edit protocols ldp] hierarchy levels to associate unique authentication key-chain attributes
as specified using the following options:

• key—Each key within a keychain is identified by a unique integer value. The range is from 0 through 63.

• secret—Each key must specify a secret in encrypted text or plain text format. Even if you enter the secret
data in plain-text format, the secret always appears in encrypted format.

• start-time—Start times for authentication key updates are specified in UTC (Coordinated Universal Time),
and must be unique within the keychain.

Configuring BGP and LDP for Authentication Key Updates

To configure the authentication key update mechanism for the BGP and LDP routing protocols, include
the authentication-key-chain statement at the [edit protocols (bgp | ldp)] hierarchy level to associate each
routing protocol with the [edit security authentication-key-chains] authentication keys. You must also
configure the authentication-algorithm algorithm statement at the [edit protocols (bgp | ldp)] hierarchy
level.

[edit protocols (bgp | ldp)]

group group-name {
neighbor address {
authentication-algorithm algorithm;
authentication-key-chain key-chain-name;
}
}
 252

NOTE: When configuring the authentication key update mechanism for BGP, you cannot commit
the 0.0.0.0/allow statement with authentication keys or key chains. The CLI issues a warning
and fails to commit such configurations.

For information about the BGP protocol, see the Junos OS Routing Protocols Library.

RELATED DOCUMENTATION

authentication-algorithm
authentication-key-chain (Protocols BGP and BMP)
authentication-key-chain (Protocol LDP)
5 CHAPTER

Remote Access Management

Remote Access Overview | 254

USB Modems for Remote Management of Security Devices | 284

Secure Web Access for Remote Management | 304

Example: Controlling Management Access on SRX Series Devices | 314

Configuration Guidelines for Securing Console Port Access | 319

Configuring the Console Port Type (CLI Procedure) | 322

 254

Remote Access Overview

IN THIS SECTION

System Services Overview | 254

Configuring Telnet Service for Remote Access to a Router or Switch | 255

Configuring FTP Service for Remote Access to the Router or Switch | 256

Configuring Finger Service for Remote Access to the Router | 257

Configuring SSH Service for Remote Access to the Router or Switch | 257

The telnet Command | 262

The ssh Command | 263

Configuring SSH Host Keys for Secure Copying of Data | 264

Configuring the SSH Service to Support Legacy Cryptography | 268

Configuring Outbound SSH Service | 270

Configuring NETCONF-Over-SSH Connections on a Specified TCP Port | 274

Configuring Password Retry Limits for Telnet and SSH Access | 275

Example: Configuring a Filter to Block Telnet and SSH Access | 276

You can access a router, switch, or security device remotely using DHCP, Finger, FTP, rlogin, SSH, and
Telnet services and so on. This topic shows you how to configure remote access using Telnet, SSH, FTP,
and Finger services. Read this topic for more information.

System Services Overview

For security reasons, remote access to the router is disabled by default. You must configure the router
explicitly so that users on remote systems can access it. The router can be accessed from a remote system
by means of the DHCP, finger, FTP, rlogin, SSH, and Telnet services. In addition, Junos XML protocol client
applications can use Secure Sockets Layer (SSL) or the Junos XML protocol-specific clear-text service,
among other services.
 255

NOTE: To protect system resources, you can limit the number of simultaneous connections that
a service accepts and the number of processes owned by a single user. If either limit is exceeded,
connection attempts fail.

SEE ALSO

Configuring clear-text or SSL Service for Junos XML Protocol Client Applications
IP Address Assignments
Configuring DTCP-over-SSH Service for the Flow-Tap Application
Configuring TACACS+ System Accounting | 242

Configuring Telnet Service for Remote Access to a Router or Switch

To configure the router or switch to accept Telnet as an access service, include the telnet statement at
the [edit system services] hierarchy level:

[edit system services]

telnet {
connection-limit limit;
rate-limit limit;
}

By default, the router or switch supports a limited number of simultaneous Telnet sessions and connection
attempts per minute.

Optionally, you can include either or both of the following statements to change the defaults:

• connection-limit limit—Maximum number of simultaneous connections per protocol (IPV4 and IPv6).
The range is from 1 through 250. The default is 75. When you configure a connection limit, the limit is
applicable to the number of telnet sessions per protocol (IPv4 and IPv6). For example, a connection limit
of 10 allows 10 IPv6 telnet sessions and 10 IPv4 telnet sessions.

• rate-limit limit—Maximum number of connection attempts accepted per minute (from 1 through 250).
The default is 150. When you configure a rate limit, the limit is applicable to the number of connection
attempts per protocol (IPv4 and IPv6). For example, a rate limit of 10 allows 10 IPv6 telnet session
connection attempts per minute and 10 IPv4 telnet session connection attempts per minute.
 256

You cannot include the telnet statement on devices that run the Junos-FIPS software. We recommend
that you do not use Telnet in a Common Criteria environment.

SEE ALSO

telnet | 1608

Configuring FTP Service for Remote Access to the Router or Switch

To configure the router or switch to accept FTP as an access service, include the ftp statement at the [edit
system services] hierarchy level:

[edit system services]

ftp {
connection-limit limit;
rate-limit limit;
}

By default, the router or switch supports a limited number of simultaneous FTP sessions and connection
attempts per minute. You can include either or both of the following statements to change the defaults:

• connection-limit limit—Maximum number of simultaneous connections per protocol (IPV4 and IPv6).
The range is a value from 1 through 250. The default is 75. When you configure a connection limit, the
limit is applicable to the number of sessions per protocol (IPv4 and IPv6). For example, a connection
limit of 10 allows 10 IPv6 FTP sessions and 10 IPv4 FTP sessions.

• rate-limit limit—Maximum number of connection attempts accepted per minute (a value from 1 through
250). The default is 150.When you configure a rate limit, the limit is applicable to the number of
connection attempts per protocol (IPv4 and IPv6). For example, a rate limit of 10 allows 10 IPv6 FTP
session connection attempts and 10 IPv4 FTP session connection attempts.

You can use passive FTP to access devices that accept only passive FTP services. All commands and
statements that use FTP also accept passive FTP. Include the ftp statement at the [edit system services]
hierarchy level to use either active FTP or passive FTP.

To start a passive FTP session, use pasvftp (instead of ftp ) in the standard FTP format (ftp://destination).
For example:

request system software add pasvftp://name.com/jinstall.tgz

 257

You cannot include the ftp statement on routers or switches that run the Junos-FIPS software. We
recommend that you do not use the finger service in a Common Criteria environment.

Configuring Finger Service for Remote Access to the Router

To configure the router to accept finger as an access service, include the finger statement at the [edit
system services] hierarchy level:

[edit system services]

finger {
connection-limit limit;
rate-limit limit;
}

By default, the router supports a limited number of simultaneous finger sessions and connection attempts
per minute. Optionally, you can include either or both of the following statements to change the defaults:

• connection-limit limit—Maximum number of simultaneous connections per protocol (IPv4 and IPv6).
The range is a value from 1 through 250. The default is 75. When you configure a connection limit, the
limit is applicable to the number of sessions per protocol (IPv4 and IPv6). For example, a connection
limit of 10 allows 10 IPv6 clear-text service sessions and 10 IPv4 clear-text service sessions

• rate-limit limit—Maximum number of connection attempts accepted per minute (a value from 1 through
250). The default is 150. When you configure a rate limit, the limit is applicable to the number of
connection attempts per protocol (IPv4 and IPv6). For example, a rate limit of 10 allows 10 IPv6 session
connection attempts per minute and 10 IPv4 session connection attempts per minute.

You cannot include the finger statement on routers that run the Junos-FIPS software. We recommend
that you do not use the finger service in a Common Criteria environment.

Configuring SSH Service for Remote Access to the Router or Switch

IN THIS SECTION

Configuring the Root Login Through SSH | 259

Configuring Incoming SFTP Connections | 260

Configuring the SSH Protocol Version | 260

 258

Configuring the Client Alive Mechanism | 261

Configuring the SSH Fingerprint Hash Algorithm | 261

To configure the router or switch to accept SSH as an access service, include the ssh statement at the
[edit system services] hierarchy level:

[edit system services]

ssh {
authentication-order [method 1 method2...];
authorized-keys-command authorized-keys-command;
authorized-keys-command-user authorized-keys-command-user;
ciphers [ cipher-1 cipher-2 cipher-3 ...];
client-alive-count-max number;
client-alive-interval seconds;
connection-limit limit;
fingerprint-hash (md5 | sha2-256);
hostkey-algorithm (algorithm | no-algorithm);
key-exchange [algorithm1 algorithm2...];
log-key-changes log-key-changes;
macs [algorithm1 algorithm2...];
max-pre-authentication-packets number;
max-sessions-per-connection number;
no-challenge-response;
no-password-authentication;
no-passwords;
no-public-keys;
no-tcp-forwarding;
port port-number;
protocol-version [v2];
rate-limit number;
rekey {
data-limit bytes;
time-limit minutes;
}
root-login (allow | deny | deny-password);
sftp-server;
}
tcp-forwarding;
 259

By default, the router or switch supports a limited number of simultaneous SSH sessions and connection
attempts per minute. Use the following statements to change the defaults:

• connection-limit limit—Maximum number of simultaneous connections per protocol (IPv4 and IPv6).
The range is a value from 1 through 250. The default is 75. When you configure a connection limit, the
limit is applicable to the number of SSH sessions per protocol (IPv4 and IPv6). For example, a connection
limit of 10 allows 10 IPv6 SSH sessions and 10 IPv4 SSH sessions.

• max-sessions-per-connection number—Include this statement to specify the maximum number of SSH

sessions allowed per single SSH connection. This allows you to limit the number of cloned sessions
tunneled within a single SSH connection. The default value is 10.

• rate-limit limit—Maximum number of connection attempts accepted per minute (a value from 1 through
250). The default is 150. When you configure a rate limit, the limit is applicable to the number of
connection attempts per protocol (IPv4 and IPv6). For example, a rate limit of 10 allows 10 IPv6 SSH
session connection attempts per minute and 10 IPv4 SSH session connection attempts per minute.

• data-limit—Data limit before renegotiating session keys (bytes)

• time-limit—Time limit before renegotiating session keys (minutes)

Starting in Junos OS Release 19.4R1, you can disable either the SSH login password or the
challenge-response authentication using the no-password-authentication and no-challenge-response
options at the [edit system services ssh] hierarchy level.

By default, a user can create an SSH tunnel over a CLI session to a router running Junos OS via SSH. This
type of tunnel could be used to forward TCP traffic, bypassing any firewall filters or access control lists
allowing access to resources beyond the router. Use the no-tcp-forwarding option to prevent a user from
creating an SSH tunnel to a router via SSH.

For information about other configuration settings, see the following topics:

Configuring the Root Login Through SSH

By default, users are allowed to log in to the router or switch as root through SSH when the authentication
method does not require a password. To control user access through SSH, include the root-login statement
at the [edit systems services ssh] hierarchy level:

[edit system services ssh]

root-login (allow | deny | deny-password);

allow—Allows users to log in to the router or switch as root through SSH.

deny—Disables users from logging in to the router or switch as root through SSH.

deny-password—Allows users to log in to the router or switch as root through SSH when the authentication
method (for example, RSA) does not require a password.
 260

The default is deny-password.

Configuring Incoming SFTP Connections

SSH File Transfer Protocol (SFTP) is a network protocol that provides file access, file transfer, and file
management over any reliable data stream. Starting in Junos OS Release 19.1R1, we have globally disabled
the incoming SFTP connections by default. If desired, you can globally enable incoming SFTP connections
by configuring the statement sftp-server at the [edit system services ssh] hierarchy level. Prior to Junos
OS Release 19.1R1, incoming SFTP connections were globally enabled by default.

NOTE: Only the incoming SFTP connections are disabled by default. For example, given devices
A and B (where device A is running 19.1R1), you cannot connect through SFTP from B to A by
default. However, you can connect through SFTP from device B to device A, if you configure
sftp-server on device A.

The incoming SFTP connections are disabled by default. To enable incoming SFTP connections:

1. Configure the sftp-server statement at the [edit system services ssh] hierarchy level:

[edit system services ssh]

user@host# set sftp-server

2. Commit the configuration.

[edit system services ssh]

user@host# commit

The sftp-server statement is now active. Therefore, the incoming SFTP connections are enabled.

Configuring the SSH Protocol Version

By default, only version 2 of the SSH protocol is enabled.

To configure the router or switch to use version 2 of the SSH protocol, include the protocol-version
statement and specify v2 at the [edit system services ssh] hierarchy level:

[edit system services ssh]

protocol-version [ v2 ];

Systems in FIPS mode always use SSH protocol version v2.

 261

Configuring the Client Alive Mechanism

The client alive mechanism is valuable when the client or server depends on knowing when a connection
has become inactive. It differs from the standard keepalive mechanism because the client alive messages
are sent through the encrypted channel. The client alive mechanism is not enabled at default. To enable
it, configure the client-alive-count-max and client-alive-interval statements. This option applies to SSH
protocol version 2 only.

In the following example, unresponsive SSH clients will be disconnected after approximately 100 seconds
(20 x 5).

[edit system services ssh]

client-alive-count-max 5;
client-alive-interval 20;

SEE ALSO

ssh | 1271

Configuring the SSH Fingerprint Hash Algorithm

To configure the hash algorithm used by the SSH server when it displays key fingerprints, include the
fingerprint-hash statement and specify md5 or sha2-256 at the [edit system services ssh] hierarchy level:

[edit system services ssh]

fingerprint-hash (md5 | sha2-256);

The md5 hash algorithm is unavailable on systems in FIPS mode.

SEE ALSO

ssh | 1271
 262

The telnet Command

You can use the CLI telnet command to open a Telnet session to a remote device:

user@host> telnet host <8bit> <bypass-routing> <inet> <interface interface-name>

<no-resolve> <port port> <routing-instance routing-instance-name> <source address>

NOTE: On SRX100, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, and SRX1500
devices, the maximum number of concurrent Telnet sessions is indicated in the following table.
Platform support depends on the Junos OS release in your installation.

SRX300
SRX210 SRX320
SRX100 SRX220 SRX240 SRX340 SRX345 SRX1500

3 3 5 3 5 5

To exit the Telnet session and return to the Telnet command prompt, press Ctrl-].

To exit the Telnet session and return to the CLI command prompt, enter quit.

Table 17 on page 262 describes the telnet command options.

Table 17: CLI telnet Command Options

Option Description

8bit Use an 8-bit data path.

bypass-routing Bypass the routing tables and open a Telnet session only to hosts on directly
attached interfaces. If the host is not on a directly attached interface, an error
message is returned.

host Open a Telnet session to the specified hostname or IP address.

inet Force the Telnet session to an IPv4 destination.

interface source-interface Open a Telnet session to a host on the specified interface. If you do not include
this option, all interfaces are used.

no-resolve Suppress the display of symbolic names.

 263

Table 17: CLI telnet Command Options (continued)

Option Description

port port Specify the port number or service name on the host.

routing-instance Use the specified routing instance for the Telnet session.
routing-instance-name

source address Use the specified source address for the Telnet session.

The ssh Command

You can use the CLI ssh command to use the secure shell (SSH) program to open a connection to a remote
device:

user@host> ssh host <bypass-routing> <inet> <interface interface-name>

<routing-instance routing-instance-name> <source address> <v1> <v2>

NOTE: On SRX100, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, and SRX1500
devices, the maximum number of concurrent SSH sessions is indicated in the following table.
Platform support depends on the Junos OS release in your installation.

SRX300
SRX210 SRX320
SRX100 SRX220 SRX240 SRX340 SRX345 SRX1500

3 3 5 3 5 5

Table 18 on page 263 describes the ssh command options.

Table 18: CLI ssh Command Options

Option Description

bypass-routing Bypass the routing tables and open an SSH connection only to hosts on directly
attached interfaces. If the host is not on a directly attached interface, an error
message is returned.
 264

Table 18: CLI ssh Command Options (continued)

Option Description

host Open an SSH connection to the specified hostname or IP address.

inet Force the SSH connection to an IPv4 destination.

interface source-interface Open an SSH connection to a host on the specified interface. If you do not include
this option, all interfaces are used.

routing-instance Use the specified routing instance for the SSH connection.
routing-instance-name

source address Use the specified source address for the SSH connection.

v1 Force SSH to use version 1 for the connection.

v2 Force SSH to use version 2 for the connection.

Configuring SSH Host Keys for Secure Copying of Data

Secure Shell (SSH) uses encryption algorithms to generate a host, server, and session key system that
ensures secure data transfer. You can configure SSH host keys to support secure copy (SCP) as an alternative
to FTP for the background transfer of data such as configuration archives and event logs. To configure
SSH support for SCP, you must complete the following tasks:

• Specify SSH known hosts by including hostnames and host key information in the Routing Engine
configuration hierarchy.

• Set an SCP URL to specify the host from which to receive data. Setting this attribute automatically
retrieves SSH host key information from the SCP server.
 265

• Verify that the host key is authentic.

• Accept the secure connection. Accepting this connection automatically stores host key information in
the local host key database. Storing host key information in the configuration hierarchy automates the
secure handshake and allows background data transfer using SCP.

Tasks to configure SSH host keys for secure copying of data are:

1. Configuring SSH Known Hosts | 265

2. Configuring Support for SCP File Transfer | 266
3. Updating SSH Host Key Information | 266

Configuring SSH Known Hosts

To configure SSH known hosts, include the host statement, and specify hostname and host key options
for trusted servers at the [edit security ssh-known-hosts] hierarchy level:

[edit security ssh-known-hosts]

host corporate-archive-server, ip-address {
dsa-key key;
}
host archive-server-url {
rsa-key key;
}
host server-with-ssh-version-1, ip-address {
rsa1-key key;
}

Host keys are one of the following:

• dsa-key key—Base64 encoded Digital Signature Algorithm (DSA) key for SSH version 2.

• ecdsa-sha2-nistp256-key key—Base64 encoded ECDSA-SHA2-NIST256 key.

• ecdsa-sha2-nistp384-key key—Base64 encoded ECDSA-SHA2-NIST384 key.

• ecdsa-sha2-nistp521-key key—Base64 encoded ECDSA-SHA2-NIST521 key.

• ed25519-key key—Base64 encoded ED25519 key.

• rsa-key key—Base64 encoded public key algorithm that supports encryption and digital signatures for
SSH version 1 and SSH version 2.

• rsa1-key key—Base64 encoded RSA public key algorithm, which supports encryption and digital signatures
for SSH version 1.
 266

Starting in Junos OS Release 18.3R1, the ssh-dss and ssh-dsa hostkey algorithms are deprecated— rather
than immediately removed—to provide backward compatibility and a chance to bring your configuration
into compliance with the new configuration.

Configuring Support for SCP File Transfer

To configure a known host to support background SCP file transfers, include the archive-sites statement
at the [edit system archival configuration] hierarchy level.

[edit system archival configuration]

archive-sites {
scp://username<:password>@host<:port>/url-path;
}

NOTE: When specifying a URL in a Junos OS statement using an IPv6 host address, you must
enclose the entire URL in quotation marks (" ") and enclose the IPv6 host address in brackets ([
]). For example, “scp://username<:password>@[host]<:port>/url-path”;

Setting the archive-sites statement to point to an SCP URL triggers automatic host key retrieval. At this
point, Junos OS connects to the SCP host to fetch the SSH public key, displays the host key message digest
or fingerprint as output to the console, and terminates the connection to the server.

user@host# set system archival configuration archive-sites “<scp-url-path>”

The authenticity of host <my-archive-server (<server-ip-address>)> can’t be established. RSA key fingerprint is
<ascii-text key>. Are you sure you want to continue connecting (yes/no)?

To verify that the host key is authentic, compare this fingerprint with a fingerprint that you obtain from
the same host using a trusted source. If the fingerprints are identical, accept the host key by entering yes
at the prompt. The host key information is then stored in the Routing Engine configuration and supports
background data transfers using SCP.

Updating SSH Host Key Information

Typically, SSH host key information is automatically retrieved when you set a URL attribute for SCP using
the archival configuration archive-sites statement at the [edit system] hierarchy level. However, if you
need to manually update the host key database, use one of the following methods.

1. Retrieving Host Key Information Manually | 267

2. Importing Host Key Information from a File | 267
 267

Retrieving Host Key Information Manually

To manually retrieve SSH public host key information, use the fetch-from-server option with the set
security ssh-known-hosts command. You must include a hostname attribute with the set security
ssh-known-hosts fetch-from-server command to specify the host from which to retrieve the SSH public
key.

user@host# set security ssh-known-hosts fetch-from-server <hostname>

Importing Host Key Information from a File

To manually import SSH host key information from the known-hosts file located at /var/tmp/known-hosts
on the server, include the load-key-file option with the set security ssh-known-hosts command. You must
include the path to the known-hosts file with the set security ssh-known-hosts load-key-file command
to specify the location from which to import host key information.

user@host# set security ssh-known-hosts load-key-file /var/tmp/known-hosts

SEE ALSO

Importing SSL Certificates for Junos XML Protocol Support

 268

Configuring the SSH Service to Support Legacy Cryptography

Starting in Junos OS Release 16.1, the SSH server in Junos OS is based on OpenSSH 7 and defaults to a
more secure set of ciphers and key-exchange algorithms. OpenSSH 7 omits some legacy cryptography.

NOTE: Lack of support for legacy cryptography in devices causes Junos Space device discovery
to fail. To work around this issue, configure the device to support the 3des-cbc or blowfish-cbc
cipher, or both, and the dh-group1-sha1 key-exchange method. This issue does not affect devices
running Junos OS with upgraded FreeBSD.

NOTE: See the OpenSSH 7 documentation at https://www.openssh.com/ for more information

about these extensions.

Junos OS Release 16.1 supports the following set of ciphers by default:

• [email protected]

• aes128-ctr

• aes192-ctr

• aes256-ctr

• [email protected]

• [email protected]

In Junos OS Release 16.1, the following ciphers are not supported by default, but you can configure your
device to support them. They are listed from the most secure to the least secure:

• aes256-cbc

• aes192-cbc

• aes128-cbc

• 3des-cbc

• blowfish-cbc

• cast128-cbc

• arcfour256

• arcfour128

• arcfour
 269

Junos OS Release 16.1 supports the following set of key-exchange methods by default:

• curve25519-sha256

• ecdh-sha2-nistp256

• ecdh-sha2-nistp384

• ecdh-sha2-nistp521

• group-exchange-sha2

• dh-group14-sha1

In Junos OS Release 16.1, the following key-exchange methods are not supported by default, but you can
configure your device to support them:

• group-exchange-sha1

• dh-group1-sha1

To configure the SSH service to support legacy cryptography:

NOTE: By configuring an ordered set of ciphers, key-exchange methods, or message

authentication codes (MACs), the newly defined set is applied to both server and client commands.
Changes to the defaults affect the file copy command when you use Secure Copy Protocol (SCP).

1. Add support for ciphers by using the set system services ssh ciphers [ cipher 1 cipher 2 ... ] command.
We recommend that you add the ciphers to the end of the configuration list so that they are among
the last options used. In the following example, the 3des-cbc and blowfish-cbc ciphers are added to
the default set:

[edit system services ssh]

user@device# set ciphers [ [email protected] aes128-ctr aes192-ctr aes256-ctr
[email protected] [email protected] 3des-cbc blowfish-cbc ]

2. Add support for key-exchange methods by using the set system services ssh key-exchange [ method
1 method 2 ... ] command. We recommend that you add the key-exchange methods to the end of the
configuration list so that they are among the last options used. In the following example, the
dh-group1-sha1 key-exchange method is added to the default set:

[edit system services ssh]

user@device# set key-exchange [ curve25519-sha256 ecdh-sha2-nistp256 ecdh-sha2-nistp384
ecdh-sha2-nistp521 group-exchange-sha2 dh-group14-sha1 dh-group1-sha1 ]
 270

3. Commit the configuration:

[edit]
user@device# commit

SEE ALSO

key-exchange | 1163

Configuring Outbound SSH Service

You can configure a device running the Junos OS to initiate a TCP/IP connection with a client management
application that would be blocked if the client attempted to initiate the connection (for example, if the
device is behind a firewall). The outbound-ssh command instructs the device to create a TCP/IP connection
with the client management application and to forward the identity of the device. Once the connection is
established, the management application acts as the client and initiates the SSH sequence, and the device
acts as the server and authenticates the client.

NOTE: There is no initiation command with outbound SSH. Once outbound SSH is configured
and committed, the device begins to initiate an outbound SSH connection based on the committed
configuration. The device repeatedly attempts to create this connection until successful. If the
connection between the device and the client management application is dropped, the device
again attempts to create a new outbound SSH connection until successful. This connection is
maintained until the outbound SSH stanza is removed from the configuration.

To configure the device for outbound SSH connections, include the outbound-ssh statement at the [edit
system services] hierarchy level:

[edit system services outbound-ssh]

The following topics describe the tasks for configuring the outbound SSH service:

Configuring the Device Identifier for Outbound SSH Connections | 271

Sending the Public SSH Host Key to the Outbound SSH Client | 271

Configuring Keepalive Messages for Outbound SSH Connections | 272

Configuring a New Outbound SSH Connection | 273

 271

Configuring the Outbound SSH Client to Accept NETCONF as an Available Service | 273

Configuring Outbound SSH Clients | 273

Configuring Routing Instances for Outbound SSH Clients | 274

Configuring the Device Identifier for Outbound SSH Connections

Each time the device establishes an outbound SSH connection, it first sends an initiation sequence to the
management client. This sequence identifies the device to the management client. Within this transmission
is the value of device-id.

To configure the device identifier of the device, include the device-id statement at the [edit system services
outbound-ssh client client-id] hierarchy level:

[edit system services outbound-ssh client client-id]

device-id device-id;

The initiation sequence when secret is not configured:

MSG-ID: DEVICE-CONN-INFO\r\n
MSG-VER: V1\r\n
DEVICE-ID: <device-id>\r\n

Sending the Public SSH Host Key to the Outbound SSH Client

Each time the router or switch establishes an outbound SSH connection, it first sends an initiation sequence
to the management client. This sequence identifies the router or switch to the management client. Within
this transmission is the value of device-id.

To configure the device identifier of the router or switch, include the device-id statement at the [edit
system services outbound-ssh client client-id] hierarchy level:

[edit system services outbound-ssh client client-id]

device-id device-id;

The initiation sequence when secret is not configured:

MSG-ID: DEVICE-CONN-INFO\r\n
MSG-VER: V1\r\n
DEVICE-ID: <device-id>\r\n
 272

During the initialization of an SSH connection, the client authenticates the identity of the device using the
public SSH host key of the device. Therefore, before the client can initiate the SSH sequence, it needs the
public SSH key of the device. When you configure the secret statement, the device passes its public SSH
key as part of the outbound SSH connection initiation sequence.

When the secret statement is set and the device establishes an outbound SSH connection, the device
communicates its device ID, its public SSH key, and an SHA1 hash derived in part from the secret statement.
The value of the secret statement is shared between the device and the management client. The client
uses the shared secret to authenticate the public SSH host key it is receiving to determine whether the
public key is from the device identified by the device-id statement.

Using the secret statement to transport the public SSH host key is optional. You can manually transport
and install the public key onto the client system.

NOTE: Including the secret statement means that the device sends its public SSH host key every
time it establishes a connection to the client. It is then up to the client to decide what to do with
the SSH host key if it already has one for that device. We recommend that you replace the client’s
copy with the new key. Host keys can change for various reasons and by replacing the key each
time a connection is established, you ensure that the client has the latest key.

To send the router’s or switch’s public SSH host key when the device connects to the client, include the
secret statement at the [edit system services outbound-ssh client client-id] hierarchy level:

[edit system services outbound-ssh client client-id]

secret password;

The following message is sent by the device when the secret attribute is configured:

MSG-ID: DEVICE-CONN-INFO\r\n
MSG-VER: V1\r\n
DEVICE-ID: <device-id>\r\n
HOST-KEY: <public-hot-key>\r\n
HMAC:<HMAC(pub-SSH-host-key, <secret>>)>\r\n

Configuring Keepalive Messages for Outbound SSH Connections

Once the client application has the router’s or switch’s public SSH host key, it can then initiate the SSH
sequence as if it had created the TCP/IP connection and can authenticate the device using its copy of the
router’s or switch’s public host SSH key as part of that sequence. The device authenticates the client user
through the mechanisms supported in the Junos OS (RSA/DSA public string or password authentication).
 273

To enable the device to send SSH protocol keepalive messages to the client application, configure the
keep-alive statement at the [edit system services outbound-ssh client client-id] hierarchy level:

[edit system services outbound-ssh client client-id]

keep-alive {
retry number;
timeout seconds;
}

Configuring a New Outbound SSH Connection

When disconnected, the device begins to initiate a new outbound SSH connection. To specify how the
device reconnects to the server after a connection is dropped, include the reconnect-strategy statement
at the [edit system services outbound-ssh client client-id] hierarchy level:

[edit system services outbound-ssh client-id]

reconnect-strategy (sticky | in-order);

You can also specify the number of retry attempts and set the amount of time before the reconnection
attempts stop. See “Configuring Keepalive Messages for Outbound SSH Connections” on page 272.

Configuring the Outbound SSH Client to Accept NETCONF as an Available Service

To configure the application to accept NETCONF as an available service, include the services netconf
statement at the [edit system services outbound-ssh client client-id] hierarchy level:

[edit system services outbound-ssh client client-id]

services {
netconf;
}

Configuring Outbound SSH Clients

To configure the clients available for this outbound SSH connection, list each client with a separate address
statement at the [edit system services outbound-ssh client client-id] hierarchy level:

[edit system services outbound-ssh client client-id]

address address {
retry number;
timeout seconds;
 274

port port-number;
}

NOTE: Outbound SSH connections support IPv4 and IPv6 address formats.

Configuring Routing Instances for Outbound SSH Clients

(SRX Series and MX Series only) Starting in Junos OS Release 19.3R1, you can specify the name of the
routing instance on which the outbound SSH connectivity needs to be established by including the
routing-instance statement at the [edit system services outbound-ssh] hierarchy level:

[edit system services outbound-ssh routing-instance routing-instance-name]

To use the management routing instance, first enable the mgmt_junos routing instance using the set system
management-instance command.

To use any other routing instance, first configure the routing instance at the [edit routing-instances]
hierarchy.

If you do not specify a routing instance, your device will establish the outbound SSH connection using the
default routing table.

Configuring NETCONF-Over-SSH Connections on a Specified TCP Port

The Junos OS enables you to restrict incoming NETCONF connections to a specified TCP port without
configuring a firewall. To configure the TCP port used for NETCONF-over-SSH connections, include the
port statement at the [edit system services netconf ssh] hierarchy level. The configured port accepts only
NETCONF-over-SSH sessions. Regular SSH session requests for this port are rejected.

You can either configure the default port 830 for NETCONF connections over SSH, as specified in RFC
4742, Using the NETCONF Configuration Protocol over Secure Shell (SSH), or configure any port from 1
through 65535.
 275

NOTE:
• The default SSH port (22) continues to accept NETCONF sessions even with a configured
NETCONF server port. To disable the SSH port from accepting NETCONF sessions, specify
this in the login event script.

• We do not recommend configuring the default ports for FTP (21) and Telnet (23) services for
configuring NETCONF-over-SSH connections.

SEE ALSO

port (NETCONF) | 1217

Configuring Password Retry Limits for Telnet and SSH Access

To prevent brute force and dictionary attacks, the device performs the following actions for Telnet or SSH
sessions by default:

• Disconnects a session after a maximum of 10 consecutive password retries.

• After the second password retry, introduces a delay in multiples of 5 seconds between subsequent
password retries.

For example, the device introduces a delay of 5 seconds between the third and fourth password retry,
a delay of 10 seconds between the fourth and fifth password retry, and so on.

• Enforces a minimum session time of 20 seconds during which a session cannot be disconnected.
Configuring the minimum session time prevents malicious users from disconnecting sessions before the
password retry delay goes into effect, and attempting brute force and dictionary attacks with multiple
logins.

You can configure the password retry limits for Telnet and SSH access. In this example, you configure the
device to take the following actions for Telnet and SSH sessions:

• Allow a maximum of four consecutive password retries before disconnecting a session.

• Introduce a delay in multiples of 5 seconds between password retries that occur after the second
password retry.

• Enforce a minimum session time of 40 seconds during which a session cannot be disconnected.
 276

To configure password retry limits for Telnet and SSH access:

1. Set the maximum number of consecutive password retries before a Telnet or SSH or telnet session is
disconnected. The default number is 10, but you can set a number from 1 through 10.

[edit system login retry-options]

user@host# set tries-before-disconnect 4

2. Set the threshold number of password retries after which a delay is introduced between two consecutive
password retries. The default number is 2, but you can specify a value from 1 through 3.

[edit system login retry-options]

user@host# set backoff-threshold 2

3. Set the delay (in seconds) between consecutive password retries after the threshold number of password
retries. The default delay is in multiples of 5 seconds, but you can specify a value from 5 through 10
seconds.

[edit system login retry-options]

user@host# set backoff-factor 5

4. Set the minimum length of time (in seconds) during which a Telnet or SSH session cannot be
disconnected. The default is 20 seconds, but you can specify an interval from 20 through 60 seconds.

[edit system login retry-options]

user@host# set minimum-time 40

5. If you are done configuring the device, enter commit from configuration mode.

Example: Configuring a Filter to Block Telnet and SSH Access

IN THIS SECTION

Requirements | 277

Overview | 277
 277

Configuration | 277

Verification | 280

Requirements

You must have access to a remote host that has network connectivity with this device.

Overview

In this example, you create an IPv4 stateless firewall filter that logs and rejects Telnet or SSH access packets
unless the packet is destined for or originates from the 192.168.1.0/24 subnet.

• To match packets destined for or originating from the address 192.168.1.0/24 subnet, you use the
source-address 192.168.1.0/24 IPv4 match condition.

• To match packets destined for or originating from a TCP port, Telnet port, or SSH port, you use the
protocol tcp, port telnet, and telnet ssh IPv4 match conditions.

Configuration

IN THIS SECTION

Configure the Stateless Firewall Filter | 278

Apply the Firewall Filter to the Loopback Interface | 279

Confirm and Commit Your Candidate Configuration | 279

The following example requires you to navigate various levels in the configuration hierarchy. For information
about navigating the CLI, see Using the CLI Editor in Configuration Mode.

To configure this example, perform the following tasks:

CLI Quick Configuration

 278

To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, copy and paste the
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

set firewall family inet filter local_acl term terminal_access from source-address 192.168.1.0/24
set firewall family inet filter local_acl term terminal_access from protocol tcp
set firewall family inet filter local_acl term terminal_access from port ssh
set firewall family inet filter local_acl term terminal_access from port telnet
set firewall family inet filter local_acl term terminal_access then accept
set firewall family inet filter local_acl term terminal_access_denied from protocol tcp
set firewall family inet filter local_acl term terminal_access_denied from port ssh
set firewall family inet filter local_acl term terminal_access_denied from port telnet
set firewall family inet filter local_acl term terminal_access_denied then log
set firewall family inet filter local_acl term terminal_access_denied then reject
set firewall family inet filter local_acl term default-term then accept
set interfaces lo0 unit 0 family inet filter input local_acl
set interfaces lo0 unit 0 family inet address 127.0.0.1/32

Configure the Stateless Firewall Filter

Step-by-Step Procedure
To configure the stateless firewall filter that selectively blocks Telnet and SSH access:

1. Create the stateless firewall filter local_acl.

[edit]
user@myhost# edit firewall family inet filter local_acl

2. Define the filter term terminal_access.

[edit firewall family inet filter local_acl]

user@myhost# set term terminal_access from source-address 192.168.1.0/24
user@myhost# set term terminal_access from protocol tcp
user@myhost# set term terminal_access from port ssh
user@myhost# set term terminal_access from port telnet
user@myhost# set term terminal_access then accept

3. Define the filter term terminal_access_denied.

[edit firewall family inet filter local_acl]

user@myhost# set term terminal_access_denied from protocol tcp
user@myhost# set term terminal_access_denied from port ssh
 279

user@myhost# set term terminal_access_denied from port telnet

user@myhost# set term terminal_access_denied then log
user@myhost# set term terminal_access_denied then reject
user@myhost# set term default-term then accept

Apply the Firewall Filter to the Loopback Interface

Step-by-Step Procedure

• To apply the firewall filter to the loopback interface:

[edit]
user@myhost# set interfaces lo0 unit 0 family inet filter input local_acl
user@myhost# set interfaces lo0 unit 0 family inet address 127.0.0.1/32

Confirm and Commit Your Candidate Configuration

Step-by-Step Procedure
To confirm and then commit your candidate configuration:

1. Confirm the configuration of the stateless firewall filter by entering the show firewall configuration
mode command. If the command output does not display the intended configuration, repeat the
instructions in this example to correct the configuration.

[edit]
user@myhost# show firewall
family inet {
filter local_acl {
term terminal_access {
from {
source-address {
192.168.1.0/24;
}
protocol tcp;
port [ssh telnet];
}
then accept;
}
term terminal_access_denied {
from {
protocol tcp;
port [ssh telnet];
}
 280

then {
log;
reject;
}
}
term default-term {
then accept;
}
}
}

2. Confirm the configuration of the interface by entering the show interfaces configuration mode command.
If the command output does not display the intended configuration, repeat the instructions in this
example to correct the configuration.

[edit]
user@myhost# show interfaces
lo0 {
unit 0 {
family inet {
filter {
input local_acl;
}
source-address 127.0.0.1/32;
}
}
}

3. If you are done configuring the device, commit your candidate configuration.

[edit]
user@myhost# commit

Verification

IN THIS SECTION

Verifying Accepted Packets | 281

Verifying Logged and Rejected Packets | 282

 281

Confirm that the configuration is working properly.

Verifying Accepted Packets

Purpose
Verify that the actions of the firewall filter terms are taken.

Action
1. Clear the firewall log on your router or switch.

user@myhost> clear firewall log

2. From a host at an IP address within the 192.168.1.0/24 subnet, use the ssh hostname command to
verify that you can log in to the device using only SSH. This packet should be accepted, and the packet
header information for this packet should not be logged in the firewall filter log buffer in the Packet
Forwarding Engine.

user@host-A> ssh myhost

user@myhosts’s password:
--- JUNOS 11.1-20101102.0 built 2010-11-02 04:48:46 UTC

% cli

user@myhost>

3. From a host at an IP address within the 192.168.1.0/24 subnet, use the telnet hostname command to
verify that you can log in to your router or switch using only Telnet. This packet should be accepted,
and the packet header information for this packet should not be logged in the firewall filter log buffer
in the Packet Forwarding Engine.

user@host-A> telnet myhost

Trying 192.168.249.71...
Connected to myhost-fxp0.example.net.
Escape character is '^]'.

host (ttyp0)

login: user

Password:

--- JUNOS 11.1-20101102.0 built 2010-11-02 04:48:46 UTC

 282

% cli

user@myhost>

4. Use the show firewall log command to verify that the routing table on the device does not contain any
entries with a source address in the 192.168.1.0/24 subnet.

user@myhost> show firewall log

Verifying Logged and Rejected Packets

Purpose
Verify that the actions of the firewall filter terms are taken.

Action
1. Clear the firewall log on your router or switch.

user@myhost> clear firewall log

2. From a host at an IP address outside of the 192.168.1.0/24 subnet, use the ssh hostname command to
verify that you cannot log in to the device using only SSH. This packet should be rejected, and the
packet header information for this packet should be logged in the firewall filter log buffer in the Packet
Forwarding Engine.

user@host-B ssh myhost

ssh: connect to host sugar port 22: Connection refused

--- JUNOS 11.1-20101102.0 built 2010-11-02 04:48:46 UTC
%

3. From a host at an IP address outside of the 192.168.1.0/24 subnet, use the telnet hostname command
to verify that you can log in to the device using only Telnet. This packet should be rejected, and the
packet header information for this packet should be logged in the firewall filter log buffer in the PFE.

user@host-B> telnet myhost

Trying 192.168.249.71...
telnet: connect to address 192.168.187.3: Connection refused
telnet: Unable to connect to remote host
%

4. Use the show firewall log command to verify that the routing table on the device does not contain any
entries with a source address in the 192.168.1.0/24 subnet.
 283

user@myhost> show firewall log

Time Filter Action Interface Protocol Src Addr Dest Addr

18:41:25 local_acl R fxp0.0 TCP 192.168.187.5 192.168.187.1
18:41:25 local_acl R fxp0.0 TCP 192.168.187.5 192.168.187.1
18:41:25 local_acl R fxp0.0 TCP 192.168.187.5 192.168.187.1
...
18:43:06 local_acl R fxp0.0 TCP 192.168.187.5 192.168.187.1
18:43:06 local_acl R fxp0.0 TCP 192.168.187.5 192.168.187.1
18:43:06 local_acl R fxp0.0 TCP 192.168.187.5 192.168.187.1
...

Release History Table

Release Description

19.4R1 Starting in Junos OS Release 19.4R1, you can disable either the SSH login password or the
challenge-response authentication using the no-password-authentication and
no-challenge-response options at the [edit system services ssh] hierarchy level.

Junos OS Release Starting in Junos OS Release 19.1R1, we have globally disabled the incoming SFTP connections
19.1R1 by default. If desired, you can globally enable incoming SFTP connections by configuring the
statement sftp-server at the [edit system services ssh] hierarchy level

18.3R1 Starting in Junos OS Release 18.3R1, the ssh-dss and ssh-dsa hostkey algorithms are
deprecated— rather than immediately removed—to provide backward compatibility and a
chance to bring your configuration into compliance with the new configuration.

RELATED DOCUMENTATION

USB Modems for Remote Management of Security Devices | 284

Secure Web Access for Remote Management | 304
 284

USB Modems for Remote Management of Security

Devices

IN THIS SECTION

USB Modem Interface Overview | 284

USB Modem Configuration Overview | 287

Example: Configuring a USB Modem Interface | 290

Example: Configuring a Dialer Interface | 293

Example: Configuring a Dialer Interface for USB Modem Dial-In | 298

Configuring a Dial-Up Modem Connection Remotely | 300

Connecting to the Device Remotely | 302

Modifying USB Modem Initialization Commands | 302

Resetting USB Modems | 303

Junos OS allows the use of USB modems for remote management on SRX Series device. You can use
Telnet or SSH to connect to the device from a remote location through two modems over a telephone
network. For more information, read this topic.

USB Modem Interface Overview

Juniper Networks SRX Series devices support the use of USB modems for remote management. You can
use Telnet or SSH to connect to the device from a remote location through two modems over a telephone
network. The USB modem is connected to the USB port on the device, and a second modem is connected
to a remote management device such as a PC or laptop computer.

NOTE: USB modems are no longer supported for dial backup on SRX300, SRX320, SRX340,
SRX345, SRX380, and SRX550HM devices.

You can configure your device to fail over to a USB modem connection when the primary Internet
connection experiences interruption.
 285

A USB modem connects to a device through modem interfaces that you configure. The device applies its
own modem AT commands to initialize the attached modem. Modem setup requires that you connect and
configure the USB modem at the device and the modem at the user end of the network.

You use either the J-Web configuration editor or CLI configuration editor to configure the USB modem
and its supporting dialer interfaces.

NOTE: Low-latency traffic such as VoIP traffic is not supported over USB modem connections.

NOTE: We recommend using a US Robotics USB 56k V.92 Modem, model number USR Model
5637.

USB Modem Interfaces

You configure two types of interfaces for USB modem connectivity:

• A physical interface which uses the naming convention umd0. The device creates this interface when a
USB modem is connected to the USB port.

• A logical interface called the dialer interface. You use the dialer interface, dln, to configure dialing
properties for USB modem connections. The dialer interface can be configured using Point-to-Point
Protocol (PPP) encapsulation. You can also configure the dialer interface to support authentication
protocols—PPP Challenge Handshake (CHAP) or Password Authentication Protocol (PAP). You can
configure multiple dialer interfaces for different functions on the device. After configuring the dialer
interface, you must configure a backup method such as a dialer backup, a dialer filter, or a dialer watch.

The USB modem provides a dial-in remote management interface, and supports dialer interface features
by sharing the same dial pool as a dialer interface. The dial pool allows the logical dialer interface and the
physical interface to be bound together dynamically on a per-call basis. You can configure the USB modem
to operate either as a dial-in console for management or as a dial-in WAN backup interface. Dialer pool
priority has a range from 1 to 255, with 1 designating the lowest priority interfaces and 255 designating
the highest priority interfaces.

Dialer Interface Rules

The following rules apply when you configure dialer interfaces for USB modem connections:

• The dialer interface must be configured to use PPP encapsulation. You cannot configure Cisco High-Level
Data Link Control (HDLC) or Multilink PPP (MLPPP) encapsulation on dialer interfaces.

• The dialer interface cannot be configured as a constituent link in a multilink bundle.

 286

• The dialer interface can perform backup, dialer filter, and dialer watch functions, but these operations
are mutually exclusive. You can configure a single dialer interface to operate in only one of the following
ways:

• As a backup interface—for one primary interface

• As a dialer filter

• As a dialer watch interface

The backup dialer interfaces are activated only when the primary interface fails. USB modem backup
connectivity is supported on all interfaces except lsq-0/0/0.

The dial-on-demand routing backup method allows a USB modem connection to be activated only when
network traffic configured as an “interesting packet” arrives on the network. Once the network traffic is
sent, an inactivity timer is triggered and the connection is closed. You define an interesting packet using
the dialer filter feature of the device. To configure dial-on-demand routing backup using a dialer filter, you
first configure the dialer filter and then apply the filter to the dialer interface.

Dialer watch is a backup method that integrates backup dialing with routing capabilities and provides
reliable connectivity without relying on a dialer filter to trigger outgoing USB modem connections. With
dialer watch, the device monitors the existence of a specified route. If the route disappears, the dialer
interface initiates the USB modem connection as a backup connection.

How the Device Initializes USB Modems

When you connect the USB modem to the USB port on the device, the device applies the modem AT
commands configured in the init-command-string command to the initialization commands on the modem.

If you do not configure modem AT commands for the init-command-string command, the device applies
the following default sequence of initialization commands to the modem: AT S7=45 S0=0 V1 X4 &C1 E0
Q0 &Q8 %C0. Table 19 on page 286 describes the commands. For more information about these commands,
see the documentation for your modem.

Table 19: Default Modem Initialization Commands

Modem Command Description

AT Attention. Informs the modem that a command follows.

S7=45 Instructs the modem to wait 45 seconds for a telecommunications service

provider (carrier) signal before terminating the call.

S0=0 Disables the auto answer feature, whereby the modem automatically answers
calls.

V1 Displays result codes as words.

 287

Table 19: Default Modem Initialization Commands (continued)

Modem Command Description

&C1 Disables reset of the modem when it loses the carrier signal.

E0 Disables the display on the local terminal of commands issued to the modem
from the local terminal.

Q0 Enables the display of result codes.

&Q8 Enables Microcom Networking Protocol (MNP) error control mode.

%C0 Disables data compression.

When the device applies the modem AT commands in the init-command-string command or the default
sequence of initialization commands to the modem, it compares them to the initialization commands already
configured on the modem and makes the following changes:

• If the commands are the same, the device overrides existing modem values that do not match. For
example, if the initialization commands on the modem include S0=0 and the device’s init-command-string
command includes S0=2, the device applies S0=2.

• If the initialization commands on the modem do not include a command in the device’s
init-command-string command, the device adds it. For example, if the init-command-string command
includes the command L2, but the modem commands do not include it, the device adds L2 to the
initialization commands configured on the modem.

NOTE: On SRX210 devices, the USB modem interface can handle bidirectional traffic of up to
19 Kbps. On oversubscription of this amount (that is, bidirectional traffic of 20 Kbps or above),
keepalives do not get exchanged, and the interface goes down. (Platform support depends on
the Junos OS release in your installation.)

USB Modem Configuration Overview

NOTE: USB modems are no longer supported for dial backup on SRX300, SRX320, SRX340,
and SRX345 devices.
 288

Before you begin:

1. Install device hardware. For more information, see the Getting Started Guide for your device.

2. Establish basic connectivity. For more information, see the Getting Started Guide for your device.

3. Order a US Robotics USB 56k V.92 Modem, model number USR Model 5637 (http://www.usr.com/).

4. Order a public switched telephone network (PSTN) line from your telecommunications service provider.
Contact your service provider for more information.

5. Connect the USB modem to the device's USB port.

NOTE: When you connect the USB modem to the USB port on the device, the USB modem
is initialized with the modem initialization string configured for the USB modem interface on
the device.

a. Plug the modem into the USB port.

b. Connect the modem to your telephone network.

i.

Suppose you have a branch office router and a head office router each with a USB modem interface and
a dialer interface. This example shows you how to establish a backup connection between the branch
office and head office routers. See Table 20 on page 289 for a summarized description of the procedure.
 289

Table 20: Configuring Branch Office and Head Office Routers for USB Modem Backup Connectivity

Router Location Configuration Requirement Procedure

Branch Office Configure the logical dialer interface on To configure the logical dialer
the branch office router for USB modem interface, see “Example: Configuring
dial backup. a USB Modem Interface” on page 290.

Configure the dialer interface dl0 on the Configure the dialer interface using
branch office router using one of the one of the following backup methods:
following backup methods:
• To configure dl0 as a backup for
• Configure the dialer interface dl0 as the t1-1/0/0 see Example: Configuring
backup interface on the branch office Dialer Interfaces and Backup
router's primary T1 interface t1-1/0/0. Methods for USB Modem Dial
• Configure a dialer filter on the branch Backup.
office router's dialer interface. • To configure a dialer filter on dl0,
• Configure a dialer watch on the branch see Example: Configuring Dialer
office router's dialer interface. Interfaces and Backup Methods for
USB Modem Dial Backup.
• To configure a dialer watch on dl0,
see Example: Configuring Dialer
Interfaces and Backup Methods for
USB Modem Dial Backup.

Head Office Configure dial-in on the dialer interface To configure dial-in on the head office
dl0 on the head office router. router, see “Example: Configuring a
Dialer Interface for USB Modem
Dial-In” on page 298.

If the dialer interface is configured to accept only calls from a specific caller ID, the device matches the
incoming call's caller ID against the caller IDs configured on its dialer interfaces. If an exact match is not
found and the incoming call's caller ID has more digits than the configured caller IDs, the device performs
a right-to-left match of the incoming call's caller ID with the configured caller IDs and accepts the incoming
call if a match is found. For example, if the incoming call's caller ID is 4085321091 and the caller ID
configured on a dialer interface is 5321091, the incoming call is accepted. Each dialer interface accepts
calls from only callers whose caller IDs are configured on it.

See Table 21 on page 290 for a list of available incoming map options.
 290

Table 21: Incoming Map Options

Option Description

accept-all Dialer interface accepts all incoming calls.

You can configure the accept-all option for only one of the dialer interfaces
associated with a USB modem physical interface. The dialer interface with
the accept-all option configured is used only if the incoming call's caller
ID does not match the caller IDs configured on other dialer interfaces.

caller Dialer interface accepts calls from a specific caller ID. You can configure
a maximum of 15 caller IDs per dialer interface.

The same caller ID must not be configured on different dialer interfaces.

However, you can configure caller IDs with more or fewer digits on
different dialer interfaces. For example, you can configure the caller IDs
14085551515, 4085551515, and 5551515 on different dialer interfaces.

You configure dialer interfaces to support PAP. PAP allows a simple method for a peer to establish its
identity using a two-way handshake during initial link establishment. After the link is established, an ID
and password pair are repeatedly sent by the peer to the authenticator until authentication is acknowledged
or the connection is terminated.

Example: Configuring a USB Modem Interface

IN THIS SECTION

Requirements | 291

Overview | 291

Configuration | 291

Verification | 292

This example shows how to configure a USB modem interface for dial backup.

NOTE: USB modems are no longer supported for dial backup on SRX300, SRX320, SRX340,
and SRX345 devices.
 291

Requirements

No special configuration beyond device initialization is required before configuring this feature.

Overview

In this example, you create an interface called as umd0 for USB modem connectivity and set the dialer
pool priority to 25. You also configure a modem initialization string to autoanswer after a specified number
of rings. The default modem initialization string is AT S7=45 S0=0 V1 X4 &C1 E0 Q0 &Q8 %C0. The
modem command S0=0 disables the modem from autoanswering the calls. Finally, you set the modem to
act as a dial-in WAN backup interface.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following command, paste it into a text file, remove any line
breaks, change any details necessary to match your network configuration, copy and paste the command
into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

set interfaces umd0 dialer-options pool usb-modem-dialer-pool priority 25

set modem-options init-command-string "ATS0=2 \n" dialin routable

Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions
on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure a USB modem interface for dial backup:

1. Create an interface.

[edit]
user@host# edit interfaces umd0

2. Set the dialer options and priority.

[edit interfaces umd0]

user@host# set dialer-options pool usb-modem-dialer-pool priority 25

3. Specify the modem options.

[edit interfaces umd0]

 292

user@host# set modem-options init-command-string "ATS0=2 \n"

4. Set the modem to act as a dial-in WAN backup interface.

[edit interfaces umd0]

user@host# set modem-options dialin routable

Results
From configuration mode, confirm your configuration by entering the show interface umd0 command. If
the output does not display the intended configuration, repeat the configuration instructions in this example
to correct it.

[edit]
user@host# show interface umd0
modem-options {
init-command-string "ATS0=2 \n";
dialin routable;
}
dialer-options {
pool usb-modem-dialer-pool priority 25;
}

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying the Configuration

Purpose
Verify a USB modem interface for dial backup.

Action
From configuration mode, enter the show interfaces umd0 extensive command. The output shows a
summary of interface information and displays the modem status.

Physical interface: umd0, Enabled, Physical link is Up

Interface index: 64, SNMP ifIndex: 33, Generation: 1
Type: Async-Serial, Link-level type: PPP-Subordinate, MTU: 1504,
 293

Clocking: Unspecified, Speed: MODEM

Device flags : Present Running
Interface flags: Point-To-Point SNMP-Traps Internal: 0x4000
Link flags : None
Hold-times : Up 0 ms, Down 0 ms
Last flapped : Never
Statistics last cleared: Never
Traffic statistics:
Input bytes : 21672
Output bytes : 22558
Input packets: 1782
Output packets: 1832
Input errors:
Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Giants: 0, Policed discards:
0,
Resource errors: 0
Output errors:
Carrier transitions: 63, Errors: 0, Drops: 0, MTU errors: 0, Resource errors:
0
MODEM status:
Modem type : LT V.92 1.0 MT5634ZBA-USB-V92 Data/Fax Modem
(Dual Config) Version 2.27m
Initialization command string : ATS0=2
Initialization status : Ok
Call status : Connected to 4085551515
Call duration : 13429 seconds
Call direction : Dialin
Baud rate : 33600 bps
Most recent error code : NO CARRIER

Logical interface umd0.0 (Index 2) (SNMP ifIndex 34) (Generation 1)

Flags: Point-To-Point SNMP-Traps Encapsulation: PPP-Subordinate

Example: Configuring a Dialer Interface

IN THIS SECTION

Requirements | 294

Overview | 294
 294

Configuration | 295

Verification | 296

This example shows how to configure a logical dialer interface for an SRX300, SRX320, SRX340, or SRX345
device.

Requirements

Before you begin:

• Install device hardware and establish basic connectivity. See the Getting Started Guide for your device.

• Order a US Robotics USB 56k V.92 Modem, model number USR Model 5637, from US Robotics
(http://www.usr.com/).

• Order a dial-up modem for the PC or laptop computer at the remote location from where you want to
connect to the device.

• Order a PSTN line from your telecommunications service provider. Contact your service provider.

Overview

In this example, you configure a logical dialer interface called dl0 to establish USB connectivity. You can
configure multiple dialer interfaces for different functions on the device. You add a description to
differentiate among different dialer interfaces. For example, this modem is called
USB-modem-remote-management. Configure PPP encapsulation and set the logical unit as 0. You then
specify the name of the dialer pool as usb-modem-dialer-pool and set the source and destination IP
addresses as 172.20.10.2, and 172.20.10.1, respectively.

NOTE: You cannot configure Cisco High-Level Data Link Control (HDLC) or Multilink PPP
(MLPPP) encapsulation on dialer interfaces used in USB modem connections.
 295

NOTE: If you configure multiple dialer interfaces, ensure that the same IP subnet address is not
configured on different dialer interfaces. Configuring the same IP subnet address on multiple
dialer interfaces can result in inconsistency in the route and packet loss. The device might route
packets through another dialer interface with the IP subnet address instead of through the dialer
interface to which the USB modem call is mapped.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, copy and paste the
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

set interfaces dl0 description USB-modem-remote-management encapsulation ppp

set interfaces dl0 unit 0 dialer-options pool usb-modem-dialer-pool
set interfaces dl0 unit 0 family inet address 172.20.10.2 destination 172.20.10.1

Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions
on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure a logical dialer interface for the device:

1. Create an interface.

[edit]
user@host# set interfaces dl0

2. Add a description and configure PPP encapsulation.

[edit interfaces dl0]

user@host# set description USB-modem-remote-management
user@host# set encapsulation ppp

3. Create the logical unit.

NOTE: The logical unit number must be 0.

 296

[edit interfaces dl0]

user@host# set unit 0

4. Configure the name of the dialer pool to use for USB modem connectivity.

[edit interfaces dl0 unit 0]

user@host# set dialer-options pool usb-modem-dialer-pool

5. Configure source and destination IP addresses for the dialer interface.

[edit interfaces dl0 unit 0]

user@host# set family inet address 172.20.10.2 destination 172.20.10.1

Results
From configuration mode, confirm your configuration by entering the show interfaces dl0 command. If
the output does not display the intended configuration, repeat the configuration instructions in this example
to correct it.

[edit]
user@host# show interfaces dl0
description USB-modem-remote-management;
encapsulation ppp;
unit 0 {
family inet {
address 172.20.10.2/32 {
destination 172.20.10.1;
}
}
dialer-options {
pool usb-modem-dialer-pool;
}
}

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

 297

Verifying a Dialer Interface

Purpose
Verify that the dialer interface has been configured.

Action
From configuration mode, enter the show interfaces dl0 extensive command. The output shows a summary
of dialer interface information.

Physical interface: dl0, Enabled, Physical link is Up

Interface index: 128, SNMP ifIndex: 24, Generation: 129
Type: 27, Link-level type: PPP, MTU: 1504, Clocking: Unspecified, Speed:
Unspecified
Device flags : Present Running
Interface flags: SNMP-Traps
Link type : Full-Duplex
Link flags : Keepalives
Physical info : Unspecified
Hold-times : Up 0 ms, Down 0 ms
Current address: Unspecified, Hardware address: Unspecified
Alternate link address: Unspecified
Last flapped : Never
Statistics last cleared: Never
Traffic statistics:
Input bytes : 13859 0 bps
Output bytes : 0 0 bps
Input packets: 317 0 pps
Output packets: 0 0 pps
Input errors:
Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Giants: 0, Policed discards:
0,
Resource errors: 0
Output errors:
Carrier transitions: 0, Errors: 0, Drops: 0, MTU errors: 0, Resource errors:
0

Logical interface dl0.0 (Index 70) (SNMP ifIndex 75) (Generation 146)
Description: USB-modem-remote-management
Flags: Point-To-Point SNMP-Traps 0x4000 LinkAddress 23-0 Encapsulation: PPP
Dialer:
State: Active, Dial pool: usb-modem-dialer-pool
Dial strings: 220
Subordinate interfaces: umd0 (Index 64)
Activation delay: 0, Deactivation delay: 0
Initial route check delay: 120
 298

Redial delay: 3
Callback wait period: 5
Load threshold: 0, Load interval: 60
Bandwidth: 115200
Traffic statistics:
Input bytes : 24839
Output bytes : 17792
Input packets: 489
Output packets: 340
Local statistics:
Input bytes : 10980
Output bytes : 17792
Input packets: 172
Output packets: 340
Transit statistics:
Input bytes : 13859 0 bps
Output bytes : 0 0 bps
Input packets: 317 0 pps
Output packets: 0 0 pps
LCP state: Opened
NCP state: inet: Opened, inet6: Not-configured, iso: Not-configured,
mpls: Not-configured
CHAP state: Success
Protocol inet, MTU: 1500, Generation: 136, Route table: 0
Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 172.20.10.1, Local: 172.20.10.2, Broadcast: Unspecified,
Generation: 134

Example: Configuring a Dialer Interface for USB Modem Dial-In

IN THIS SECTION

Requirements | 299

Overview | 299

Configuration | 299

Verification | 300
 299

This example shows how to configure a dialer interface for USB modem dial-in.

NOTE: USB modems are no longer supported for dial-in to a dialer interface on SRX300, SRX320,
SRX340, and SRX345 devices.

Requirements

No special configuration beyond device initialization is required before configuring this feature.

Overview

To enable connections to the USB modem from a remote location, you must configure the dialer interfaces
set up for USB modem use to accept incoming calls. You can configure a dialer interface to accept all
incoming calls or accept only calls from one or more caller IDs.

If the dialer interface is configured to accept only calls from a specific caller ID, the system matches the
incoming call's caller ID against the caller IDs configured on its dialer interfaces. If an exact match is not
found and the incoming call's caller ID has more digits than the configured caller IDs, the system performs
a right-to-left match of the incoming call's caller ID with the configured caller IDs and accepts the incoming
call if a match is found. For example, if the incoming call's caller ID is 4085550115 and the caller ID
configured on a dialer interface is 5550115, the incoming call is accepted. Each dialer interface accepts
calls from only callers whose caller IDs are configured on it.

You can configure the following incoming map options for the dialer interface:

• accept-all—Dialer interface accepts all incoming calls.

You can configure the accept-all option for only one of the dialer interfaces associated with a USB
modem physical interface. The device uses the dialer interface with the accept-all option configured
only if the incoming call's caller ID does not match the caller IDs configured on other dialer interfaces.

• caller—Dialer interface accepts calls from a specific caller ID— for example, 4085550115. You can
configure a maximum of 15 caller IDs per dialer interface.

The same caller ID must not be configured on different dialer interfaces. However, you can configure
caller IDs with more or fewer digits on different dialer interfaces. For example, you can configure the
caller IDs 14085550115, 4085550115, and 5550115 on different dialer interfaces.

In this example, you configure the incoming map option as caller 4085550115 for dialer interface dl0.

Configuration

CLI Quick Configuration

 300

To quickly configure this example, copy the following command, paste it into a text file, remove any line
breaks, change any details necessary to match your network configuration, copy and paste the command
into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

set interfaces dl0 unit 0 dialer-options incoming-map caller 4085550115

Step-by-Step Procedure
To configure a dialer interface for USB modem dial-in:

1. Select a dialer interface.

[edit]
user@host# edit interfaces dl0

2. Configure the incoming map options.

[edit]
user@host# edit unit 0 dialer-options incoming-map caller 4085551515

3. If you are done configuring the device, commit the configuration.

[edit]
user@host# commit

Verification

To verify the configuration is working properly, enter the show interface dl0 command.

Configuring a Dial-Up Modem Connection Remotely

To remotely connect to the USB modem connected to the USB port on the device, you must configure a
dial-up modem connection on the PC or laptop computer at your remote location. Configure the dial-up
modem connection properties to disable IP header compression.

To configure a dial-up modem connection remotely:

 301

1. At your remote location, connect a modem to a management device such as a PC or laptop computer.

2. Connect the modem to your telephone network.

3. On the PC or laptop computer, select Start>Settings>Control Panel>Network Connections. The

Network Connections page appearts.

4. Click Create a new connection. The New Connection Wizard appears.

5. Click Next. The New Connection Wizard: Network Connection Type page appears.

6. Select Connect to the network at my workplace, and then click Next.

The New Connection Wizard: Network Connection page appears.

7. Select Dial-up connection, and then click Next. The New Connection Wizard: Connection Name page
appears.

8. In the Company Name box, type the dial-up connection name, for example USB-modem-connect. Then,
click Next. The New Connection Wizard: Phone Number to Dial page appears.

9. In the Phone number box, type the telephone number of the PSTN line connected to the USB modem
at the device end.

10. Click Next twice, and then click Finish. The Connect USB-modem-connect page appears.

11. If CHAP is configured on the dialer interface used for the USB modem interface at the device end, type
the username and password configured in the CHAP configuration in the User name and Password
boxes.

12. Click Properties. The USB-modem-connect Properties page appears.

13. In the Networking tab, select Internet Protocol (TCP/IP), and then click Properties. The Internet Protocol
(TCP/IP) Properties page appears.

14. Click Advanced. The Advanced TCP/IP Settings page appears.

15. Clear the Use IP header compression check box.

 302

Connecting to the Device Remotely

To remotely connect to the device through a USB modem connected to the USB port on the device:

1. On the PC or laptop computer at your remote location, select Start>Settings>Control Panel>Network

Connections. The Network Connections page appears.

2. Double-click the USB-modem-connect dial-up connection. The Connect USB-modem-connect page

appears.

3. Click Dial to connect to the Juniper Networks device.

When the connection is complete, you can use Telnet or SSH to connect to the device.

Modifying USB Modem Initialization Commands

NOTE: These instructions use Hayes-compatible modem commands to configure the modem.
If your modem is not Hayes-compatible, see the documentation for your modem and enter
equivalent modem commands. Applies to SRX300, SRX320, SRX340, SRX345 devices.

You can use the CLI configuration editor to override the value of an initialization command configured on
the USB modem or configure additional commands for initializing USB modems.

NOTE: If you modify modem initialization commands when a call is in progress, the new
initialization sequence is applied on the modem only when the call ends.

You can configure the following modem AT commands to initialize the USB modem:

• The command S0=2 configures the modem to automatically answer calls on the second ring.

• The command L2 configures medium speaker volume on the modem.

You can insert spaces between commands.

When you configure modem commands in the CLI configuration editor, you must follow these conventions:

• Use the newline character \n to indicate the end of a command sequence.

• Enclose the command string in double quotation marks.

 303

You can override the value of the S0=0 command in the initialization sequence configured on the modem
and add the L2 command.

To modify the initialization commands on a USB modem:

1. Configure the modem AT commands to initialize the USB modem.

[edit interfaces umd0]

user@host# set modem-options init-command-string "AT S0=2 L2 \n"

2. If you are done configuring the device, enter commit from configuration mode.

Resetting USB Modems

For SRX300, SRX320, SRX340, and SRX345 devices, if the USB modem does not respond, you can reset
the modem.

CAUTION: If you reset the modem when a call is in progress, the call is terminated.

To reset the USB modem, in operational mode, enter the following command:

user@host> request interface modem reset umd0

RELATED DOCUMENTATION

Junos OS User Authentication Overview | 172

USB Modems for Remote Management of Security Devices | 284
Secure Web Access for Remote Management | 304
 304

Secure Web Access for Remote Management

IN THIS SECTION

Secure Web Access Overview | 304

Generating SSL Certificates for Secure Web Access (SRX Series Devices) | 305

Generating SSL Certificates to Be Used for Secure Web Access (EX Series Switch) | 306

Generating a Self-Signed SSL Certificate Automatically | 307

Manually Generating Self-Signed SSL Certificates | 307

Deleting Self-Signed Certificates (CLI Procedure) | 308

Understanding Self-Signed Certificates on EX Series Switches | 308

Manually Generating Self-Signed Certificates on Switches (CLI Procedure) | 310

Example: Configuring Secure Web Access | 311

You can manage a Juniper Networks device remotely through the J-Web interface. To enable secure Web
access, the Juniper Networks devices support HTTP over Secure Sockets Layer (HTTPS). You can enable
HTTP or HTTPS access on specific interfaces and ports on the device as needed. Read this topic for
information.

Secure Web Access Overview

You can manage a Juniper Networks device remotely through the J-Web interface. To communicate with
the device, the J-Web interface uses the Hypertext Transfer Protocol (HTTP). HTTP allows easy Web
access but no encryption. The data that is transmitted between the Web browser and the device by means
of HTTP is vulnerable to interception and attack. To enable secure Web access, the Juniper Networks
devices support HTTP over Secure Sockets Layer (HTTPS). You can enable HTTP or HTTPS access on
specific interfaces and ports as needed.

The Juniper Networks device uses the Secure Sockets Layer (SSL) protocol to provide secure device
management through the Web interface. SSL uses public-private key technology that requires a paired
private key and an authentication certificate for providing the SSL service. SSL encrypts communication
between your device and the Web browser with a session key negotiated by the SSL server certificate.

An SSL certificate includes identifying information such as a public key and a signature made by a certificate
authority (CA). When you access the device through HTTPS, an SSL handshake authenticates the server
 305

and the client and begins a secure session. If the information does not match or the certificate has expired,
you cannot access the device through HTTPS.

Without SSL encryption, communication between your device and the browser is sent in the open and
can be intercepted. We recommend that you enable HTTPS access on your WAN interfaces.

HTTP access is enabled by default on the built-in management interfaces. By default, HTTPS access is
supported on any interface with an SSL server certificate.

SEE ALSO

Configuring Device Addresses (IPv4 and Loopback Addresses)

Generating SSL Certificates for Secure Web Access (SRX Series Devices)

To generate an SSL certificate using the openssl command:

1. Enter openssl in the CLI. The openssl command generates a self-signed SSL certificate in
privacy-enhanced mail (PEM) format. It writes the certificate and an unencrypted 1024-bit RSA private
key to the specified file.

NOTE: Run this command on a LINUX or UNIX device because Juniper Networks Services
Gateways do not support the openssl command.

% openssl req –x509 –nodes –newkey rsa:1024 –keyout filename.pem -out filename.pem

Replace filename with the name of a file in which you want the SSL certificate to be written—for example,
new.pem.

2. When prompted, type the appropriate information in the identification form. For example, type US for
the country name.

3. Display the contents of the file new.pem.

cat new.pem

Copy the contents of this file for installing the SSL certificate.
 306

Generating SSL Certificates to Be Used for Secure Web Access (EX Series
Switch)

You can set up secure Web access for an EX Series switch. To enable secure Web access, you must generate
a digital Secure Sockets Layer (SSL) certificate and then enable HTTPS access on the switch.

To generate an SSL certificate:

1. Enter the following openssl command in your SSH command-line interface on a BSD or Linux system
on which openssl is installed. The openssl command generates a self-signed SSL certificate in the
privacy-enhanced mail (PEM) format. It writes the certificate and an unencrypted 1024-bit RSA private
key to the specified file.

% openssl req –x509 –nodes –newkey rsa:1024 –keyout filename.pem -out filename.pem

where filename is the name of a file in which you want the SSL certificate to be written—for example,
my-certificate.

2. When prompted, type the appropriate information in the identification form. For example, type US for
the country name.

3. Display the contents of the file that you created.

cat my-certificate.pem

You can use the J-Web Configuration page to install the SSL certificate on the switch. To do this, copy
the file containing the certificate from the BSD or Linux system to the switch. Then open the file, copy its
contents, and paste them into the Certificate box on the J-Web Secure Access Configuration page.

You can also use the following CLI statement to install the SSL certificate on the switch:

[edit]
user@switch# set security certificates local my-signed-cert load-key-file my-certificate.pem

For more information on installing certificates, see “Example: Configuring Secure Web Access” on page 311.

SEE ALSO

Configuring Management Access for the EX Series Switch (J-Web Procedure)

Overview of Port Security
 307

Generating a Self-Signed SSL Certificate Automatically

To generate a self-signed SSL certificate on Juniper Networks devices:

1. Establish basic connectivity.

2. Reboot the system. The self-signed certificate is automatically generated at bootup time.

user@host> request system reboot

Reboot the system ? [yes,no] yes

3. Specify system-generated-certificate under HTTPS Web management.

[edit]
user@host# show system services web-management https system-generated-certificate

Manually Generating Self-Signed SSL Certificates

To manually generate a self-signed SSL certificate on Juniper Networks devices:

1. Establish basic connectivity.

2. If you have root login access, you can manually generate the self-signed certificate by using the following
commands:

root@host> request security pki generate-key-pair size 512 certificate-id certname

Generated key pair sslcert, key size 512 bits

root@host> request security pki local-certificate generate-self-signed certificate-id cert-name email email
domain-name domain name ip-address IP address subject “DC= Domain name, CN= Common-Name, OU=
Organizational-Unit-name, O= Organization-Name, ST= state, C= Country”

Self-signed certificate generated and loaded successfully

 308

NOTE: When generating the certificate, you must specify the subject, e-mail address, and
either domain-name or ip-address.

3. To verify that the certificate was generated and loaded properly, enter the show security pki
local-certificate operational command and specify local-certificate under HTTPS Web management.

[edit]
root@host# show system services web-management https local-certificate certname

Deleting Self-Signed Certificates (CLI Procedure)

You can delete a self-signed certificate that is automatically or manually generated from the EX Series
switch. When you delete the automatically generated self-signed certificate, the switch generates a new
self-signed certificate and stores it in the file system.

• To delete the automatically generated certificate and its associated key pair from the switch:

user@switch> clear security pki local-certificate system-generated

• To delete a manually generated certificate and its associated key pair from the switch:

user@switch> clear security pki local-certificate certificate-id certificate-id-name

• To delete all manually generated certificates and their associated key pairs from the switch:

user@switch> clear security pki local-certificate all

Understanding Self-Signed Certificates on EX Series Switches

When you initialize a Juniper Networks EX Series Ethernet Switch with the factory default configuration,
the switch generates a self-signed certificate, allowing secure access to the switch through the Secure
Sockets Layer (SSL) protocol. Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) and XML
Network Management over Secure Sockets Layer (XNM-SSL) are the two services that can make use of
the self-signed certificates.
 309

NOTE: Self-signed certificates do not provide additional security as do those generated by

Certificate Authorities (CAs). This is because a client cannot verify that the server he or she has
connected to is the one advertised in the certificate.

The switches provide two methods for generating a self-signed certificate:

• Automatic generation

In this case, the creator of the certificate is the switch. An automatically generated (also called
“system-generated”) self-signed certificate is configured on the switch by default.

After the switch is initialized, it checks for the presence of an automatically generated self-signed
certificate. If it does not find one, the switch generates one and saves it in the file system.

A self-signed certificate that is automatically generated by the switch is similar to an SSH host key. It is
stored in the file system, not as part of the configuration. It persists when the switch is rebooted, and it
is preserved when a request system snapshot command is issued.

The switch uses the following distinguished name for the automatically generated certificate:

“ CN=<device serial number>, CN=system generated, CN=self-signed”

If you delete the system-generated self-signed certificate on the switch, the switch generates a self-signed
certificate automatically.

• Manual generation

In this case, you create the self-signed certificate for the switch. At any time, you can use the CLI to
generate a self-signed certificate. Manually generated self-signed certificates are stored in the file system,
not as part of the configuration.

Self-signed certificates are valid for five years from the time they are generated. When the validity of an
automatically generated self-signed certificate expires, you can delete it from the switch so that the switch
generates a new self-signed certificate.

System-generated self-signed certificates and manually generated self-signed certificates can coexist on
the switch.
 310

Manually Generating Self-Signed Certificates on Switches (CLI Procedure)

IN THIS SECTION

Generating a Public-Private Key Pair on Switches | 310

Generating Self-Signed Certificates on Switches | 311

EX Series switches allow you to generate custom self-signed certificates and store them in the file system.
The certificate you generate manually can coexist with the automatically generated self-signed certificate
on the switch. To enable secure access to the switch over SSL, you can use either the system-generated
self-signed certificate or a certificate you have generated manually.

To generate self-signed certificates manually, you must complete the following tasks:

Generating a Public-Private Key Pair on Switches

A digital certificate has an associated cryptographic key pair that is used to sign the certificate digitally.
The cryptographic key pair comprises a public key and a private key. When you generate a self-signed
certificate, you must provide a public-private key pair that can be used to sign the self-signed certificate.
Therefore, you must generate a public-private key pair before you can generate a self-signed certificate.

To generate a public-private key pair:

user@switch> request security pki generate-key-pair certificate-id certificate-id-name

NOTE: Optionally, you can specify the encryption algorithm and the size of the encryption key.
If you do not specify the encryption algorithm and encryption key size, default values are used.
The default encryption algorithm is RSA, and the default encryption key size is 1024 bits.

After the public-private key pair is generated, the switch displays the following:

generated key pair certificate-id-name, key size 1024 bits

 311

Generating Self-Signed Certificates on Switches

To generate the self-signed certificate manually, include the certificate ID name, the subject of the
distinguished name (DN), the domain name, the IP address of the switch, and the e-mail address of the
certificate holder:

user@switch> request security pki local-certificate generate-self-signed certificate-id certificate-id-name

domain-name domain-name email email-address ip-address switch-ip-address subject
subject-of-distinguished-name

The certificate you have generated is stored in the switch’s file system. The certificate ID you have specified
while generating the certificate is a unique identifier that you can use to enable the HTTPS or XNM-SSL
services.

To verify that the certificate was generated and loaded properly, enter the show security pki local-certificate
operational command.

SEE ALSO

Enabling HTTPS and XNM-SSL Services on Switches Using Self-Signed Certificates (CLI Procedure)

Example: Configuring Secure Web Access

IN THIS SECTION

Requirements | 311

Overview | 312

Configuration | 312

Verification | 313

This example shows how to configure secure Web access on your device.

Requirements

No special configuration beyond device initialization is required before configuring this feature.
 312

NOTE: You can enable HTTPS access on specified interfaces. If you enable HTTPS without
specifying an interface, HTTPS is enabled on all interfaces.

Overview

In this example, you import the SSL certificate that you have generated as a new and private key in PEM
format. You then enable HTTPS access and specify the SSL certificate to be used for authentication. Finally,
you specify the port as 8443 on which HTTPS access is to be enabled.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, copy and paste the
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

set security certificates local new load-key-file /var/tmp/new.pem

set system services web-management https local-certificate new port 8443

Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions
on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure secure Web access on your device:

1. Import the SSL certificate and private key.

[edit security]
user@host# set certificates local new load-key-file /var/tmp/new.pem

2. Enable HTTPS access and specify the SSL certificate and port.

[edit system]
user@host# set services web-management https local-certificate new port 8443

Results
 313

From configuration mode, confirm your configuration by entering the show security command. If the
output does not display the intended configuration, repeat the configuration instructions in this example
to correct it.

[edit]
user@host# show security
certificates {
local {
new {
"-----BEGIN RSA PRIVATE KEY-----\nMIICXQIBAAKBgQC/C5UI4frNqbi
qPwbTiOkJvqoDw2YgYse0Z5zzVJyErgSg954T\nEuHM67Ck8hAOrCnb0YO+SY
Y5rCXLf4+2s8k9EypLtYRw/Ts66DZoXI4viqE7HSsK\n5sQw/UDBIw7/MJ+OpA ...
KYiFf4CbBBbjlMQJ0HFudW6ISVBslONkzX+FT\ni95ddka6iIRnArEb4VFCRh+
e1QBdp1UjziYf7NuzDx4Z\n -----END RSA PRIVATE KEY-----\n-----BEGIN CERTIFICATE-----
\nMIIDjDCCAvWgAwIBAgIBADANBgkqhkiG9w0BAQQ ...
FADCBkTELMAkGA1UEBhMCdXMx\nCzAJBgNVBAgTAmNhMRIwEAYDVQQHEwlzdW5ue
HB1YnMxDTALBgNVBAMTBGpucHIxJDAiBgkqhkiG\n9w0BCQEWFW5iaGFyZ2F2YUB
fLUYAnBYmsYWOH\n -----END CERTIFICATE-----\n"; ## SECRET-DATA
}
}
}

If you are done configuring the device, enter commit from configuration mode.

Verification

IN THIS SECTION

Verifying an SSL Certificate Configuration | 313

Verifying a Secure Access Configuration | 314

Confirm that the configuration is working properly.

Verifying an SSL Certificate Configuration

Purpose
Verify the SSL certificate configuration.

Action
From operational mode, enter the show security command.
 314

Verifying a Secure Access Configuration

Purpose
Verify the secure access configuration.

Action
From operational mode, enter the show system services command. The following sample output displays
the sample values for secure Web access:

[edit]
user@host# show system services
web-management {
http;
https {
port 8443;
local-certificate new;
}
}

RELATED DOCUMENTATION

Remote Access Overview | 254

Junos OS User Authentication Overview | 172

Example: Controlling Management Access on SRX

Series Devices

IN THIS SECTION

Requirements | 315

Overview | 315

Configuration | 315

Verification | 318
 315

This example shows how to limit the management access to the specific IP addresses on an SRX Series
devices to manage the device.

Requirements

No special configuration beyond device initialization is required before configuring this feature.

Overview

To limit the IP addresses that can manage a device, you can configure a firewall filter. This firewall filters
must include a term to deny all traffic except the IP address that you allow to manage the device. You
must apply the firewall filter to the loopback interface (lo0) as this ensures that only management traffic
(traffic to the device) is filtered.

In this example you:

• Configure a prefix-list called manager-ip. This list defines a set of IP addresses that are allowed to manage
the SRX Series device.

• Configure a firewall filter FILTER1 that rejects all requesters except IP addresses available in the
manager-ip prefix list. In this way, you are ensuring that IP address list specified in the prefix list can
manage the device.

• Apply FILTER1 filter to the loopback interface. Any time a packet hits any of the interfaces on the device,
the loopback interface applies the filter FILTER1 .

Configuration

Configuring an IP Address List to Restrict Management Access to a Device

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, copy and paste the
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

set policy-options prefix-list manager-ip 192.168.4.254/32

set policy-options prefix-list manager-ip 10.0.0.0/8
set firewall filter FILTER1 term block_non_manager from source-address 0.0.0.0/0
 316

set firewall filter FILTER1 term block_non_manager from source-prefix-list manager-ip except
set firewall filter FILTER1 term block_non_manager from protocol tcp
set firewall filter FILTER1 term block_non_manager from destination-port ssh
set firewall filter FILTER1 term block_non_manager from destination-port https
set firewall filter FILTER1 term block_non_manager from destination-port telnet
set firewall filter FILTER1 term block_non_manager from destination-port http
set firewall filter FILTER1 term block_non_manager then discard
set firewall filter FILTER1 term accept_everything_else then accept
set interfaces lo0 unit 0 family inet filter input FILTER1

Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions
on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

1. Define a set of allowed host addresses in the prefix list.

[edit policy-options]
user@host# set prefix-list manager-ip 192.168.4.254/32
user@host# set prefix-list manager-ip 10.0.0.0/8

NOTE: The configured list is referenced in the actual filter, where you can change your
defined set of addresses.

2. Configure a firewall filter to deny traffic from all IP addresses except the IP addresses defined in the
prefix list.

[edit firewall filter]

user@host# set manager-ip term block_non_manager from source-address 0.0.0.0/0
user@host# set manager-ip term block_non_manager from source-prefix-list manager-ip except
user@host# set manager-ip term block_non_manager from protocol tcp
user@host# set manager-ip term block_non_manager from destination-port ssh
user@host# set manager-ip term block_non_manager from destination-port https
user@host# set manager-ip term block_non_manager from destination-port telnet
user@host# set manager-ip term block_non_manager from destination-port http
user@host# set manager-ip term block_non_manager then discard

Management traffic that uses any of the listed destination ports is rejected when the traffic comes
from an address in the list.

3. Configure a default term that accepts all other traffic.

 317

[edit firewall filter]

user@host# set manager-ip term accept_everything_else then accept

4. Apply stateless firewall filters to the loopback interface to filter the packets originating from the hosts
to which you are granting management access.

[edit interfaces lo0 unit 0 ]

user@host# set family inet filter input manager-ip

This configuration applies to traffic terminating at the device itself. If you have IPsec traffic, or OSPF,
RIP, BGP, or any other traffic that terminates at the interface of the device, then you must add the IP
address of the interface to the prefix list.

Results
From configuration mode, confirm your configuration by entering show configuration command. If the
output does not display the intended configuration, repeat the configuration instructions in this example
to correct it.

user@host# show configuration policy-options

prefix-list manager-ip {
10.0.0.0/8;
192.168.4.254/32;
}

user@host# show configuration firewall

filter FILTER1 {
term block_non_manager {
from {
source-address {
0.0.0.0/0;
}
source-prefix-list {
manager-ip except;
}
protocol tcp;
destination-port [ ssh https telnet http ];
}
then {
discard;
}
}
 318

term accept_everything_else {
then accept;
}
}

user@host# show configuration interfaces

lo0 {
unit 0 {
family inet {
filter {
input FILTER1;
}
}
}
}

user@host# show configuration interfaces lo0

unit 0 {
family inet {
filter {
input FILTER1;
}
}
}

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying Interfaces

Purpose
Verify if the interfaces are configured correctly.

Action
From operational mode, enter the following commands:

• show policy-options
 319

• show firewall

• show interfaces

RELATED DOCUMENTATION

Configuration Guidelines for Securing Console Port Access | 319

Configuration Guidelines for Securing Console Port

Access

IN THIS SECTION

Securing Console Port | 319

Securing Mini-USB Ports | 321

We recommend disabling the console port to prevent unauthorized access to the device.

Securing Console Port

You can use the console port on the device to connect to the device through an RJ-45 serial cable. From
the console port, you can use the CLI to configure the device. By default, the console port is enabled. To
secure the console port, you can configure the device to take the following actions:

• Log out of the console session when you unplug the serial cable connected to the console port.

• Disable root login connections to the console. This action prevents a non-root user from performing
password recovery operation using the console.

• Disable the console port. We recommend disabling the console port to prevent unauthorized access to
the device, especially when the device is used as customer premises equipment (CPE) and is forwarding
sensitive traffic.
 320

NOTE: It is not always possible to disable the console port, because console access is important
during operations such as software upgrades.

WARNING: On SRX SRX300, SRX320, SRX340, and SRX345 devices, if both set
system ports console insecure and set chassis routing-engine bios uninterrupt
options are configured, there is no alternative recovery method available incase
Junos OS fails to boot and the device might become unusable.

To secure the console port:

1. Do one of the following:

• Disable the console port. Enter

[edit system ports console]

user@host# set disable

• Disable root login connections to the console. Enter

[edit system ports console]

user@host# set insecure

NOTE: After configuring the console port as insecure, if a user tries to perform password
recovery operation by booting in single-user mode, the device will prompt for the root
password. This way, the user will be unable to log in to single-user mode for password
recovery unless the root password is known.

• Log out the console session when the serial cable connected to the console port is unplugged. Enter

[edit system ports console]

user@host# set log-out-on-disconnect

NOTE: The log-out-on-disconnect statement is not operational on SRX1500, SRX4100,

SRX4200, and SRX4600 devices; on these devices, you must manually log out from the
console with the request system logout command.
 321

2. If you are done configuring the device, enter commit from configuration mode.

Securing Mini-USB Ports

SRX320, SRX320, SRX340, and SRX345 devices have a mini-USB Type-B port. You can connect your
management device to the Mini-USB Type-B console port for CLI management.

You can disable mini-USB ports on the SRX Series devices to block users from connecting a USB mass
storage device to the services gateway. When you disable the device, any transactions in progress on the
USB device are aborted.

Disable mini-USB ports.

• Use the following command to disable the mini-USB ports.

[edit]
user@host# set chassis usb storage disable

Enable mini-USB ports.

• Use the following command to enable the mini-USB ports.

[edit]
user@host# delete chassis usb storage disable

This step re-enables the disabled mini-USB ports.

Verify the status of the mini-USB.

• Use the following show command to verify the status.

user@host> show chassis usb storage

The output displays the current status of USB mass storage device and whether the USB ports are
enabled or disabled.

USB Enabled
 322

RELATED DOCUMENTATION

Console Port Overview

Configuring the Console Port Type (CLI Procedure)

Some devices have two console ports: an RJ-45 console port and a Mini-USB Type-B console port. You
can configure and manage the device using either port. To connect to the device using a passive port, you
must first configure the port as active and then reboot the device.

When a console port is active, it can display all the early boot and low-level message output. You can
access the device through this port in the debugger prompt. On some devices, only one console port is
active at a time and the console input is active only on that port. Check the hardware guide for your
particular device for whether both ports can be active at the same time.

The RJ-45 console port is the active port by default. To activate the Mini-USB Type-B console port:

1. Connect the host machine to the device directly using the active console port or remotely using the
management interface. To connect using the active console port, which is the RJ-45 console port by
default, see Connecting a Device to a Management Console Using an RJ-45 Connector.

2. Connect to your device using the Mini-USB Type-B console port. See the hardware guide for your
particular device for how to connect to the port.

3. Configure the port type as mini-usb:

[edit]
user@switch# set system ports auxiliary port-type mini-usb

4. Commit the configuration and Exit. The initial logs will show the Mini-USB Type-B console port as
active.

5. Reboot the switch. The boot log appears on the activated console. If your device supports both ports
being active at the same time, both ports are now active and can be used as console ports.

NOTE: Do not use the delete system ports auxiliary port-type command to delete the port-type
configuration. Always use the set system ports auxiliary port-type type command to change the
active management console port type.
 323

To configure the RJ-45 console port as the active port, use the same procedure with the set system ports
auxiliary port-type rj45 command.

RELATED DOCUMENTATION

Connecting a Device to a Management Console Using an RJ-45 Connector

Connecting an EX Series Switch to a Management Console Using the Mini-USB Type-B Console Port
Connecting an MX150 to a Management Console Using Mini-USB Type-B Console Port
Connecting an NFX250 Device to a Management Console Using Mini-USB Type-B Console Port
Connecting an OCX1100 Switch to a Management Console by Using the Mini-USB Type-B Console Port
6 CHAPTER

Access Control on Switches

Access Control and Authentication on Switching Devices | 326

Preventing Unauthorized Access to EX Series Switches Using Unattended Mode for

U-Boot | 338

RADIUS Server Configuration for Authentication | 343

802.1X Authentication | 351

MAC RADIUS Authentication | 390

802.1X and RADIUS Accounting | 399

Example: Setting Up 802.1X for Single-Supplicant or Multiple-Supplicant

Configurations on an EX Series Switch | 405

Example: Setting Up 802.1X in Conference Rooms to Provide Internet Access to

Corporate Visitors on an EX Series Switch | 413

Interfaces Enabled for 802.1X or MAC RADIUS Authentication | 420

Static MAC Bypass of 802.1X and MAC RADIUS Authentication | 441

Captive Portal Authentication | 449

Flexible Authentication Order on EX Series Switches | 469

Central Web Authentication | 474

Centralized Access Control to Network Resources on EX Series Switches | 481

VoIP on EX Series Switches | 489

 326

Access Control and Authentication on Switching

Devices

IN THIS SECTION

Understanding Authentication on Switches | 326

Understanding Access Control on Switches | 333

Understanding Authentication Session Timeout | 335

Controlling Authentication Session Timeouts (CLI Procedure) | 336

You can control access to your network through a switch by using several different authentication. Junos
OS switches support 802.1X, MAC RADIUS, and captive portal as an authentication methods to devices
requiring to connect to a network. Read this topic for more information.

Understanding Authentication on Switches

IN THIS SECTION

Sample Authentication Topology | 327

802.1X Authentication | 329

MAC RADIUS Authentication | 330

Captive Portal Authentication | 331

Static MAC Bypass of Authentication | 331

Fallback of Authentication Methods | 332

 327

You can control access to your network through a Juniper Networks EX Series Ethernet Switch by using
authentication methods such as 802.1X, MAC RADIUS, or captive portal. Authentication prevents
unauthenticated devices and users from gaining access to your LAN. For 802.1X and MAC RADIUS
authentication, end devices must be authenticated before they receive an IP address from a Dynamic Host
Configuration Protocol (DHCP) server. For captive portal authentication, the switch allows the end devices
to acquire an IP address in order to redirect them to a login page for authentication.

This topic covers:

Sample Authentication Topology

Figure 5 on page 328 illustrates a basic deployment topology for authentication on an EX Series switch:

NOTE: For illustration purposes, we have used an EX Series switch, but a QFX5100 switch can
be used in the same way.
 328

Figure 5: Example Authentication Topology

The topology contains an EX Series access switch connected to the authentication server on port ge-0/0/10.
Interface ge-0/0/1 connects to the conference room host. Interface ge-0/0/8 is connected to four desktop
PCs through a hub. Interfaces ge-0/0/9 and ge-0/0/2 are connected to IP phones with an integrated hub
 329

to connect the phone and desktop PC to a single port. Interfaces ge-0/0/19 and ge-0/0/20 are connected
to printers.

802.1X Authentication

802.1X is an IEEE standard for port-based network access control (PNAC). It provides an authentication
mechanism for devices seeking to access a LAN. The 802.1X authentication feature on an EX Series switch
is based upon the IEEE 802.1X standard Port-Based Network Access Control.

The communication protocol between the end device and the switch is Extensible Authentication Protocol
over LAN (EAPoL). EAPoL is a version of EAP designed to work with Ethernet networks. The communication
protocol between the authentication server and the switch is RADIUS.

During the authentication process, the switch completes multiple message exchanges between the end
device and the authentication server. While 802.1X authentication is in process, only 802.1X traffic and
control traffic can transit the network. Other traffic, such as DHCP traffic and HTTP traffic, is blocked at
the data link layer.

NOTE: You can configure both the maximum number of times an EAPoL request packet is
retransmitted and the timeout period between attempts. For information, see “Configuring
802.1X Interface Settings (CLI Procedure)” on page 355.

An 802.1X authentication configuration for a LAN contains three basic components:

• Supplicant (also called end device)—Supplicant is the IEEE term for an end device that requests to join
the network. The end device can be responsive or nonresponsive. A responsive end device is
802.1X-enabled and provides authentication credentials using EAP. The credentials required depend on
the version of EAP being used—specifically, a username and password for EAP MD5 or a username and
client certificates for Extensible Authentication Protocol-Transport Layer Security (EAP-TLS),
EAP-Tunneled Transport Layer Security (EAP-TTLS), and Protected EAP (PEAP).

You can configure a server-reject VLAN to provide limited LAN access for responsive 802.1X-enabled
end devices that sent incorrect credentials. A server-reject VLAN can provide a remedial connection,
typically only to the Internet, for these devices. See “Example: Configuring Fallback Options on EX Series
Switches for EAP-TTLS Authentication and Odyssey Access Clients” on page 379 for additional information.

NOTE: If the end device that is authenticated using the server-reject VLAN is an IP phone,
voice traffic is dropped.

A nonresponsive end device is one that is not 802.1X-enabled. It can be authenticated through MAC
RADIUS authentication.
 330

• Authenticator port access entity—The IEEE term for the authenticator. The switch is the authenticator,
and it controls access by blocking all traffic to and from end devices until they are authenticated.

• Authentication server—The authentication server contains the backend database that makes authentication
decisions. It contains credential information for each end device that is authenticated to connect to the
network. The authenticator forwards credentials supplied by the end device to the authentication server.
If the credentials forwarded by the authenticator match the credentials in the authentication server
database, access is granted. If the credentials forwarded do not match, access is denied. The EX Series
switches support RADIUS authentication servers.

NOTE: You cannot configure 802.1X authentication on redundant trunk groups (RTGs). For
more information about RTGs, see Understanding Redundant Trunk Links (Legacy RTG Configuration).

MAC RADIUS Authentication

The 802.1X authentication method only works if the end device is 802.1X-enabled, but many single-purpose
network devices such as printers and IP phones do not support the 802.1X protocol. You can configure
MAC RADIUS authentication on interfaces that are connected to network devices that do not support
802.1X and for which you want to allow to access the LAN. When an end device that is not 802.1X-enabled
is detected on the interface, the switch transmits the MAC address of the device to the authentication
server. The server then tries to match the MAC address with a list of MAC addresses in its database. If
the MAC address matches an address in the list, the end device is authenticated.

You can configure both 802.1X and MAC RADIUS authentication methods on the interface. In this case,
the switch first attempts to authenticate the end device by using 802.1X, and if that method fails, it attempts
to authenticate the end device by using MAC RADIUS authentication. If you know that only non-responsive
supplicants connect on that interface, you can eliminate the delay that occurs for the switch to determine
that the end device is not 802.1X-enabled by configuring the mac-radius restrict option. When this option
is configured, the switch does not attempt to authenticate the end device through 802.1X authentication
but instead immediately sends a request to the RADIUS server for authentication of the MAC address of
the end device. If the MAC address of that end device is configured as a valid MAC address on the RADIUS
server, the switch opens LAN access to the end device on the interface to which it is connected.

The mac-radius-restrict option is useful when no other 802.1X authentication methods, such as guest
VLAN, are needed on the interface. If you configure mac-radius-restrict on an interface, the switch drops
all 802.1X packets.

The authentication protocols supported for MAC RADIUS authentication are EAP-MD5, which is the
default, Protected EAP (EAP-PEAP), and Password Authentication Protocol (PAP). You can specify the
authentication protocol to be used for MAC RADIUS authentication using the authentication-protocol
statement.
 331

Captive Portal Authentication

Captive portal authentication (hereafter referred to as captive portal) enables you to authenticate users
on EX Series switches by redirecting Web browser requests to a login page that requires users to input a
valid username and password before they can access the network. Captive portal controls network access
by requiring users to provide information that is authenticated against a RADIUS server database by using
EAP-MD5. You can also use captive portal to display an acceptable-use policy to users before they access
your network.

Juniper Networks Junos operating system (Junos OS) for EX Series switches provides a template that
enables you to easily design and modify the look of the captive portal login page. You enable specific
interfaces for captive portal. The first time an end device connected to a captive portal interface attempts
to access a webpage, the switch presents the captive portal login page. After the device is successfully
authenticated, it is allowed access to the network and to continue to the original page requested.

NOTE: If HTTPS is enabled, HTTP requests are redirected to an HTTPS connection for the
captive portal authentication process. After authentication, the end device is returned to the
HTTP connection.

If there are end devices that are not HTTP-enabled connected to the captive portal interface, you can
allow them to bypass captive portal authentication by adding their MAC addresses to an authentication
whitelist.

When a user is authenticated by the RADIUS server, any per-user policies (attributes) associated with that
user are also sent to the switch.

Captive portal on switches has the following limitations:

• Captive portal does not support dynamic assignment of VLANs downloaded from the RADIUS server.

• If the user remains idle for more than about 5 minutes and there is no traffic passed, the user must log
back in to the captive portal.

Static MAC Bypass of Authentication

You can allow end devices to access the LAN without authentication on a RADIUS server by including
their MAC addresses in the static MAC bypass list (also known as the exclusion list).

You might choose to include a device in the bypass list to:

• Allow non-802.1X-enabled devices access to the LAN.

• Eliminate the delay that occurs for the switch to determine that a connected device is a
non-802.1X-enabled host.
 332

When you configure static MAC on the switch, the MAC address of the end device is first checked in a
local database (a user-configured list of MAC addresses). If a match is found, the end device is successfully
authenticated and the interface is opened up for it. No further authentication is done for that end device.
If a match is not found and 802.1X authentication is enabled on the switch, the switch attempts to
authenticate the end device through the RADIUS server.

For each MAC address, you can also configure the VLAN to which the end device is moved or the interfaces
on which the host connects.

CAUTION: When you clear the learned MAC addresses from an interface, using the
clear dot1x interface command, all MAC addresses are cleared, including those in the
static MAC bypass list.

Fallback of Authentication Methods

You can configure 802.1X, MAC RADIUS, and captive portal authentication on a single interface to enable
fallback to another method if authentication by one method fails. The authentication methods can be
configured in any combination, except that you cannot configure both MAC RADIUS and captive portal
on an interface without also configuring 802.1X. By default, an EX Series switch uses the following order
of authentication methods:

1. 802.1X authentication—If 802.1X is configured on the interface, the switch sends EAPoL requests to
the end device and attempts to authenticate the end device through 802.1X authentication. If the end
device does not respond to the EAP requests, the switch checks whether MAC RADIUS authentication
is configured on the interface.

2. MAC RADIUS authentication—If MAC RADIUS authentication is configured on the interface, the switch
sends the MAC RADIUS address of the end device to the authentication server. If MAC RADIUS
authentication is not configured, the switch checks whether captive portal is configured on the interface.

3. Captive portal authentication—If captive portal is configured on the interface, the switch attempts to
authenticate the end device by using this method after the other authentication methods configured
on the interface have failed.

For an illustration of the default process flow when multiple authentication methods are configured on an
interface, see “Understanding Access Control on Switches” on page 333.

You can override the default order for fallback of authentication methods by configuring the
authentication-order statement to specify that the switch use either 802.1X authentication or MAC
RADIUS authentication first. Captive portal must always be last in the order of authentication methods.
For more information, see “Configuring Flexible Authentication Order” on page 470.
 333

NOTE: Starting with Junos OS Release 15.1R3, if an interface is configured in multiple-supplicant

mode, end devices connecting through the interface can be authenticated using different methods
in parallel. Therefore, if an end device on the interface was authenticated after fall back to captive
portal, then additional end devices can still be authenticated using 802.1X or MAC RADIUS
authentication.

SEE ALSO

802.1X for Switches Overview | 352

Example: Setting Up 802.1X for Single-Supplicant or Multiple-Supplicant Configurations on an EX
Series Switch | 405
Configuring 802.1X Interface Settings (CLI Procedure) | 355
Configuring MAC RADIUS Authentication (CLI Procedure) | 391
Configuring Captive Portal Authentication (CLI Procedure) | 456
Configuring Static MAC Bypass of 802.1X and MAC RADIUS Authentication (CLI Procedure) | 442

Understanding Access Control on Switches

You can control access to your network through a switch by using several different authentication
methods—including 802.1X, MAC RADIUS, or captive portal.

Figure 6 on page 334 illustrates the authentication process:

 334

Figure 6: Authentication Process Flow for Switches

Begin
Authentication

MAC
address in A Client authenticated.
whitelist or static YES A Allow access on port.
MAC list? B Client is not authenticated.
Deny access on port.
C Captive portal.
NO
D Reauthentication.
E Client authenticated. Allow access
only to specified VLAN on port.

Authenticator
D
configured? Try authenticating
NO using EAPOL—
maximum 3 requests

YES
mac-radius C
restrict statement
configured?

Does client
MAC RADIUS Captive portal Guest VLAN
YES respond to EAP NO NO NO
configured? configured? configured?
message?

Try authenticating
using
MAC RADIUS YES YES YES
YES NO

Continue with Try once to Continue with A B

NO 802.1X authenticate using captive portal
authentication MAC RADIUS

Go to C
Does
RADIUS server NO
respond?

Does
Server-reject YES Server-fail
RADIUS server
VLAN NO VLAN NO B
return access-
configured? configured?
accept?
Does
RADIUS server NO
YES NO YES YES respond?

E B A A
YES

Does
RADIUS server
NO B
return access-
YES accept?
g041098

SEE ALSO

Understanding Server Fail Fallback and Authentication on Switches | 348

Understanding Guest VLANs for 802.1X on Switches | 372
Understanding Dynamic VLAN Assignment Using RADIUS Attributes | 371
Example: Setting Up Captive Portal Authentication on an EX Series Switch | 449
 335

Understanding Authentication Session Timeout

Information about authentication sessions—including the associated interfaces and VLANs for each MAC
address that is authenticated—is stored in the authentication session table. The authentication session
table is tied to the Ethernet switching table (also called the MAC table). Each time the switch detects traffic
from a MAC address, it updates the timestamp for that network node in the Ethernet switching table. A
timer on the switch periodically checks the timestamp and if its value exceeds the user-configured
mac-table-aging-time value, the MAC address is removed from the Ethernet switching table. When a MAC
address ages out of the Ethernet switching table, the entry for that MAC address is also removed from
the authentication session table, with the result that the session ends.

When the authentication session ends due to MAC address aging, the host must re-attempt authentication.
To limit the downtime resulting from re-authentication, you can control the timeout of authentication
sessions in the following ways:

• For 802.1X and MAC RADIUS authentication sessions, disassociate the authentication session table
from the Ethernet switching table by using the no-mac-table-binding statement. This setting prevents
the termination of the authentication session when the associated MAC address ages out of the Ethernet
switching table.

• For captive portal authentication sessions, configure a keep-alive timer using the user-keepalive statement.
With this option configured, when the associated MAC address ages out of the Ethernet switching table,
the keep-alive timer is started. If traffic is received within the keep-alive timeout period, the timer is
deleted. If there is no traffic within the keep-alive timeout period, the session is deleted.

You can also specify timeout values for authentication sessions to end the session before the MAC aging
timer expires. After the session times out, the host must re-attempt authentication.

• For 802.1X and MAC RADIUS authentication sessions, the duration of the session before timeout
depends on the value of the reauthentication statement. If the MAC aging timer expires before the
session times out, and the no-mac-table-binding statement is not configured, the session is ended, and
the host must re-authenticate.

• For captive portal authentication sessions, the duration of the session depends on the value configured
for the session-expiry statement. If the MAC aging timer expires before the session times out, and the
user-keepalive statement is not configured, the session is ended, and the host must re-authenticate.

NOTE: If the authentication server sends an authentication session timeout to the client, this
takes priority over the value configured locally using either the reauthentication statement or
the session-expiry statement. The session timeout value is sent from the server to the client as
an attribute of the RADIUS Access-Accept message. For information about configuring the
authentication server to send an authentication session timeout, see the documentation for your
server.
 336

SEE ALSO

Example: Setting Up 802.1X for Single-Supplicant or Multiple-Supplicant Configurations on an EX

Series Switch | 405
Configuring MAC Table Aging on Switches

Controlling Authentication Session Timeouts (CLI Procedure)

The expiration of an authentication session can result in downtime because the host must re-attempt
authentication. You can limit this downtime by controlling the timeout period for authentication sessions.

An authentication session can end when the MAC address associated with the authenticated host ages
out of the Ethernet switching table. When the MAC address is cleared from the Ethernet switching table,
the authenticated session for that host ends, and the host must re-attempt authentication.

To prevent the authentication session from ending when the MAC address ages out of the Ethernet
switching table:

• For sessions authenticated using 802.1X or MAC RADIUS authentication, you can prevent authentication
session timeouts due to MAC address aging by disassociating the authentication session table from
the Ethernet switching table using the no-mac-table-binding statement:

[edit]
user@switch# set protocols dot1x authenticator no-mac-table-binding;

• For sessions authenticated using captive portal authentication, you can prevent authentication session
timeouts due to MAC address aging by extending the timeout period using the user-keepalive statement:

[edit]
user@switch# set services captive-portal interface interface-name user-keepalive minutes;

You can also configure timeout values for authentication sessions to end an authenticated session before
the MAC aging timer expires.

NOTE: Configuring the session timeout for an authentication session does not extend the session
after the MAC aging timer expires. You must configure either the no-mac-table-binding statement
for 802.1X and MAC RADIUS authentication, or the user-keepalive statement for captive portal
authentication, to prevent session timeout due to MAC aging.
 337

For 802.1X and MAC RADIUS authentication sessions, configure the timeout value using the
reauthentication statement.

• To configure the timeout value on a single interface:

[edit]
user@switch# set protocols dot1x authenticator interface interface-name reauthentication seconds;

• To configure the timeout value on all interfaces:

[edit]
user@switch# set protocols dot1x authenticator interface all reauthentication seconds;

For captive portal authentication sessions, configure the timeout value using the session-expiry statement.

• To configure the timeout value on a single interface:

[edit]
user@switch# set services captive-portal interface interface-name session-expiry minutes;

• To configure the timeout value on all interfaces:

[edit]
user@switch# set services captive-portal interface all session-expiry minutes;

NOTE: If the authentication server sends an authentication session timeout to the client, this
takes priority over the value configured using the reauthentication statement or the session-expiry
statement. The session timeout value is sent from the server to the client as an attribute of the
RADIUS Access-Accept message.

SEE ALSO

Configuring MAC Table Aging on Switches

Example: Setting Up 802.1X for Single-Supplicant or Multiple-Supplicant Configurations on an EX
Series Switch | 405

RELATED DOCUMENTATION

802.1X Authentication | 351

 338

802.1X and RADIUS Accounting | 399

MAC RADIUS Authentication | 390

Preventing Unauthorized Access to EX Series Switches

Using Unattended Mode for U-Boot

IN THIS SECTION

Understanding Unattended Mode for U-Boot on EX Series Switches | 338

Using Unattended Mode for U-Boot to Prevent Unauthorized Access | 340

Junos OS allows you to configure anattended mode for U-Boot to prevent unauthorized access to the
switch during the boot process. When you configure unattended mode, an user can access the CLI during
the boot process by supplying the boot-loader password. This prevents unauthorized access during boot
process. Read this topic for more information.

Understanding Unattended Mode for U-Boot on EX Series Switches

Unattended mode for U-Boot can be configured to prevent unauthorized access to the switch that can
occur during the boot process. After the CPU has been reset, there are several known methods of accessing
the system before the JUNOS OS login prompt appears that do not require the user to enter authorization
credentials. By gaining unauthorized access, the user can view, modify, or corrupt the switch configuration,
or make the switch unavailable on the network.

When unattended mode is configured, the user can access the CLI during the boot process only by pressing
<Ctrl+c> and entering the correct password, which is known as the boot-loader password. The boot-loader
password must have been previously configured on the switch. Entering the correct boot-loader password
will place the user in the U-Boot CLI. If the password is incorrect, or if no password is entered within one
minute, access to the U-Boot CLI is blocked and the boot process continues automatically.

Access to the bootstrap loader command prompt (loader>) is blocked in unattended mode, which prevents
the use of the following recovery mechanisms: root password recovery by using single-user mode, and
booting the switch by using a software package stored on a USB flash drive.
 339

NOTE: If the root password is lost while the switch is in unattended mode, the switch must be
reset to the factory default configuration using the LCD panel. For more information see Reverting
to the Default Factory Configuration for the EX Series Switch.

If unattended mode is not configured, but a boot-loader password has been configured, the user must
enter the correct password to access the U-Boot CLI. If a boot-loader password has not been configured,
the user can access the U-Boot CLI without entering a password. In either case, the user can access the
bootstrap loader command prompt, which enables root password recovery by using single-user mode as
well as booting from a USB flash drive.

Unattended mode is not enabled by default. When configured, unattended mode is turned on and will
block unauthorized access to the switch. Table 22 on page 339 summarizes the behaviors for U-Boot mode.

Table 22: Unattended Mode Behavior

Boot-loader
Unattended Mode password Behavior

On Set • Access to U-Boot CLI is allowed only after entering correct password.
• Access to loader command prompt is blocked.
• Booting from USB is blocked.
• Root password recovery by using single-user mode is blocked.

On Not Set • Access to U-Boot CLI is blocked.

• Access to loader command prompt is blocked.
• Booting from USB is blocked.
• Root password recovery by using single-user mode is blocked.

Off Set • Access to U-Boot CLI is allowed only after entering correct password.
• Access to loader command prompt is allowed.
• Booting from USB is allowed.
• Root password recovery by using single-user mode is allowed.

Off Not Set • Access to U-Boot CLI is allowed.

• Access to loader command prompt is allowed.
• Booting from USB is allowed.
• Root password recovery by using single-user mode is allowed.

SEE ALSO
 340

Root Password | 142

Using Unattended Mode for U-Boot to Prevent Unauthorized Access

IN THIS SECTION

Configuring the Boot Loader Password | 341

Configuring Unattended Mode for U-Boot | 342

Accessing the U-Boot CLI | 342

Unattended mode for U-Boot can be used to prevent unauthorized access to the switch that can occur
during the boot process. When unattended mode is configured, the user can access the CLI during the
boot process only by entering the correct password, which is known as the boot-loader password. The
boot-loader password must have been previously configured on the switch.

When unattended mode is configured, access to the bootstrap loader command prompt (loader>) is blocked,
which prevents the use of the following recovery mechanisms: root password recovery by using single-user
mode, and booting the switch by using a software package stored on a USB flash drive.

WARNING: On EX2200 switches, if both the root and unattended mode password
are lost while the switch is in unattended mode, there is no alternative recovery method
available. The switch must be returned to Juniper Networks. For more information,
see Returning an EX2200 Switch or Component for Repair or Replacement.

To use unattended mode, follow the following procedures:

 341

Configuring the Boot Loader Password

To configure the boot loader password, you can use either a plain-text password that the system encrypts
for you, or a password that has already been encrypted. If you use a plain-text password, Junos OS displays
the password as an encrypted string so that users viewing the configuration cannot see it. As you enter
the password in plain text, Junos OS encrypts it immediately. You do not have to configure Junos OS to
encrypt the password. Plain-text passwords are hidden and marked as ## SECRET-DATA in the
configuration.

To configure the boot-loader password:

1. Enter either a plain-text password or an encrypted password by using the set system boot-loader
authentication command.

• To enter a plain-text password, use the plain-text-password option, and re-enter the password when
prompted:

[edit]
root@# set system boot-loader-authentication plain-text-password
New Password: type password here
Retype new password: retype password here

• To enter a password that is already encrypted, use the encrypted-password option:

[edit]
root@# set system boot-loader-authentication encrypted-password password

2. Commit the changes.

[edit]
root@# commit

3. To view the encrypted password entries, use the configuration mode show command. For example:

[edit]
root@# show system boot-loader-authentication
encrypted-password “$ABC123”; ## SECRET-DATA
 342

Configuring Unattended Mode for U-Boot

Before enabling unattended mode for U-Boot, you must download and install the jloader firmware package
/volume/build/junos/13.2/service/13.2X51-D20.2/ship/jloader-ex-2200-13.2X51-D20.2-signed.tgz,
as described in TSB16425.

Unattended mode for U-Boot is not enabled by default. Use the following procedure to configure unattended
mode:

1. Configure unattended mode.

[edit]
root@# set system unattended-boot

2. Commit the changes.

[edit]
root@# commit

Accessing the U-Boot CLI

When unattended mode for U-Boot is configured and the boot-loader password has been set, you can
access the U-Boot CLI during the boot process by pressing <Ctrl+c> and entering the password at the
prompt:

Press Ctrl-C in next 1 seconds to enter u-boot prompt...

Enter password:
password correct...
=>

The correct password must be entered within one minute after the prompt appears. If the password is not
entered within one minute, or if the password is incorrect or has not been configured, access to the U-Boot
CLI will be blocked, and the boot process will continue. For more information about unattended mode
behavior, see “Understanding Unattended Mode for U-Boot on EX Series Switches” on page 338.

SEE ALSO

unattended-boot | 1324
boot-loader-authentication | 1073
 343

RELATED DOCUMENTATION

Access Control and Authentication on Switching Devices | 326

RADIUS Server Configuration for Authentication

IN THIS SECTION

Specifying RADIUS Server Connections on Switches (CLI Procedure) | 344

Configuring MS-CHAPv2 to Provide Password-Change Support (CLI Procedure) | 345

Configuring MS-CHAPv2 for Password-Change Support | 346

Understanding Server Fail Fallback and Authentication on Switches | 348

Configuring RADIUS Server Fail Fallback (CLI Procedure) | 349

Juniper Networks Ethernet Switches use 802.1X, MAC RADIUS, or captive portal authentication to provide
access control to the devices or users. When 802.1X, MAC RADIUS, or captive portal authentications are
configured on the switch, end devices are evaluated at the initial connection by an authentication (RADIUS)
server. To use 802.1X or MAC RADIUS authentication, you must specify the connections on the switch
for each RADIUS server to which you want to connect. Read this topic for more information.
 344

Specifying RADIUS Server Connections on Switches (CLI Procedure)

IEEE 802.1X and MAC RADIUS authentication both provide network edge security, protecting Ethernet
LANs from unauthorized user access by blocking all traffic to and from devices at the interface until the
supplicant's credentials or MAC address are presented and matched on the authentication server (a RADIUS
server). When the supplicant is authenticated, the switch stops blocking access and opens the interface
to the supplicant.

To use 802.1X or MAC RADIUS authentication, you must specify the connections on the switch for each
RADIUS server to which you will connect.

To configure a RADIUS server on the switch:

1. Define the IP address of the RADIUS server, the RADIUS server authentication port number, and the
secret password. You can define more than one RADIUS server. The secret password on the switch
must match the secret password on the server:

[edit access]
user@switch# set radius-server server-address port 1812 secret password

NOTE: Specifying the authentication port is optional, and port 1812 is the default. However,
we recommend that you configure it in order to avoid confusion as some RADIUS servers
might refer to an older default.

2. (Optional) Specify the IP address by which the switch is identified by the RADIUS server. If you do not
specify the IP address, the RADIUS server uses the address of the interface that sends the RADIUS
request. We recommend that you specify this IP address because if the request gets diverted on an
alternate route to the RADIUS server, the interface relaying the request might not be an interface on
the switch.

[edit access]
user@switch# set access radius-server source-address source-address

3. Configure the authentication order, making radius the first method of authentication:

[edit access]
user@switch# set profile profile-name authentication-order (Access Profile) radius

4. Create a profile and specify the list of RADIUS servers to be associated with the profile. For example,
you might choose to group your RADIUS servers geographically by city. This feature enables easy
modification whenever you want to change to a different sent of authentication servers.
 345

[edit access profile profile-name]

user@switch# set radius authentication-server server-address server-address

5. Specify the group of servers to be used for 802.1X or MAC RADIUS authentication by identifying the
profile name:

[edit]
user@switch# set protocols dot1x authenticator authentication-profile-name access-profile-name

6. Configure the IP address of the switch in the list of clients on the RADIUS server. For information about
configuring the RADIUS server, consult the documentation for your server.

SEE ALSO

Configuring 802.1X Interface Settings (CLI Procedure) | 355

Configuring 802.1X Authentication (J-Web Procedure)
Configuring MAC RADIUS Authentication (CLI Procedure) | 391
Configuring 802.1X RADIUS Accounting (CLI Procedure) | 403

Configuring MS-CHAPv2 to Provide Password-Change Support (CLI

Procedure)

Junos OS for EX Series switches enables you to configure the Microsoft Corporation implementation of
the Challenge Handshake Authentication Protocol version 2 (MS-CHAPv2) on the switch to provide
password-change support. Configuring MS-CHAPv2 on the switch provides users accessing a switch the
option of changing the password when the password expires, is reset, or is configured to be changed at
next login.

See RFC 2433, Microsoft PPP CHAP Extensions, for information about MS-CHAP.

Before you configure MS-CHAPv2 to provide password-change support, ensure that you have:
 346

• Configured RADIUS server authentication. Configure users on the authentication server and set the
first-tried option in the authentication order to radius. See “Example: Connecting a RADIUS Server for
802.1X to an EX Series Switch” on page 365.

To configure MS-CHAPv2, specify the following:

[edit system radius-options]

user@switch# set password-protocol mschap-v2

You must have the required access permission on the switch in order to change your password.

SEE ALSO

Managing Users (J-Web Procedure)

For more about configuring user access, see the Junos OS Access Privilege Configuration Guide.

Configuring MS-CHAPv2 for Password-Change Support

You can configure the Microsoft implementation of the Challenge Handshake Authentication Protocol
version 2 (MS-CHAPv2) on the router or switch to support changing of passwords. This feature provides
users accessing a router or switch the option of changing the password when the password expires, is
reset, or is configured to be changed at next logon.

Before you configure MS-CHAPv2 for password-change support, ensure that you have done the following:

• Configured RADIUS server authentication parameters.

• Set the first tried option in the authentication order to RADIUS server.

To configure MS-CHAP-v2, include the following statements at the [edit system radius-options] hierarchy
level:

[edit system radius-options]

password-protocol mschap-v2;

The following example shows statements for configuring the MS-CHAPv2 password protocol, password
authentication order, and user accounts:

[edit]
system {
 347

authentication-order [ radius password ];

radius-server {
192.168.69.149 secret "$9$G-j.5Qz6tpBk.1hrlXxUjiq5Qn/C"; ## SECRET-DATA
}
radius-options {
password-protocol mschap-v2;
}
login {
user bob {
class operator;
}
}
}

SEE ALSO

Configuring Access Profiles for L2TP or PPP Parameters

 348

Understanding Server Fail Fallback and Authentication on Switches

Juniper Networks Ethernet Switches use authentication to implement access control in an enterprise
network. If 802.1X, MAC RADIUS, or captive portal authentication is configured on the switch, end devices
are evaluated at the initial connection by an authentication (RADIUS) server. If the end device is configured
on the authentication server, the device is granted access to the LAN and the EX Series switch opens the
interface to permit access.

Server fail fallback enables you to specify how end devices connected to the switch are supported if the
RADIUS authentication server becomes unavailable. Server fail fallback is triggered most often during
reauthentication when the already configured and in-use RADIUS server becomes inaccessible. However,
server fail fallback can also be triggered by an end device’s first attempt at authentication through the
RADIUS server.

Server fail fallback enables you to specify one of four actions to be taken for end devices awaiting
authentication when the server is timed out. The switch can accept or deny access to supplicants or
maintain the access already granted to supplicants before the RADIUS timeout occurred. You can also
configure the switch to move the supplicants to a specific VLAN. The VLAN must already be configured
on the switch. The configured VLAN name overrides any attributes sent by the server.

• Permit authentication, allowing traffic to flow from the end device through the interface as if the end
device were successfully authenticated by the RADIUS server.

• Deny authentication, preventing traffic from flowing from the end device through the interface. This is
the default.

• Move the end device to a specified VLAN if the switch receives a RADIUS access-reject message. The
configured VLAN name overrides any attributes sent by the server. (The VLAN must already exist on
the switch.)

• Sustain authenticated end devices that already have LAN access and deny unauthenticated end devices.
If the RADIUS servers time out during reauthentication, previously authenticated end devices are
reauthenticated and new users are denied LAN access.

SEE ALSO

802.1X for Switches Overview | 352

Example: Configuring 802.1X Authentication Options When the RADIUS Server Is Unavailable to an
EX Series Switch | 373
Example: Setting Up 802.1X for Single-Supplicant or Multiple-Supplicant Configurations on an EX
Series Switch | 405
Configuring 802.1X Interface Settings (CLI Procedure) | 355
 349

Configuring RADIUS Server Fail Fallback (CLI Procedure)

You can configure authentication fallback options to specify how end devices connected to a switch are
supported if the RADIUS authentication server becomes unavailable.

When you set up 802.1X or MAC RADIUS authentication on the switch, you specify a primary authentication
server and one or more backup authentication servers. If the primary authentication server cannot be
reached by the switch and the secondary authentication servers are also unreachable, a RADIUS server
timeout occurs. If this happens, because it is the authentication server that grants or denies access to the
end devices awaiting authentication, the switch does not receive access instructions for end devices
attempting access to the LAN, and normal authentication cannot be completed.

You can configure the server fail fallback feature to specify an action that the switch applies to end devices
when the authentication servers are unavailable. The switch can accept or deny access to supplicants or
maintain the access already granted to supplicants before the RADIUS timeout occurred. You can also
configure the switch to move the supplicants to a specific VLAN.

You can also configure the server reject fallback feature for end devices that receive a RADIUS access-reject
message from the authentication server. The server reject fallback feature provides limited access to a
LAN, typically only to the Internet, for responsive end devices that are 802.1X-enabled but that have sent
the wrong credentials.

Server fail fallback is supported for voice traffic starting in Release 14.1X53-D40 and Release 15.1R4. To
configure server fail fallback actions for VoIP clients sending voice traffic, use the server-fail-voip statement.
For all data traffic, use the server-fail statement. The switch determines the fallback method to use based
on the type of traffic sent by the client. Untagged data frames are subject to the action configured with
server-fail, even if they are sent by a VoIP client. Tagged VoIP VLAN frames are subject to the action
configured with server-fail-voip. If server-fail-voip is not configured, the voice traffic is dropped.

NOTE: Server reject fallback is not supported for VoIP VLAN tagged traffic. If a VoIP client starts
authentication by sending untagged data traffic to a VLAN while server reject fallback is in effect,
the VoIP client is allowed to access the fallback VLAN. If the same client subsequently sends
tagged voice traffic, the voice traffic is dropped.

If a VoIP client starts authentication by sending tagged voice traffic while server reject fallback
is in effect, the VoIP client is denied access to the fallback VLAN.
 350

You can use the following procedure to configure server fail actions for data clients. To configure server
fail fallback for VoIP clients sending voice traffic, use the server-fail-voip statement in place of the server-fail
statement.

To configure server fail fallback actions:

• Configure an interface to allow traffic to flow from a supplicant to the LAN if a RADIUS server timeout
occurs (as if the end device had been successfully authenticated by a RADIUS server):

[edit protocols dot1x authenticator]

user@switch# set interface interface-name server-fail permit

• Configure an interface to prevent traffic flow from an end device to the LAN (as if the end device had
failed authentication and had been denied access by the RADIUS server):

[edit protocols dot1x authenticator]

user@switch# set interface interface-name server-fail deny

• Configure an interface to move an end device to a specified VLAN if a RADIUS server timeout occurs:

[edit protocols dot1x authenticator]

user@switch# set interface interface-name server-fail vlan-name

• Configure an interface to recognize already connected end devices as reauthenticated if there is a

RADIUS timeout during reauthentication (new end devices are denied access):

[edit protocols dot1x authenticator]

user@switch# set interface interface-name server-fail use-cache

You can configure an interface that receives a RADIUS access-reject message from the authentication
server to move end devices attempting LAN access on the interface to a server-reject VLAN, a specified
VLAN already configured on the switch.

To configure a server reject fallback VLAN:

• [edit protocols dot1x authenticator]

user@switch# set interface interface-name server-reject-vlan vlan-sf

SEE ALSO

Example: Configuring 802.1X Authentication Options When the RADIUS Server Is Unavailable to an
EX Series Switch | 373
Configuring 802.1X Interface Settings (CLI Procedure) | 355
 351

Monitoring 802.1X Authentication | 385

Release History Table

Release Description

14.1X53-D40 Server fail fallback is supported for voice traffic starting in Release 14.1X53-D40
and Release 15.1R4.

RELATED DOCUMENTATION

Access Control and Authentication on Switching Devices | 326

802.1X Authentication | 351
802.1X and RADIUS Accounting | 399
MAC RADIUS Authentication | 390

802.1X Authentication

IN THIS SECTION

802.1X for Switches Overview | 352

Configuring 802.1X Interface Settings (CLI Procedure) | 355

Understanding RADIUS-Initiated Changes to an Authorized User Session | 357

Filtering 802.1X Supplicants by Using RADIUS Server Attributes | 360

Example: Connecting a RADIUS Server for 802.1X to an EX Series Switch | 365

Understanding Dynamic Filters Based on RADIUS Attributes | 370

Understanding Dynamic VLAN Assignment Using RADIUS Attributes | 371

Understanding Guest VLANs for 802.1X on Switches | 372

Example: Configuring 802.1X Authentication Options When the RADIUS Server Is Unavailable to an EX
Series Switch | 373

Example: Configuring Fallback Options on EX Series Switches for EAP-TTLS Authentication and Odyssey
Access Clients | 379

Monitoring 802.1X Authentication | 385

Verifying 802.1X Authentication | 386

Troubleshooting Authentication of End Devices on EX Series Switches | 388

 352

IEEE 802.1X standard for port-based network access control and protects Ethernet LANs from unauthorized
user access. It blocks all traffic to and from a supplicant (client) at the interface until the supplicant's
credentials are presented and matched on the authentication server (a RADIUS server). When the supplicant
is authenticated, the switch stops blocking access and opens the interface to the supplicant. Read this
topic for more information.

802.1X for Switches Overview

How 802.1X Authentication Works

802.1X authentication works by using an authenticator port access entity (the switch) to block ingress
traffic from a supplicant (end device) at the port until the supplicant's credentials are presented and match
on the authentication server (a RADIUS server). When authenticated, the switch stops blocking traffic and
opens the port to the supplicant.

The end device is authenticated in single supplicant mode, single-secure supplicant mode, or multiple supplicant
mode:

• single supplicant—Authenticates only the first end device. All other end devices that connect later to
the port are allowed full access without any further authentication. They effectively piggyback on the
first end device’s authentication.

• single-secure supplicant—Allows only one end device to connect to the port. No other end device is
allowed to connect until the first device logs out.

• multiple supplicant—Allows multiple end devices to connect to the port. Each end device is authenticated
individually.

Network access can be further defined by using VLANs and firewall filters, both of which act as filters to
separate and match groups of end devices to the areas of the LAN they require. For example, you can
configure VLANs to handle different categories of authentication failures depending upon:

• Whether or not the end device is 802.1X-enabled.

• Whether or not MAC RADIUS authentication is configured on the switch interfaces to which the hosts
are connected.

• Whether the RADIUS authentication server becomes unavailable or sends a RADIUS access-reject
message. See “Configuring RADIUS Server Fail Fallback (CLI Procedure)” on page 349.
 353

802.1X Features Overview

The following 802.1X features are supported on Juniper Networks Ethernet Switches:

• Guest VLAN—Provides limited access to a LAN, typically only to the Internet, for nonresponsive end
devices that are not 802.1X-enabled when MAC RADIUS authentication is not configured on the switch
interfaces to which the hosts are connected. Also, a guest VLAN can be used to provide limited access
to a LAN for guest users. Typically, the guest VLAN provides access only to the Internet and to other
guests’ end devices.

• Server-reject VLAN—Provides limited access to a LAN, typically only to the Internet, for responsive end
devices that are 802.1X-enabled but that have sent the wrong credentials. If the end device that is
authenticated using the server-reject VLAN is an IP phone, voice traffic is not allowed.

• Server-fail VLAN—Provides limited access to a LAN, typically only to the Internet, for 802.1X end devices
during a RADIUS server timeout.

• Dynamic VLAN—Enables an end device, after authentication, to be a member of a VLAN dynamically.

• Private VLAN—Enables configuration of 802.1X authentication on interfaces that are members of private
VLANs (PVLANs).

• Dynamic changes to a user session—Enables the switch administrator to terminate an already

authenticated session. This feature is based on support of the RADIUS Disconnect Message defined in
RFC 3576.

• VoIP VLAN—Supports IP telephones. The implementation of a voice VLAN on an IP telephone is

vendor-specific. If the phone is 802.1X-enabled, it is authenticated as any other supplicant is. If the
phone is not 802.1X-enabled, but has another 802.1X-compatible device connected to its data port,
that device is authenticated, and then VoIP traffic can flow to and from the phone (provided that the
interface is configured in single supplicant mode and not in single-secure supplicant mode).

NOTE: Configuring a VoIP VLAN on private VLAN (PVLAN) interfaces is not supported.

• RADIUS accounting—Sends accounting information to the RADIUS accounting server. Accounting

information is sent to the server whenever a subscriber logs in or logs out and whenever a subscriber
activates or deactivates a subscription.

• RADIUS server attributes for 802.1X—The Juniper-Switching-Filter is a vendor-specific attribute (VSA)

that can be configured on the RADIUS server to further define a supplicant's access during the 802.1X
authentication process. Centrally configuring attributes on the authentication server obviates the need
to configure these same attributes in the form of firewall filters on every switch in the LAN to which the
supplicant might connect to the LAN. This feature is based on RLI 4583, AAA RADIUS BRAS VSA Support.
 354

The following features are supported to authenticate devices that are not 802.1X-enabled:

• Static MAC bypass—Provides a bypass mechanism to authenticate devices that are not 802.1X-enabled
(such as printers). Static MAC bypass connects these devices to 802.1X-enabled ports, bypassing 802.1X
authentication.

• MAC RADIUS authentication—Provides a means to permit hosts that are not 802.1X-enabled to access
the LAN. MAC-RADIUS simulates the supplicant functionality of the client device, using the MAC address
of the client as username and password.

802.1X Authentication on Trunk Ports

Starting in Junos OS Release 18.3R1, you can configure 802.1X authentication on trunk interfaces, which
allows the network access device (NAS) to authenticate an access point (AP) or another connected Layer
2 device. An AP or switch connected to the NAS will support multiple VLANs, so must connect to a trunk
port. Enabling 802.1X authentication on the trunk interface protects the NAS from a security breach in
which an attacker might disconnect the AP and connect a laptop to get free access to network for all the
configured VLANs.

Please note the following caveats when configuring 802.1X authentication on trunk interfaces.

• Only single and single-secure supplicant modes are supported on trunk interfaces.

• You must configure 802.1X authentication locally on the trunk interface. If you configure 802.1X
authentication globally using the set protocol dot1x interface all command, the configuration is not
applied to the trunk interface.

• Dynamic VLANS are not supported on trunk interfaces.

• Guest VLAN and server-reject VLAN are not supported on trunk interfaces.

• Server fail fallback for VoIP clients is not supported on trunk interfaces (server-fail-voip).

• Authentication on trunk port is not supported using captive portal.

• Authentication on trunk port is not supported on aggregated interfaces.

• Configuration of 802.1X authentication on interfaces that are members of private VLANs (PVLANs) is
not supported on trunk ports.

SEE ALSO

Understanding Authentication on Switches | 326

Understanding 802.1X and VoIP on EX Series Switches | 489
Understanding LLDP and LLDP-MED on EX Series Switches | 623
Understanding 802.1X and RADIUS Accounting on Switches | 400
 355

Understanding Server Fail Fallback and Authentication on Switches | 348

Configuring 802.1X Interface Settings (CLI Procedure)

IEEE 802.1X authentication provides network edge security, protecting Ethernet LANs from unauthorized
user access by blocking all traffic to and from a supplicant (client) at the interface until the supplicant's
credentials are presented and matched on the authentication server (a RADIUS server). When the supplicant
is authenticated, the switch stops blocking access and opens the interface to the supplicant.

NOTE:
• You can also specify an 802.1X exclusion list to specify supplicants that can bypass
authentication and be automatically connected to the LAN. See “Configuring Static MAC
Bypass of 802.1X and MAC RADIUS Authentication (CLI Procedure)” on page 442.

• You cannot configure 802.1X user authentication on interfaces that have been enabled for
Q-in-Q tunneling.

Before you begin, specify the RADIUS server or servers to be used as the authentication server. See
“Specifying RADIUS Server Connections on Switches (CLI Procedure)” on page 344.

To configure 802.1X on an interface:

1. Configure the supplicant mode as single (authenticates the first supplicant), single-secure (authenticates
only one supplicant), or multiple (authenticates multiple supplicants):

[edit protocols dot1x]

user@switch# set authenticator interface interface-name supplicant multiple

NOTE: Multiple supplicant mode is not supported on trunk interfaces.

2. Enable reauthentication and specify the reauthentication interval:

[edit protocols dot1x]

user@switch# set authenticator interface interface-name reauthentication interval seconds

3. Configure the interface timeout value for the response from the supplicant:

[edit protocols dot1x]

user@switch# set authenticator interface interface-name supplicant-timeout seconds
 356

4. Configure the timeout for the interface before it resends an authentication request to the RADIUS
server:

[edit protocols dot1x]

user@switch# set authenticator interface interface-name server-timeout seconds

5. Configure how long, in seconds, the interface waits before retransmitting the initial EAPOL PDUs to
the supplicant:

[edit protocols dot1x]

user@switch# set authenticator interface interface-name transmit-period seconds

6. Configure the maximum number of times an EAPOL request packet is retransmitted to the supplicant
before the authentication session times out:

[edit protocols dot1x]

user@switch# set authenticator interface interface-name maximum-requests number

7. Configure the number of times the switch attempts to authenticate the port after an initial failure. The
port remains in a wait state during the quiet period after the authentication attempt.

[edit protocols dot1x]

user@switch# set authenticator interface interface-name retries number

8. Set the server-fail to deny so that the server does not fail.

[edit protocols dot1x authenticator interface interface-name]

user@switch# set server-fail deny

NOTE: This setting specifies the number of attempts before the switch puts the interface in a
HELD state.

SEE ALSO

Configuring 802.1X Authentication (J-Web Procedure)

Example: Setting Up VoIP with 802.1X and LLDP-MED on an EX Series Switch | 492
Configuring LLDP (CLI Procedure) | 616
Understanding Authentication on Switches | 326
 357

Understanding RADIUS-Initiated Changes to an Authorized User Session

IN THIS SECTION

Disconnect Messages | 357

Change of Authorization Messages | 358

CoA Request Port Bounce | 358

Error-Cause Codes | 359

When using an authentication service that is based on a client/server RADIUS model, requests are typically
initiated by the client and sent to the RADIUS server. There are instances in which a request might be
initiated by the server and sent to the client in order to dynamically modify an authenticated user session
already in progress. The client that receives and processes the messages is the switch, which acts as the
network access server, or NAS. The server can send the switch a Disconnect message requesting to
terminate a session, or a Change of Authorization (CoA) message requesting to modify the session
authorization attributes.

The switch listens for unsolicited RADIUS requests on UPD port 3799, and accepts requests only from a
trusted source. Authorization to send a Disconnect or CoA request is determined based on the source
address and the corresponding shared secret, which must be configured on the switch as well as on the
RADIUS server. For more information about configuring the source address and shared secret on the
switch, see “Example: Connecting a RADIUS Server for 802.1X to an EX Series Switch” on page 365.

Disconnect Messages

The RADIUS server sends a Disconnect-Request message to the switch in order to terminate a user session
and discard all associated session context. The switch responds to a Disconnect-Request packet with a
Disconnect-ACK message if the request is successful, that is, all associated session context is discarded
and the user session is no longer connected, or with a Disconnect-NAK packet if the request fails, that is,
the authenticator is unable to disconnect the session and discard all associated session context.

In Disconnect-Request messages, RADIUS attributes are used to uniquely identify the switch (NAS) and
the user session. The combination of NAS identification attributes and session identification attributes
included in the message must match at least one session for the request to be successful; otherwise, the
switch responds with a Disconnect-NAK message. A Disconnect-Request message can contain only NAS
and session identification attributes; if any other attributes are included, the switch responds with a
Disconnect-NAK message.
 358

Change of Authorization Messages

Change of Authorization (CoA) messages contain information for dynamically modifying the authorization
attributes for a user session to change the authorization level. This occurs as part of a two-step
authentication process, in which the endpoint is first authenticated using MAC RADIUS authentication,
and is then profiled based on the type of device. The CoA message is used to apply an enforcement policy
that is appropriate for the device, typically by changing the data filters or the VLAN.

The switch responds to a CoA message with a CoA-ACK message if the authorization change is successful,
or a with CoA-NAK message if the change is unsuccessful. If one or more authorization changes specified
in a CoA-Request message cannot be carried out, the switch responds with a CoA-NAK message.

In CoA-Request messages, RADIUS attributes are used to uniquely identify the switch (acting as the NAS)
and the user session. The combination of NAS identification attributes and session identification attributes
included in the message must match the identification attributes of at least one session for the request to
be successful; otherwise, the switch responds with a CoA-NAK message.

CoA-Request packets also include the session authorization attributes that will be modified if the request
is accepted. The supported session authorization attributes are listed below. The CoA message can contain
any or all of these attributes. If any attribute is not included as part of the CoA-Request message, the NAS
assumes that the value for that attribute is to remain unchanged.

• Filter-ID

• Tunnel-Private-Group-ID

• Juniper-Switching-Filter

• Juniper-VoIP-VLAN

• Session-Timeout

CoA Request Port Bounce

When a CoA message is used to change the VLAN for an authenticated host, end devices such as printers
do not have a mechanism to detect the VLAN change, so they do not renew the lease for their DHCP
address in the new VLAN. Starting in Junos OS Release 17.3, the port bounce feature can be used to force
the end device to initiate DHCP re-negotiation by causing a link flap on the authenticated port.

The command to bounce the port is sent from the RADIUS server using a Juniper Networks vendor-specific
attribute (VSA). The port is bounced if the following VSA attribute-value pair is received in the CoA message
from the RADIUS server:
 359

• Juniper-AV-Pair = “Port-Bounce”

To enable the port bounce feature, you must update the Junos dictionary file (juniper.dct) on the RADIUS
server with the Juniper-AV-Pair VSA. Locate the dictionary file and add the following text to the file:

ATTRIBUTE Juniper-AV-Pair Juniper-VSA(52, string) r

For more information about adding the VSA, consult the FreeRADIUS documentation.

You can disable the feature by configuring the ignore-port-bounce statement at the [edit protocols dot1x
authenticator interface interface-name] hierachy level.

Error-Cause Codes

When a disconnect or CoA operation is unsuccessful, an Error-Cause attribute (RADIUS attribute 101)
can be included in the response message sent by the NAS to the server to provide detail about the cause
of the problem. If the detected error does not map to one of the supported Error-Cause attribute values,
the router sends the message without an error-cause attribute. See Table 23 on page 359 for descriptions
of error-cause codes that can be included in response messages sent from the NAS.

Table 23: Error-Cause Codes (RADIUS Attribute 101)

Code Value Description

201 Residual session context Sent in response to a Disconnect-Request message if one or more user
removed sessions are no longer active, but residual session context was found
and successfully removed. This code is sent only within a Disconnect-ACK
message.

401 Unsupported attribute The request contains an attribute that is not supported (for example, a
third-party attribute).

402 Missing attribute A critical attribute (for example, the session identification attribute) is
missing from a request.

403 NAS identification mismatch Request contains one or more NAS identification attributes that do not
match the identity of the NAS receiving the request.

404 Invalid request Some other aspect of the request is invalid—for example, if one or more
attributes are not formatted properly.

405 Unsupported service The Service-Type attribute included with the request contains an invalid
or unsupported value.
 360

Table 23: Error-Cause Codes (RADIUS Attribute 101) (continued)

Code Value Description

406 Unsupported extension The entity receiving the request (either an NAS or a RADIUS proxy) does
not support RADIUS-initiated requests.

407 Invalid attribute value The request contains an attribute with an unsupported value.

501 Administratively prohibited The NAS is configured to prohibit honoring of Disconnect-Request or

CoA-Request messages for the specified session.

503 Session context not found The session context identified in the request does not exist on the NAS.

504 Session context not The subscriber identified by attributes in the request is owned by a
removable component that is not supported. This code is sent only within a
Disconnect-NAK message.

506 Resources unavailable A request could not be honored because of lack of available NAS
resources (such as memory).

507 Request initiated The CoA-Request message includes a Service-Type attribute with a value
of Authorize Only.

508 Multiple session selection The session identification attributes included in the request match
unsupported multiple sessions, but the NAS does not support requests that apply to
multiple sessions.

Filtering 802.1X Supplicants by Using RADIUS Server Attributes

There are two ways to configure the a RADIUS server with port firewall filters (Layer 2 firewall filters):

• Include one or more filter terms in the Juniper-Switching-Filter attribute. The Juniper-Switching-Filter
attribute is a vendor-specific attribute (VSA) listed under attribute ID number 48 in the Juniper dictionary
on the RADIUS server. Use this VSA to configure simple filter conditions for 802.1X authenticated users.
Nothing needs to be configured on the switch; all of the configuration is on the RADIUS server.

• Configure a local firewall filter on each switch and apply that firewall filter to users authenticated through
the RADIUS server. Use this method for more complex filters. The firewall filter must be configured on
each switch.
 361

NOTE: If the firewall filter configuration is modified after users are authenticated using the
802.1X authentication, then the established 802.1X authentication session must be terminated
and re-established for the firewall filter configuration changes to take effect.

This topic includes the following tasks:

1. Configuring Firewall Filters on the RADIUS Server | 361

2. Applying a Locally Configured Firewall Filter from the RADIUS Server | 364

Configuring Firewall Filters on the RADIUS Server

You can configure simple filter conditions by using the Juniper-Switching-Filter attribute in the Juniper
dictionary on the RADIUS server. These filters are sent to a switch whenever a new user is authenticated
successfully. The filters are created and applied on all EX Series switches that authenticate users through
that RADIUS server without the need for you to configure anything on each individual switch.

NOTE: This procedure describes using FreeRADIUS software to configure the

Juniper-Switching-Filter VSA. For specific information about configuring your server, consult
the AAA documentation included with your server.

To configure the Juniper-Switching-Filter attribute, enter one or more filter terms by using the CLI for the
RADIUS server. Each filter term consists of match conditions with a corresponding action. Enter the filter
terms enclosed within quotation marks (" ") by using the following syntax:

Juniper-Switching-Filter = “match <destination-mac mac-address> <source-vlan vlan-name> <source-dot1q-tag

tag> <destination-ip ip-address> <ip-protocol protocol-id> <source-port port> <destination-port port> action
(allow | deny) <forwarding-class class-of-service> <loss-priority (low | medium | high)>”

More than one match condition can be included in a filter term. When multiple conditions are specified in
a filter term, they must all be fulfilled for the packet to match the filter term. For example, the following
filter term requires a packet to match both the destination IP address and the destination MAC address
to meet the term criteria:

Juniper-Switching-Filter = “match destination-ip 10.10.10.8 destination-mac 00:00:00:01:02:03 action allow”

Multiple filter terms should be separated with commas—for example:

 362

Juniper-Switching-Filter = “match destination-mac 00:00:00:01:02:03 action allow, match destination-port 80

destination-mac 00:aa:bb:cc:dd:ee action allow”

See “Juniper-Switching-Filter VSA Match Conditions and Actions” on page 215 for definitions of match
conditions and actions.

NOTE: On EX9200 switches, and in a Junos Fusion Enterprise with EX9200 as the aggregate
device, the dynamic firewall filter is strictly applied for all IP packets. If the filter is configured
to allow only a specific destination IP address, packets with other IP addresses as the destination
IP will be dropped per the filter rules. This includes any IP protocol packets, such as DHCP, IGMP
and ARP packets.

To configure match conditions on the RADIUS server:

1. Verify that the Juniper dictionary is loaded on your RADIUS server and includes the filtering attribute
Juniper-Switching-Filter (attribute ID 48):

[root@freeradius]# cat /usr/local/share/freeradius/dictionary.juniper

# dictionary.juniper
#
# Version: $Id: dictionary.juniper,v 1.2.6.1 2005/11/30 22:17:25 aland Exp
$
# VENDOR Juniper 2636
BEGIN-VENDOR Juniper
ATTRIBUTE Juniper-Local-User-Name 1 string
ATTRIBUTE Juniper-Allow-Commands 2 string
ATTRIBUTE Juniper-Deny-Commands 3 string
ATTRIBUTE Juniper-Allow-Configuration 4 string
ATTRIBUTE Juniper-Deny-Configuration 5 string
ATTRIBUTE Juniper-Switching-Filter 48 string
<—

2. Enter the match conditions and actions. For example:

• To deny authentication based on the 802.1Q tag (here, the 802.1Q tag is 10):

[root@freeradius]#
cd /usr/local/etc/raddb
vi users

For each relevant user, add the Juniper-Switching-Filter attribute:

 363

Juniper-Switching-Filter = "Match Source-dot1q-tag 10 Action deny"

• To deny access based on a destination IP address:

[root@freeradius]# cd /usr/local/etc/raddb
vi users

For each relevant user, add the Juniper-Switching-Filter attribute:

Juniper-Switching-Filter = “Match Destination-ip 192.168.1.0/31 Action deny”

• To set the packet loss priority (PLP) to high based on a destination MAC address and the IP protocol:

[root@freeradius]# cd /usr/local/etc/raddb
vi users

For each relevant user, add the Juniper-Switching-Filter attribute:

Juniper-Switching-Filter = "Match Destination-mac 00:04:0f:fd:ac:fe, Ip-protocol 2, forwarding-class

high, Action loss-priority high"

NOTE: For the forwarding-class option to be applied, the forwarding class must be
configured on the switch and the packet loss priority specified. If it is not configured on
the switch, this option is ignored. You must specify both the forwarding class and the packet
loss priority.

3. Stop and restart the RADIUS process to activate the configuration.

 364

Applying a Locally Configured Firewall Filter from the RADIUS Server

You can apply a port firewall filter (Layer 2 firewall filter) to user policies centrally from the RADIUS server.
The RADIUS server can then specify the firewall filters that are to be applied to each user that requests
authentication, reducing the need to configure the same firewall filter on multiple switches. Use this method
when the firewall filter contains a large number of conditions or you want to use different conditions for
the same filter on different switches. The firewall filters must be configured on each switch.

For more information about firewall filters, see Firewall Filters for EX Series Switches Overview.

To apply a port firewall filter centrally from the RADIUS server:

NOTE: If port firewall filters are also configured locally for the interface, then the firewall filters
configured by using VSAs take precedence if they conflict with the locally configured port firewall
filters. If there is no conflict, they are merged.

1. Create the firewall filter on the local switch. See Configuring Firewall Filters (CLI Procedure) for more
information on configuring a port firewall filter.

2. On the RADIUS server, open the users file to display the local user profiles of the end devices to which
you want to apply the filter:

[root@freeradius]#
cat /usr/local/etc/raddb/usersvi users

3. Apply the filter to each user profile by adding the Filter-ID attribute with the filter name as the attribute
value:

Filter-Id =filter-name

For example, the user profile below for supplicant1 includes the Filter-ID attribute with the filter name
filter1:

[root@freeradius]# cat /usr/local/etc/raddb/users

supplicant1 Auth-Type := EAP, User-Password == "supplicant1"

Tunnel-Type = VLAN,
Tunnel-Medium-Type = IEEE-802,
Tunnel-Private-Group-Id = "1005",
Filter-Id = "filter1"
 365

NOTE: Multiple filters are not supported on a single interface. However, you can support
multiple filters for multiple users that are connected to the switch on the same interface by
configuring a single filter with policies for each of those users.

4. Stop and restart the RADIUS process to activate the configuration.

SEE ALSO

Example: Applying a Firewall Filter to 802.1X-Authenticated Supplicants by Using RADIUS Server

Attributes on an EX Series Switch | 420
Example: Configuring Firewall Filters for Port, VLAN, and Router Traffic on EX Series Switches

Example: Connecting a RADIUS Server for 802.1X to an EX Series Switch

IN THIS SECTION

Requirements | 366

Overview and Topology | 366

Configuration | 368

Verification | 369

802.1X is the IEEE standard for port-based network access control (PNAC). You use 802.1X to control
network access. Only users and devices providing credentials that have been verified against a user database
are allowed access to the network. You can use a RADIUS server as the user database for 802.1X
authentication, as well as for MAC RADIUS authentication.

This example describes how to connect a RADIUS server to an EX Series switch, and configure it for
802.1X:
 366

Requirements

This example uses the following software and hardware components:

• Junos OS Release 9.0 or later for EX Series switches

• One EX Series switch acting as an authenticator port access entity (PAE). The ports on the authenticator
PAE form a control gate that blocks all traffic to and from supplicants until they are authenticated.

• One RADIUS authentication server that supports 802.1X. The authentication server acts as the backend
database and contains credential information for hosts (supplicants) that have permission to connect to
the network.

Before you connect the server to the switch, be sure you have:

• Performed basic bridging and VLAN configuration on the switch. See the documentation that describes
setting up basic bridging and a VLAN for your switch. If you are using a switch that supports the Enhanced
Layer 2 Software (ELS) configuration style, see Example: Setting Up Basic Bridging and a VLAN for an EX
Series Switch with ELS Support . For all other switches, see Example: Setting Up Basic Bridging and a VLAN
for an EX Series Switch.

NOTE: For more about ELS, see Using the Enhanced Layer 2 Software CLI.

• Configured users on the RADIUS authentication server.

Overview and Topology

The EX Series switch acts as an authenticator PAE. It blocks all traffic and acts as a control gate until the
supplicant (client) is authenticated by the server. All other users and devices are denied access.

Figure 7 on page 367 shows one EX4200 switch that is connected to the devices listed in
Table 24 on page 368.
 367

Figure 7: Topology for Configuration

 368

Table 24: Components of the Topology

Property Settings

Switch hardware EX4200 access switch, 24 Gigabit Ethernet ports: 8 PoE ports (ge-0/0/0 through
ge-0/0/7) and 16 non-PoE ports (ge-0/0/8 through ge-0/0/23)

VLAN name default

One RADIUS server Backend database with an address 10.0.0.100 connected to the switch at port
ge-0/0/10

In this example, connect the RADIUS server to access port ge-0/0/10 on the EX4200 switch. The switch
acts as the authenticator and forwards credentials from the supplicant to the user database on the RADIUS
server. You must configure connectivity between the EX4200 and the RADIUS server by specifying the
address of the server and configuring the secret password. This information is configured in an access
profile on the switch.

NOTE: For more information about authentication, authorization, and accounting (AAA) services,
see the Junos OS System Basics Configuration Guide.

Configuration

CLI Quick Configuration

To quickly connect the RADIUS server to the switch, copy the following commands and paste them into
the switch terminal window:

[edit]

set access radius-server 10.0.0.100 secret juniper

set access radius-server 10.0.0.200 secret juniper

set access profile profile1 authentication-order radius

set access profile profile1 radius authentication-server [10.0.0.100 10.0.0.200]

Step-by-Step Procedure
To connect the RADIUS server to the switch:

1. Define the address of the servers, and configure the secret password. The secret password on the
switch must match the secret password on the server:
 369

[edit]
user@switch# set access radius-server 10.0.0.100 secret juniper
user@switch# set access radius-server 10.0.0.200 secret juniper

2. Configure the authentication order, making radius the first method of authentication:

[edit]
user@switch# set access profile profile1 authentication-order radius

3. Configure a list of server IP addresses to be tried in sequential order to authenticate the supplicant:

[edit]
user@switch# set access profile profile1 radius authentication-server [10.0.0.100 10.0.0.200]

Results
Display the results of the configuration:

user@switch> show configuration access

radius-server {
10.0.0.100
port 1812;
secret "$ABC123"; ## SECRET-DATA
}
}
profile profile1{
authentication-order radius;
radius {
authentication-server 10.0.0.100 10.0.0.200;
}
}
}

Verification

IN THIS SECTION

Verify That the Switch and RADIUS Server Are Properly Connected | 370

To confirm that the configuration is working properly, perform these tasks:

 370

Verify That the Switch and RADIUS Server Are Properly Connected

Purpose
Verify that the RADIUS server is connected to the switch on the specified port.

Action

Ping the RADIUS server to verify the connection between the switch and the server:

user@switch> ping 10.0.0.100

PING 10.0.0.100 (10.0.0.100): 56 data bytes

64 bytes from 10.93.15.218: icmp_seq=0 ttl=64 time=9.734 ms
64 bytes from 10.93.15.218: icmp_seq=1 ttl=64 time=0.228 ms

Meaning
ICMP echo request packets are sent from the switch to the target server at 10.0.0.100 to test whether
the server is reachable across the IP network. ICMP echo responses are being returned from the server,
verifying that the switch and the server are connected.

SEE ALSO

Example: Setting Up 802.1X for Single-Supplicant or Multiple-Supplicant Configurations on an EX

Series Switch | 405
Example: Setting Up 802.1X in Conference Rooms to Provide Internet Access to Corporate Visitors
on an EX Series Switch | 413
Example: Setting Up VoIP with 802.1X and LLDP-MED on an EX Series Switch | 492
Configuring 802.1X RADIUS Accounting (CLI Procedure) | 403

Understanding Dynamic Filters Based on RADIUS Attributes

You can use RADIUS server attributes to implement port firewall filters on a RADIUS authentication server.
These filters can be dynamically applied to supplicants that request authentication through that server.
RADIUS server attributes are clear-text fields encapsulated in Access-Accept messages sent from the
authentication server to the switch when a supplicant connected to the switch is successfully authenticated.
The switch, acting as the authenticator, uses the information in the RADIUS attributes to apply the related
filters to the supplicant. Dynamic filters can be applied to multiple ports on the same switch, or to multiple
switches that the use same authentication server, providing centralized access control for the network.
 371

You can define firewall filters directly on the RADIUS server by using the Juniper-Switching-Filter attribute,
which is a RADIUS attribute specific to Juniper Networks, also known as a vendor-specific attribute (VSA).
VSAs are described in RFC 2138, Remote Authentication Dial In User Service (RADIUS). The
Juniper-Switching-Filter VSA is listed under attribute ID number 48 in the Juniper dictionary on the RADIUS
server, with the vendor ID set to the Juniper Networks ID number 2636. Using this attribute, you define
filters on the authentication server, which are applied on all switches that authenticate supplicants through
that server. This method eliminates the need to configure the same filters on multiple switches.

Alternatively, you can apply a port firewall filter to multiple ports on the same switch by using the Filter-ID
attribute, which is RADIUS attribute ID number 11. To use the Filter-ID attribute, you must first configure
a filter on the switch, and then add the filter name to user policies on the RADIUS server as the value of
the Filter-ID attribute. When a supplicant defined in one of those policies is authenticated by the RADIUS
server, the filter is applied to the switch port that has been authenticated for the supplicant. Use this
method when the firewall filter has complex conditions, or if you want to use different conditions for the
same filter on different switches. The filter named in the Filter-ID attribute must be configured locally on
the switch at the [edit firewall family ethernet-switching filter] hierarchy level.

VSAs are supported only for 802.1X single supplicant configurations and multiple supplicant configurations.

SEE ALSO

Understanding Authentication on Switches | 326

Example: Applying a Firewall Filter to 802.1X-Authenticated Supplicants by Using RADIUS Server
Attributes on an EX Series Switch | 420
Configuring Firewall Filters (CLI Procedure)
Juniper-Switching-Filter VSA Match Conditions and Actions | 215

Understanding Dynamic VLAN Assignment Using RADIUS Attributes

VLANs can be dynamically assigned by a RADIUS server to supplicants requesting 802.1X authentication
through that server. You configure the VLAN on the RADIUS server using RADIUS server attributes, which
are clear-text fields encapsulated in messages sent from the authentication server to the switch when a
supplicant connected to the switch requests authentication. The switch, acting as the authenticator, uses
the information in the RADIUS attributes to assign the VLAN to the supplicant. Based on the results of
the authentication, a supplicant that began authentication in one VLAN might be assigned to another
VLAN.

Successful authentication requires that the VLAN ID or VLAN name is configured on the switch acting as
802.1X authenticator, and that it matches the VLAN ID or VLAN name sent by the RADIUS server during
 372

authentication. If neither exists, the end device is not authenticated. If a guest VLAN is established, the
unauthenticated end device is automatically moved to the guest VLAN.

The RADIUS server attributes used for dynamic VLAN assignment described in RFC 2868, RADIUS Attributes
for Tunnel Protocol Support.

• Tunnel-Type—Defined as RADIUS attribute type 64. The value should be set to VLAN.

• Tunnel-Medium-Type—Defined as RADIUS attribute type 65. The value should be set to IEEE-802.

• Tunnel-Private-Group-ID—Defined as RADIUS attribute type 81. The value should be set to the VLAN
ID or the VLAN name.

For more information about configuring dynamic VLANs on your RADIUS server, see the documentation
for your RADIUS server.

SEE ALSO

Example: Configuring MAC RADIUS Authentication on an EX Series Switch | 392

Example: Setting Up 802.1X in Conference Rooms to Provide Internet Access to Corporate Visitors
on an EX Series Switch | 413

Understanding Guest VLANs for 802.1X on Switches

Guest VLANs can be configured on switches that are using 802.1X authentication to provide limited
access—typically only to the Internet—for corporate guests. Guest VLAN is used as a fallback when:

• The supplicant is not 802.1X-enabled and does not respond to EAP messages.

• MAC RADIUS authentication has not been configured on the switch interfaces to which the supplicant
is connected.

• Captive portal has not been configured on the switch interfaces to which the supplicant is connected.

A guest VLAN is not used for supplicants that send incorrect credentials. Those supplicants are directed
to the server-reject VLAN instead.

For end devices that are not 802.1X-enabled, a guest VLAN can allow limited access to a server from
which the non-802.1X-enabled end device can download the supplicant software and attempt authentication
again.

SEE ALSO
 373

Example: Setting Up 802.1X in Conference Rooms to Provide Internet Access to Corporate Visitors
on an EX Series Switch | 413
Understanding Authentication on Switches | 326

Example: Configuring 802.1X Authentication Options When the RADIUS

Server Is Unavailable to an EX Series Switch

IN THIS SECTION

Requirements | 373

Overview and Topology | 374

Configuration | 376

Verification | 377

Server fail fallback enables you to specify how 802.1X supplicants connected to the switch are supported
if the RADIUS authentication server becomes unavailable.

You use 802.1X to control network access. Only users and devices (supplicants) providing credentials that
have been verified against a user database are allowed access to the network. You use a RADIUS server
as the user database.

This example describes how to configure an interface to move a supplicant to a VLAN in the event of a
RADIUS server timeout:

Requirements

This example uses the following software and hardware components:

NOTE: This example also applies to QFX5100 switches.

• Junos OS Release 9.3 or later for EX Series switches

• One EX Series switch acting as an authenticator port access entity (PAE). The ports on the authenticator
PAE form a control gate that blocks all traffic to and from supplicants until they are authenticated.
 374

• One RADIUS authentication server that supports 802.1X. The authentication server acts as the backend
database and contains credential information for hosts (supplicants) that have permission to connect to
the network.

Before you connect the server to the switch, be sure you have:

• Performed basic bridging and VLAN configuration on the switch. See the documentation that describes
setting up basic bridging and a VLAN for your switch. If you are using a switch that supports the Enhanced
Layer 2 Software (ELS) configuration style, see Example: Setting Up Basic Bridging and a VLAN for an EX
Series Switch with ELS Support or Example: Setting Up Basic Bridging and a VLAN on Switches. For all other
switches, seeExample: Setting Up Basic Bridging and a VLAN for an EX Series Switch.

NOTE: For more about ELS, see Using the Enhanced Layer 2 Software CLI.

• Set up a connection between the switch and the RADIUS server. See “Example: Connecting a RADIUS
Server for 802.1X to an EX Series Switch” on page 365.

• Configured users on the authentication server.

Overview and Topology

A RADIUS server timeout occurs if no authentication RADIUS servers are reachable when a supplicant
logs in and attempts to access the LAN. Using server fail fallback, you configure alternative options for
supplicants attempting LAN access. You can configure the switch to accept or deny access to supplicants
or to maintain the access already granted to supplicants before the RADIUS server timeout. Additionally,
you can configure the switch to move supplicants to a specific VLAN if a RADIUS timeout occurs.

Figure 8 on page 375 shows the topology used for this example. The RADIUS server is connected to the
EX4200 switch on access port ge-0/0/10. The switch acts as the authenticator port access entity (PAE)
and forwards credentials from the supplicant to the user database on the RADIUS server. The switch blocks
all traffic and acts as a control gate until the supplicant is authenticated by the authentication server. A
supplicant is connected to the switch through interface ge-0/0/1.

NOTE: This figure also applies to QFX5100 switches.

 375

Figure 8: Topology for Configuring 802.1X Options

Table 25 on page 375 describes the components in this topology.

Table 25: Components of the Topology

Property Settings

Switch hardware EX4200 access switch, 24 Gigabit Ethernet ports: 16 non-PoE ports and 8
PoE ports.

VLAN names default VLAN

vlan-sf VLAN

Supplicant Supplicant attempting access on interface ge-0/0/1

One RADIUS server Backend database with an address of 10.0.0.100 connected to the switch at
port ge-0/0/10
 376

In this example, configure interface ge-0/0/1 to move a supplicant attempting access to the LAN during
a RADIUS timeout to another VLAN. A RADIUS timeout prevents the normal exchange of EAP messages
that carry information from the RADIUS server to the switch and permit the authentication of a supplicant.
The default VLAN is configured on interface ge-0/0/1. When a RADIUS timeout occurs, supplicants on
the interface will be moved from the default VLAN to the VLAN named vlan-sf.

Configuration

CLI Quick Configuration

To quickly configure server fail fallback on the switch, copy the following commands and paste them into
the switch terminal window:

[edit protocols dot1x authenticator]

set interface ge-0/0/1 server-fail vlan-name vlan-sf

Step-by-Step Procedure
To configure an interface to divert supplicants to a specific VLAN when a RADIUS timeout occurs (here,
the VLAN is vlan-sf):

1. Define the VLAN to which supplicants are diverted:

[edit protocols dot1x authenticator]

user@switch# set interface ge-0/0/1 server-fail vlan-name vlan-sf

Results
Display the results of the configuration:

user@switch> show configuration

interfaces {
ge-0/0/1 {
unit 0 {
family ethernet-switching {
vlan {
members default;
}
}
}
}
protocols {
dot1x {
authenticator {
interface {
 377

ge-0/0/1.0 {
server-fail vlan-name vlan-sf;
}
}
}
}
}
}

Verification

IN THIS SECTION

Verifying That the Supplicants Are Moved to an Alternative VLAN During a RADIUS Timeout | 377

To confirm that the configuration is working properly, perform these tasks:

Verifying That the Supplicants Are Moved to an Alternative VLAN During a RADIUS Timeout

Purpose
Verify that the interface moves supplicants to an alternative VLAN during a RADIUS timeout.

NOTE: On switches running Junos OS for EX Series with support for ELS, the output for the
show vlans command will contain additional information. If your switch runs software that
supports ELS, see show vlans. For ELS details, see Using the Enhanced Layer 2 Software CLI

Action

Display the VLANs configured on the switch; the interface ge-0/0/1.0 is a member of the default VLAN:

user@switch> show vlans

Name Tag Interfaces

default
ge-0/0/0.0, ge-0/0/1.0*, ge-0/0/5.0*, ge-0/0/10.0,
ge-0/0/12.0*, ge-0/0/14.0*, ge-0/0/15.0, ge-0/0/20.0
v2 77
 378

None
vlan—sf 50
None
mgmt
me0.0*

Display 802.1X protocol information on the switch to view supplicants that are authenticated on interface
ge-0/0/1.0:

user@switch> show dot1x interface brief

802.1X Information:
Interface Role State MAC address User
ge-0/0/1.0 Authenticator Authenticated 00:00:00:00:00:01 abc
ge-0/0/10.0 Authenticator Initialize
ge-0/0/14.0 Authenticator Connecting
ge-0/0/15.0 Authenticator Initialize
ge-0/0/20.0 Authenticator Initialize

A RADIUS server timeout occurs. Display the Ethernet switching table to show that the supplicant with
the MAC address 00:00:00:00:00:01 previously accessing the LAN through the default VLAN is now being
learned on the VLAN named vlan-sf:

user@switch> show ethernet-switching table

Ethernet-switching table: 3 entries, 1 learned

VLAN MAC address Type Age Interfaces
v1 * Flood - All-members
vlan—sf 00:00:00:00:00:01 Learn 1:07 ge-0/0/1.0
default * Flood - All-members

Display 802.1X protocol information to show that interface ge-0/0/1.0 is connecting and will open LAN
access to supplicants:

user@switch> show dot1x interface brief

802.1X Information:
Interface Role State MAC address User
 379

ge-0/0/1.0 Authenticator Connecting

ge-0/0/10.0 Authenticator Initialize
ge-0/0/14.0 Authenticator Connecting
ge-0/0/15.0 Authenticator Initialize
ge-0/0/20.0 Authenticator Initialize

Meaning
The show vlans command displays interface ge-0/0/1.0 as a member of the default VLAN. The show
dot1x interface brief command shows that a supplicant (abc) is authenticated on interface ge-0/0/1.0 and
has the MAC address 00:00:00:00:00:01. A RADIUS server timeout occurs, and the authentication server
cannot be reached by the switch. The show-ethernet-switching table command shows that MAC address
00:00:00:00:00:01 is learned on VLAN vlan-sf. The supplicant has been moved from the default VLAN to
the vlan-sf VLAN. The supplicant is then connected to the LAN through the VLAN named vlan-sf.

SEE ALSO

Example: Setting Up 802.1X for Single-Supplicant or Multiple-Supplicant Configurations on an EX

Series Switch | 405
Configuring RADIUS Server Fail Fallback (CLI Procedure) | 349
Configuring 802.1X RADIUS Accounting (CLI Procedure) | 403
Understanding Server Fail Fallback and Authentication on Switches | 348

Example: Configuring Fallback Options on EX Series Switches for EAP-TTLS

Authentication and Odyssey Access Clients

IN THIS SECTION

Requirements | 380

Overview and Topology | 380

Configuration | 382

Verification | 384
 380

For 802.1X user authentication, EX Series switches support RADIUS authentication servers that are using
Extensible Authentication Protocol–Tunneled TLS (EAP-TTLS) to authenticate Odyssey Access Client
(OAC) supplicants. OAC networking software runs on endpoint computers (desktop, laptop, or notepad
computers and supported wireless devices) and provides secure access to both wired and wireless networks.

This example describes how to configure an 802.1X-enabled interface on the switch to provide fallback
support for OAC users who have entered incorrect login credentials:

Requirements

This example uses the following software and hardware components:

NOTE: This example also applies to QFX5100 switches.

• Junos OS Release 11.2 or later for EX Series switches

• One EX Series switch acting as an authenticator port access entity (PAE). The ports on the authenticator
PAE form a control gate that blocks all traffic to and from supplicants until they are authenticated.

• One RADIUS authentication server that supports 802.1X. The authentication server acts as the backend
database and contains credential information for hosts (supplicants) that have permission to connect to
the network.

• One OAC end device acting as a supplicant.

Before you begin configuring the fallback option, ensure that you have:

• Set up a connection between the switch and the RADIUS server. See “Example: Connecting a RADIUS
Server for 802.1X to an EX Series Switch” on page 365.

• Configured EAP-TTLS on the server. See your RADIUS server documentation.

• Configured users on the RADIUS server. See your RADIUS server documentation.

Overview and Topology

OAC is networking software that runs on endpoint computers (desktop, laptop, or notepad) and supported
wireless devices. OAC provides full support for EAP, which is required for secure wireless LAN access.

In this topology, OAC is deployed with an 802.1X-enabled switch and a RADIUS server. The switch functions
as an enforcement point in the network security architecture. This topology:

• Ensures that only authorized users can connect.

• Maintains privacy of login credentials.

• Maintains data privacy over the wireless link.

 381

This example includes the configuration of a server-reject VLAN on the switch, which can be used to
prevent accidental lockout for users who have entered incorrect login credentials. These users can be
given limited LAN access.

However, this fallback configuration is complicated by the fact that the OAC supplicant and RADIUS server
are using EAP-TTLS. EAP-TTLS creates a secure encrypted tunnel between the server and the end device
to complete the authentication process. When the user enters incorrect login credentials, the RADIUS
server sends EAP failure messages directly to the client through this tunnel. The EAP failure message
causes the client to restart the authentication procedure, so that the switch’s 802.1X authentication process
tears down the session that was established with the switch using the server-reject VLAN. You can enable
the remedial connection to continue by configuring:

• eapol-block—Enable the EAPoL block timer on the 802.1X interface that is configured to belong to the
server-reject VLAN. The block timer causes the authentication port access entity to ignore EAP start
messages from the client, attempting to restart the authentication procedure.

NOTE: The EAPoL block timer is triggered only after the configured number of allowed
reattempts (using the retries option) on the 802.1X interface have been exhausted. You can
configure retries to specify the number of times the switch attempts to authenticate the port
after an initial failure. The default is three retries.

• block-interval—Configure the amount of time that you want the EAPoL block timer to continue to ignore
EAP start messages. If you do not configure the block interval, the EAPoL block timer defaults to 120
seconds.

When the 802.1X interface ignores the EAP start messages from the client, the switch allows the existing
remedial session that was established through the server-reject VLAN to remain open.

These configuration options apply to single, single-secure, and multiple supplicant authentication modes.
In this example, the 802.1X interface is configured in single supplicant mode.

Figure 9 on page 382 shows an EX Series switch connecting an OAC end device to a RADIUS server, and
indicates the protocols being used to connect the network entities.

NOTE: This figure also applies to QFX5100 switches.

 382

Figure 9: EX Series Switch Connecting OAC to RADIUS Server Using EAP-TTLS Authentication

Table 26 on page 382 describes the components in this OAC deployment:.

Table 26: Components of the OAC Deployment

Property Settings

Switch hardware EX Series switch

VLANs default

server-reject-vlan: VLAN name is remedial and VLAN ID is

700

802.1X interface ge-0/0/8

OAC supplicant EAP-TTLS

One RADIUS authentication server EAP-TTLS

Configuration

CLI Quick Configuration

To quickly configure the fallback options for EAP-TTLS and OAC supplicants, copy the following commands
and paste them into the switch terminal window:

[edit]
set vlans remedial vlan-id 700
set protocols dot1x authenticator interface ge-0/0/8 retries 4
set protocols dot1x authenticator interface ge-0/0/8 server-reject-vlan remedial
set protocols dot1x authenticator interface ge-0/0/8 server-reject-vlan eapol-block
set protocols dot1x authenticator interface ge-0/0/8 server-reject-vlan block-interval 130
 383

Step-by-Step Procedure
To configure the fallback options for EAP-TTLS and OAC supplicants:

TIP: In this example, the switch has only one server-reject VLAN. Therefore, the configuration
specifies eapol-block and block-interval directly after server-reject-vlan. However, if you have
configured multiple VLANs on the switch, you must include the VLAN name or VLAN ID directly
after server-reject-vlan to indicate which VLAN is being modified.

1. Configure a VLAN that will function as the server-reject VLAN to provide limited LAN access for users
who have entered incorrect login credentials:

[edit]
user@switch# set vlans remedial vlan-id 700

2. Configure the number of times for the client to be prompted for username and password before an
incorrect login is directed to the server-reject VLAN:

[edit protocols dot1x authenticator interface ge-0/0/8]

user@switch# set retries 4

3. Configure the 802.1X authenticator interface to use the server-reject VLAN as a fallback for incorrect
logins:

[edit protocols dot1x authenticator interface ge-0/0/8]

user@switch# set server-reject-vlan remedial

4. Enable the EAPoL block timer on the 802.1X interface that is configured to belong to the server-reject
VLAN.

[edit protocols dot1x authenticator interface ge-0/0/8]

user@switch# set server-reject-vlan eapol-block

5. Configure the amount of time for the EAPoL block to remain in effect:

[edit protocols dot1x authenticator interface ge-0/0/8]

user@switch# set server-reject-vlan block-interval 130

Results

Check the results of the configuration:

user@switch> show configuration

 384

protocols {
dot1x {
authenticator {
interface {
ge-0/0/8.0 {
supplicant single;
retries 4;
server-reject-vlan remedial block-interval 130 eapol-block;
}

Verification

IN THIS SECTION

Verifying the Configuration of the 802.1X Interface | 384

To confirm that the configuration and the fallback options are working correctly, perform this task:

Verifying the Configuration of the 802.1X Interface

Purpose
Verify that the 802.1X interface is configured with the desired options.

Action

user@switch> show dot1x interface ge-0/0/8.0 detail

ge-0/0/8.0
Role: Authenticator
Administrative state: Auto
Supplicant mode: Single
Number of retries: 4
Quiet period: 60 seconds
Transmit period: 30 seconds
Mac Radius: Disabled
Mac Radius Restrict: Disabled
Reauthentication: Enabled
Configured Reauthentication interval: 120 seconds
Supplicant timeout: 30 seconds
Server timeout: 30 seconds
 385

Maximum EAPoL requests: 2

Guest VLAN member: guest
Number of connected supplicants: 1
Supplicant: tem, 2A:92:E6:F2:00:00
Operational state: Authenticated
Backend Authentication state: Idle
Authentication method: Radius
Authenticated VLAN: remedial
Session Reauth interval: 120 seconds
Reauthentication due in 68 seconds

Meaning
The show dot1x ge-0/0/8 detail command output shows that the ge-0/0/8 interface is in the Authenticated
state and that it is using the remedial VLAN.

SEE ALSO

Understanding Authentication on Switches | 326

Monitoring 802.1X Authentication

Purpose

NOTE: This topic applies only to the J-Web Application package.

J-Web Application package Release 14.1X53-A2 does not support 802.1X authentication on
EX4600 switches.

Use the monitoring feature to display details of authenticated users and users that failed authentication.

Action
To display authentication details in the J-Web interface, select Monitoring > Security > 802.1X.

To display authentication details in the CLI, enter the following commands:

• show dot1x interface detail | display xml

• show dot1x interface detail <interface> | display xml

• show dot1x auth-failed-users

 386

Meaning
The details displayed include:

• A list of authenticated users.

• The number of connected users.

• A list of users that failed authentication.

You can also specify an interface for which the details must be displayed.

SEE ALSO

Configuring 802.1X Authentication (J-Web Procedure)

Example: Setting Up 802.1X for Single-Supplicant or Multiple-Supplicant Configurations on an EX
Series Switch | 405

Verifying 802.1X Authentication

Purpose
Verify that supplicants are being authenticated on an interface on a switch with the interface configured
for 802.1X authentication, and display the method of authentication being used.

Action

Display detailed information about an interface configured for 802.1X (here, the interface is ge-0/0/16):

user@switch> show dot1x interface ge-0/0/16.0 detail

ge-0/0/16.0
Role: Authenticator
Administrative state: Auto
Supplicant mode: Single
Number of retries: 3
Quiet period: 60 seconds
Transmit period: 30 seconds
Mac Radius: Enabled
Mac Radius Strict: Disabled
Reauthentication: Enabled Reauthentication interval: 40 seconds
Supplicant timeout: 30 seconds
Server timeout: 30 seconds
Maximum EAPOL requests: 1
 387

Guest VLAN member: <not configured>

Number of connected supplicants: 1
Supplicant: user5, 00:30:48:8C:66:BD
Operational state: Authenticated
Authentication method: Radius
Authenticated VLAN: v200
Reauthentication due in 17 seconds

Meaning
The sample output from the show dot1x interface detail command shows that the Number of connected
supplicants is 1. The supplicant that was authenticated and is now connected to the LAN is known as
user5 on the RADIUS server and has the MAC address 00:30:48:8C:66:BD. The supplicant was authenticated
by means of the 802.1X authentication method called RADIUS authentication, as indicated by Radius in
the output. When RADIUS authentication is used, the supplicant is configured on the RADIUS server, the
RADIUS server communicates this to the switch, and the switch opens LAN access on the interface to
which the supplicant is connected. The sample output also shows that the supplicant is connected to VLAN
v200.

Other 802.1X authentication methods supported on EX Series switches in addition to RADIUS authentication
are:

• Guest VLAN—A nonresponsive host is granted Guest-VLAN access.

• MAC Radius—A nonresponsive host is authenticated based on its MAC address. The MAC address is
configured as permitted on the RADIUS server, the RADIUS server notifies the switch that the MAC
address is a permitted address, and the switch grants LAN access to the nonresponsive host on the
interface to which it is connected.

• Server-fail deny—If the RADIUS servers time out, all supplicants are denied access to the LAN, preventing
traffic from the supplicant from traversing through the interface. This is the default.

• Server-fail permit—When the RADIUS server is unavailable, a supplicant is still permitted access to the
LAN as if the supplicant were successfully authenticated by the RADIUS server.

• Server-fail use-cache—If the RADIUS servers time out during reauthentication, previously authenticated
supplicants are granted LAN access, but new supplicants are denied LAN access.

• Server-fail VLAN—A supplicant is configured to be moved to a specified VLAN if the RADIUS server is
unavailable to reauthenticate the supplicant. (The VLAN must already exist on the switch.)

SEE ALSO

Configuring 802.1X Authentication (J-Web Procedure)

 388

Configuring MAC RADIUS Authentication (CLI Procedure) | 391

Configuring RADIUS Server Fail Fallback (CLI Procedure) | 349

Troubleshooting Authentication of End Devices on EX Series Switches

Problem
Description: End devices configured using static MAC addresses lose connection to the switch after the
clear dot1x interface command is run to clear all learned MAC addresses.
Before clearing MAC addresses:

user@switch# run show ethernet-switching table

Ethernet-switching table: 3 entries, 1 learned, 0 persistent entries
VLAN MAC address Type Age Interfaces
vlan100 * Flood - All-members
default * Flood - All-members
default 00:a0:d4:00:03:00 Learn 0 ge-3/0/16.0

user@switch> show dot1x authentication-bypassed-users

MAC address Interface VLAN
00:a0:d4:00:03:00 ge-3/0/16.0 configured/default

To clear MAC addresses:

user@switch> clear dot1x interface

After clearing MAC addresses:

user@switch> show ethernet-switching table

Ethernet-switching table: 2 entries, 0 learned, 0 persistent entries
VLAN MAC address Type Age Interfaces
vlan100 * Flood - All-members
default * Flood - All-members

user@switch> show dot1x authentication-bypassed-users

Note that there are no end devices on the authentication bypass list.
 389

Cause
Static MAC addresses are treated the same as other learned MAC addresses on an interface. When the
clear dot1x interface command is run, it clears all learned MAC addresses from the interface, including the
static MAC bypass list (also known as the exclusion list).

Solution
If you run the clear dot1x interfaces command for an interface that has static MAC addresses configured
for authentication bypass, re-add the static MAC addresses to the static MAC bypass list.

SEE ALSO

clear dot1x | 1348

Understanding Authentication on Switches | 326

Release History Table

Release Description

18.4R1 Starting in Junos OS Release 18.3R1, you can configure 802.1X authentication on trunk
interfaces, which allows the network access device (NAS) to authenticate an access point
(AP) or another connected Layer 2 device.

17.3R1 Starting in Junos OS Release 17.3, the port bounce feature can be used to force the end
device to initiate DHCP re-negotiation by causing a link flap on the authenticated port.

14.1X53-A2 J-Web Application package Release 14.1X53-A2 does not support 802.1X authentication
on EX4600 switches.

RELATED DOCUMENTATION

RADIUS Server Configuration for Authentication | 343

802.1X and RADIUS Accounting | 399
MAC RADIUS Authentication | 390
Example: Setting Up 802.1X for Single-Supplicant or Multiple-Supplicant Configurations on an EX
Series Switch | 405
Example: Setting Up 802.1X in Conference Rooms to Provide Internet Access to Corporate Visitors
on an EX Series Switch | 413
 390

MAC RADIUS Authentication

IN THIS SECTION

Configuring MAC RADIUS Authentication (CLI Procedure) | 391

Example: Configuring MAC RADIUS Authentication on an EX Series Switch | 392

You can control access to your network through a switch by using several different authentication. Junos
OS switches support 802.1X, MAC RADIUS, and captive portal as an authentication methods to devices
requiring to connect to a network.

You can configure MAC RADIUS authentication on the switch interfaces to which the hosts are connected
to provide LAN access. For more information, read this topic.
 391

Configuring MAC RADIUS Authentication (CLI Procedure)

You can permit devices that are not 802.1X-enabled LAN access by configuring MAC RADIUS authentication
on the switch interfaces to which the hosts are connected.

NOTE: You can also allow non-802.1X-enabled devices to access the LAN by configuring their
MAC address for static MAC bypass of authentication.

You can configure MAC RADIUS authentication on an interface that also allows 802.1X authentication,
or you can configure either authentication method alone.

If both MAC RADIUS and 802.1X authentication are enabled on the interface, the switch first sends the
host three EAPoL requests to the host. If there is no response from the host, the switch sends the host’s
MAC address to the RADIUS server to check whether it is a permitted MAC address. If the MAC address
is configured as permitted on the RADIUS server, the RADIUS server sends a message to the switch that
the MAC address is a permitted address, and the switch opens LAN access to the nonresponsive host on
the interface to which it is connected.

If MAC RADIUS authentication is configured on the interface but 802.1X authentication is not (by using
the mac-radius restrict option), the switch attempts to authenticate the MAC address with the RADIUS
server without delaying by attempting 802.1X authentication first.

Before you configure MAC RADIUS authentication, be sure you have:

 392

• Configured basic access between the switch and the RADIUS server. See “Example: Connecting a RADIUS
Server for 802.1X to an EX Series Switch” on page 365.

To configure MAC RADIUS authentication by using the CLI:

• On the switch, configure the interfaces to which the nonresponsive hosts are attached for MAC RADIUS
authentication, and add the restrict qualifier for interface ge-0/0/20 to have it use only MAC RADIUS
authentication:

[edit]
user@switch# set protocols dot1x authenticator interface ge-0/0/19 mac-radius
user@switch# set protocols dot1x authenticator interface ge-0/0/20 mac-radius restrict

• On a RADIUS authentication server, create user profiles for each nonresponsive host using the MAC
address (without colons) of the nonresponsive host as the username and password (here, the MAC
addresses are 00:04:0f:fd:ac:fe and 00:04:ae:cd:23:5f):

[root@freeradius]#
edit /etc/raddb
vi users
00040ffdacfe Auth-type:=Local, User-Password = "00040ffdacfe"
0004aecd235f Auth-type:=Local, User-Password = "0004aecd235f"

SEE ALSO

Understanding Authentication on Switches | 326

Example: Configuring MAC RADIUS Authentication on an EX Series Switch

IN THIS SECTION

Requirements | 393

Overview and Topology | 393

Configuration | 396

Verification | 397
 393

To permit hosts that are not 802.1X-enabled to access a LAN, you can configure MAC RADIUS
authentication on the switch interfaces to which the non-802.1X-enabled hosts are connected. When
MAC RADIUS authentication is configured, the switch will attempt to authenticate the host with the
RADIUS server by using the host’s MAC address.

This example describes how to configure MAC RADIUS authentication for two non-802.1X-enabled hosts:

Requirements

This example uses the following software and hardware components:

NOTE: This example also applies to QFX5100 switches.

• Junos OS Release 9.3 or later for EX Series switches.

• An EX Series switch acting as an authenticator port access entity (PAE). The ports on the authenticator
PAE form a control gate that blocks all traffic to and from supplicants until they are authenticated.

• A RADIUS authentication server. The authentication server acts as the backend database and contains
credential information for hosts (supplicants) that have permission to connect to the network.

Before you configure MAC RADIUS authentication, be sure you have:

• Configured basic access between the EX Series switch and the RADIUS server. See “Example: Connecting
a RADIUS Server for 802.1X to an EX Series Switch” on page 365.

• Performed basic bridging and VLAN configuration on the switch. See the documentation that describes
setting up basic bridging and a VLAN for your switch. If you are using a switch that supports the Enhanced
Layer 2 Software (ELS) configuration style, see Example: Setting Up Basic Bridging and a VLAN for an EX
Series Switch with ELS Support or Example: Setting Up Basic Bridging and a VLAN on Switches. For all other
switches, see Example: Setting Up Basic Bridging and a VLAN for an EX Series Switch.

NOTE: For more about ELS, see: Using the Enhanced Layer 2 Software CLI

• Performed basic 802.1X configuration. See “Configuring 802.1X Interface Settings (CLI Procedure)” on
page 355.

Overview and Topology

IEEE 802.1X port-based network access control (PNAC) authenticates and permits devices access to a
LAN if the devices can communicate with the switch by using the 802.1X protocol (that is, the devices are
802.1X-enabled). To permit non-802.1X-enabled end devices to access the LAN, you can configure MAC
 394

RADIUS authentication on the interfaces to which the end devices are connected. When the MAC address
of the end device appears on the interface, the switch consults the RADIUS server to check whether it is
a permitted MAC address. If the MAC address of the end device is configured as permitted on the RADIUS
server, the switch opens LAN access to the end device.

You can configure both MAC RADIUS authentication and 802.1X authentication methods on an interface
configured for multiple supplicants. Additionally, if an interface is connected only to a non-802.1X-enabled
host, you can enable MAC RADIUS and not enable 802.1X authentication by using the mac-radius restrict
option, and thus avoid the delay that occurs while the switch determines that the device is does not respond
to EAP messages.

Figure 10 on page 395 shows the two printers connected to the switch.

NOTE: This figure also applies to QFX5100 switches.

 395

Figure 10: Topology for MAC RADIUS Authentication Configuration

Table 27 on page 395 shows the components in the example for MAC RADIUS authentication.

Table 27: Components of the MAC RADIUS Authentication Configuration Topology

Property Settings

Switch hardware EX4200 ports (ge-0/0/0 through ge-0/0/23)

VLAN name sales

Connections to printers (no PoE required) ge-0/0/19, MAC address 00040ffdacfe

ge-0/0/20, MAC address 0004aecd235f

RADIUS server Connected to the switch on interface ge-0/0/10

 396

The printer with the MAC address 00040ffdacfe is connected to access interface ge-0/0/19. A second
printer with the MAC address 0004aecd235f is connected to access interface ge-0/0/20. In this example,
both interfaces are configured for MAC RADIUS authentication on the switch, and the MAC addresses
(without colons) of both printers are configured on the RADIUS server. Interface ge-0/0/20 is configured
to eliminate the normal delay while the switch attempts 802.1X authentication; MAC RADIUS authentication
is enabled and 802.1X authentication is disabled using the mac radius restrict option.

Configuration

CLI Quick Configuration

To quickly configure MAC RADIUS authentication, copy the following commands and paste them into the
switch terminal window:

[edit]
set protocols dot1x authenticator interface ge-0/0/19 mac-radius
set protocols dot1x authenticator interface ge-0/0/20 mac-radius restrict

NOTE: You must also configure the two MAC addresses as usernames and passwords on the
RADIUS server, as is done in step 2 of the Step-by-Step Procedure.

Step-by-Step Procedure
Configure MAC RADIUS authentication on the switch and on the RADIUS server:

1. On the switch, configure the interfaces to which the printers are attached for MAC RADIUS
authentication, and configure the restrict option on interface ge-0/0/20, so that only MAC RADIUS
authentication is used:

[edit]
user@switch# set protocols dot1x authenticator interface ge-0/0/19 mac-radius
user@switch# set protocols dot1x authenticator interface ge-0/0/20 mac-radius restrict

2. On the RADIUS server, configure the MAC addresses 00040ffdacfe and 0004aecd235f as usernames
and passwords:

[root@freeradius]#
edit /etc/raddb
vi users
00040ffdacfe Auth-type:=EAP, User-Password = "00040ffdacfe"
0004aecd235f Auth-type:=EAP, User-Password = "0004aecd235f"
 397

Results
Display the results of the configuration on the switch:

user@switch> show configuration

protocols {
dot1x {
authenticator {
authentication-profile-name profile52;
interface {
ge-0/0/19.0 {
mac-radius;
}
ge-0/0/20.0 {
mac-radius {
restrict;
}
}
}
}
}
}

Verification

IN THIS SECTION

Verifying That the Supplicants Are Authenticated | 397

Verify that the supplicants are authenticated:

Verifying That the Supplicants Are Authenticated

Purpose
After supplicants are configured for MAC RADIUS authentication on the switch and on the RADIUS server,
verify that they are authenticated and display the method of authentication.

Action

Display information about the 802.1X-configured interfaces ge-0/0/19 and ge-0/0/20:

user@switch> show dot1x interface ge-0/0/19.0 detail

 398

ge-0/0/19.0
Role: Authenticator
Administrative state: Auto
Supplicant mode: Single
Number of retries: 3
Quiet period: 60 seconds
Transmit period: 30 seconds
Mac Radius: Enabled
Mac Radius Restrict: Disabled
Reauthentication: Enabled
Configured Reauthentication interval: 3600 seconds
Supplicant timeout: 30 seconds
Server timeout: 30 seconds
Maximum EAPOL requests: 2
Guest VLAN member: <not configured>
Number of connected supplicants: 1
Supplicant: user101, 00:04:0f:fd:ac:fe
Operational state: Authenticated
Authentication method: Radius
Authenticated VLAN: vo11
Dynamic Filter: match source-dot1q-tag 10 action deny
Session Reauth interval: 60 seconds
Reauthentication due in 50 seconds

user@switch> show dot1x interface ge-0/0/20.0 detail

ge-0/0/20.0
Role: Authenticator
Administrative state: Auto
Supplicant mode: Single
Number of retries: 3
Quiet period: 60 seconds
Transmit period: 30 seconds
Mac Radius: Enabled
Mac Radius Restrict: Enabled
Reauthentication: Enabled
Configured Reauthentication interval: 3600 seconds
Supplicant timeout: 30 seconds
Server timeout: 30 seconds
Maximum EAPOL requests: 2
Guest VLAN member: <not configured>
Number of connected supplicants: 1
Supplicant: user102, 00:04:ae:cd:23:5f
Operational state: Authenticated
 399

Authentcation method: Radius

Authenticated VLAN: vo11
Dynamic Filter: match source-dot1q-tag 10 action deny
Session Reauth interval: 60 seconds
Reauthentication due in 50 seconds

Meaning
The sample output from the show dot1x interface detail command displays the MAC address of the
connected end device in the Supplicant field. On interface ge-0/0/19, the MAC address is 00:04:0f:fd:ac:fe,
which is the MAC address of the first printer configured for MAC RADIUS authentication. The
Authentication method field displays the authentication method as Radius. On interface ge-0/0/20, the
MAC address is 00:04:ae:cd:23:5f, which is the MAC address of the second printer configured for MAC
RADIUS authentication. The Authentication method field displays the authentication method as Radius.

RELATED DOCUMENTATION

Interfaces Enabled for 802.1X or MAC RADIUS Authentication | 420

Static MAC Bypass of 802.1X and MAC RADIUS Authentication | 441

802.1X and RADIUS Accounting

IN THIS SECTION

Understanding 802.1X and RADIUS Accounting on Switches | 400

Configuring 802.1X RADIUS Accounting (CLI Procedure) | 403

EX Series Switches support RADIUS accounting. You can configure RADIUS accounting on an EX Series
switch to collect statistical data about users logging in to or out of a LAN and send that data to a RADIUS
accounting server. The data gathered is used for network monitoring purpose.
 400

Understanding 802.1X and RADIUS Accounting on Switches

IN THIS SECTION

RADIUS Accounting Process | 400

Supported RADIUS Attributes | 401

Juniper Networks EX Series Ethernet Switches support IETF RFC 2866, RADIUS Accounting. By configuring
RADIUS accounting on an EX Series switch, you can collect statistical data about users logging in to or out
of a LAN and send that data to a RADIUS accounting server. The statistical data gathered can be used to
perform general network monitoring, to analyze and track usage patterns, or to bill a user based on the
amount of time or type of services accessed.

RADIUS Accounting Process

RADIUS accounting is based on a client/server model in which the switch, operating as the network access
server (NAS), is the client. The client forwards user accounting statistics to a designated RADIUS accounting
server. The RADIUS accounting server must send a response to the client when it has successfully received
and recorded the accounting statistics.

The RADIUS accounting process between a switch and a RADIUS server is based on the exchange of two
types of RADIUS messages—Accounting-Request and Accounting-Response. Accounting-Request messages
are sent from the switch to the server and convey information used to account for a service provided to
a user. Accounting-Response messages are sent from the server to acknowledge receipt of the
Accounting-Request packets. The exchange of messages between the switch and the server proceeds as
follows:

1. A RADIUS accounting server listens for User Datagram Protocol (UDP) packets on a specific port. For
example, on FreeRADIUS, the default port is 1813.

2. When a supplicant is authenticated through 802.1X authentication and then connected to the LAN,
the switch forwards an Accounting-Request message with a record of the event to the accounting
server. The Accounting-Request message sent by the switch includes the RADIUS attribute
Acct-Status-Type with a value of Start, which indicates the beginning of user service for this supplicant.
The accounting server records this event in the accounting log file as a start record.

3. The accounting server sends an Accounting-Response message back to the switch confirming that it
received the accounting request. If the switch does not receive a response from the server, it continues
to send accounting requests until an accounting response is returned from the accounting server.
 401

4. The switch might send an interim message to the accounting server to periodically update the server
with information pertaining to a specific session. Interim messages are sent as Accounting-Request
messages with the Acct-Status-Type attribute value of Interim-Update. The accounting server sends
an Accounting-Response messae back to the switch to confirm receipt of an interim update.

5. When the supplicant's session ends, the switch forwards an Accounting-Request message with the
Acct-Status-Type attribute value set to Stop, indicating the end of user service. The accounting server
records this event in the accounting log file as a stop record that contains session information and the
length of the session.

The statistics collected through this process can be displayed from the RADIUS server. To view those
statistics, the user needs to access the accounting log file configured to receive them. On FreeRADIUS,
the filename is the server's address—for example, 122.69.1.250.

Supported RADIUS Attributes

RADIUS accounting statistics are conveyed through the attributes included in each Accounting-Request
message sent from the NAS to the server. Table 28 on page 401 list the RADIUS attributes supported for
Accounting-Request messages.

Table 28: RADIUS Accounting Request Attributes

Type Attribute Description

1 User-Name The name of the authenticated user.

5 NAS-Port The physical port number of the NAS that authenticates the user. Either
NAS-Port or NAS-Port-ID must be contained in the packet.

8 Framed-IP-Address The IP address of the authenticated user.

NOTE: The Framed-IP-Address attribute is sent only if a valid DHCP

binding exists for the host in the DHCP snooping table.

11 Filter-ID The name of the filter list for the user.

12 Framed-MTU The maximum transmission unit that can be configured for the user.

26 Client-System-Name Vendor-specific attribute (VSA) used to indicate the client’s hostname.

Supported for LLDP-capable devices only.

27 Session-Timeout Sets the maximum time (in seconds) that a session stays active before it
terminates or a prompt is issued notifying its termination.
 402

Table 28: RADIUS Accounting Request Attributes (continued)

Type Attribute Description

28 Idle-Timeout The maximum number of consecutive seconds of idle connection allowed

to the user before termination of the session or prompt.

30 Called-Station-ID Enables the NAS to identify the phone number that the user called, using
Dialed Number Identification (DNIS) or a similar technology.

31 Calling-Station-ID Enables the NAS to identify the phone number that the call came from,
using Automatic Number Identification (ANI) or a similar technology.

32 NAS-Identifier Contains a string identifying the NAS originating the Accounting-Request

message.

40 Acct-Status-Type Indicates whether this Accounting-Request message marks the beginning

(Start) or the end (Stop) of the user session. Can also be used for an
interim update (Interim-Update).

44 Acct-Session-ID A unique ID for a specific accounting session that can be used to match
start and stop records for a session in the log file.

45 Acct-Authentic Indicates whether the user was authenticated locally, by the RADIUS
server, or by another remote authentication protocol.

55 Event-Timestamp Records the time an event occurred.

87 NAS-Port-ID Text string that identifies the port that authenticates the user. Either
NAS-Port or NAS-Port-ID must be present in the packet.

SEE ALSO

802.1X for Switches Overview | 352

Example: Connecting a RADIUS Server for 802.1X to an EX Series Switch | 365
Configuring 802.1X RADIUS Accounting (CLI Procedure) | 403
 403

Configuring 802.1X RADIUS Accounting (CLI Procedure)

RADIUS accounting enables statistical data about users logging in to or out of a LAN to be collected and
sent to a RADIUS accounting server. The statistical data gathered can be used to perform general network
monitoring, to analyze and track usage patterns, or to bill a user based upon the amount of time or type
of services accessed.

RADIUS accounting is based on a client/server model in which the switch, operating as the network access
server (NAS), is the client. The client is responsible for forwarding user accounting statistics to a designated
RADIUS accounting server. To configure RADIUS accounting, specify one or more RADIUS accounting
servers to receive the statistical data from the switch, and select the type of accounting data to be collected.

The RADIUS accounting server you specify can be the same server used for RADIUS authentication, or it
can be a separate RADIUS server. You can specify a list of RADIUS accounting servers. If the primary
server (the first one configured) is unavailable, then each RADIUS server in the list is tried in the order in
which the servers are configured in Junos OS.

To configure RADIUS accounting by using the CLI:

1. Configure an access profile and specify the accounting servers to which the switch forwards accounting
statistics:

[edit access]
user@switch# set profile profile-name radius accounting-server [server-addresses]

2. Define the address of RADIUS accounting servers and configure the secret password (the secret
password on the switch must match the secret password on the server):

[edit access]
user@switch# set radius-server server-address secret password

3. Enable accounting for the access profile:

[edit access]
user@switch# set profile profile-name accounting

4. Configure the accounting order, making RADIUS the first method for sending accounting messages
and updates:

[edit access]
user@switch# set profile profile-name accounting order radius

5. Configure the statistics to be collected on the switch and forwarded to the accounting server:

[edit access]
 404

user@switch# set profile profile-name accounting accounting-stop-on-access-deny

user@switch# set profile profile-name accounting accounting-stop-on-failure

6. (Optional) Configure the switch to send periodic updates for a user session at a specified interval to
the accounting server:

[edit access]
user@switch# set profile profile-name accounting update-interval minutes

7. Display accounting statistics collected on the switch using the show network-access aaa statistics
accounting command, for example:

user@switch> show network-access aaa statistics accounting

Accounting module statistics

Requests received: 1
Accounting Response failures: 0
Accounting Response Success: 1
Requests timedout: 0

8. Open an accounting log on the RADIUS accounting server by using the server's address, and view
accounting statistics, for example:

[root@freeradius]# cd /usr/local/var/log/radius/radacct/192.168.0.1
[root@freeradius 192.168.0.1]# ls

detail-20071214

[root@freeradius 192.168.0.1]# vi details-20071214

User-Name = "000347e1bab9"
NAS-Port = 67
Acct-Status-Type = Stop
Acct-Session-Id = "8O2.1x811912"
Acct-Input-Octets = 17454
Acct-Output-Octets = 4245
Acct-Session-Time = 1221041249
Acct-Input-Packets = 72
Acct-Output-Packets = 53
Acct-Terminate-Cause = Lost-Carrier
Acct-Input-Gigawords = 0
 405

Acct-Output-Gigawords = 0
Called-Station-Id = "00-19-e2-50-52-60"
Calling-Station-Id = "00-03-47-e1-ba-b9"
Event-Timestamp = "Sep 10 2008 16:52:39 PDT"
NAS-Identifier = "esp48t-1b-01"
NAS-Port-Type = Virtual

User-Name = "000347e1bab9"
NAS-Port = 67
Acct-Status-Type = Start
Acct-Session-Id = "8O2.1x811219"
Called-Station-Id = "00-19-e2-50-52-60"
Calling-Station-Id = "00-03-47-e1-ba-b9"
Event-Timestamp = "Sep 10 2008 18:58:52 PDT"
NAS-Identifier = "esp48t-1b-01"
NAS-Port-Type = Virtual

SEE ALSO

Example: Connecting a RADIUS Server for 802.1X to an EX Series Switch | 365

RELATED DOCUMENTATION

RADIUS Server Configuration for Authentication | 343

Example: Setting Up 802.1X for Single-Supplicant or

Multiple-Supplicant Configurations on an EX Series
Switch

IN THIS SECTION

Requirements | 406

Overview and Topology | 407

 406

Configuration of 802.1X to Support Multiple Supplicant Modes | 409

Verification | 411

802.1x port-based network access control (PNAC) authentication on EX Series switches provides three
types of authentication to meet the access needs of your enterprise LAN:

• Authenticate the first end device (supplicant) on an authenticator port, and allow all other end devices
also connecting to have access to the LAN.

• Authenticate only one end device on an authenticator port at one time.

• Authenticate multiple end devices on an authenticator port. Multiple supplicant mode is used in VoIP
configurations.

This example configures an EX Series switch to use IEEE 802.1X to authenticate end devices that use three
different administrative modes.

Requirements

This example uses the following software and hardware components:

NOTE: This example also applies to QFX5100 switches.

• Junos OS Release 9.0 or later for EX Series switches

• One EX Series switch acting as an authenticator port access entity (PAE). The ports on the authenticator
PAE form a control gate that blocks all traffic to and from end devices until they are authenticated.

• One RADIUS authentication server that supports 802.1X. The authentication server acts as the backend
database and contains credential information for end devices (supplicants) that have permission to
connect to the network.

Before you configure the ports for 802.1X authentication, be sure you have:

• Performed the initial switch configuration. See Connecting and Configuring an EX Series Switch (CLI
Procedure).

• Performed basic bridging and VLAN configuration on the switch. See the documentation that describes
setting up basic bridging and a VLAN for your switch. If you are using a switch that supports the Enhanced
Layer 2 Software (ELS) configuration style, see Example: Setting Up Basic Bridging and a VLAN for an EX
 407

Series Switch with ELS Support or Example: Setting Up Basic Bridging and a VLAN on Switches. For all other
switches, see Example: Setting Up Basic Bridging and a VLAN for an EX Series Switch.

NOTE: For more about ELS, see Using the Enhanced Layer 2 Software CLI.

• Configured users on the authentication server.

Overview and Topology

As shown in Figure 11 on page 408, the topology contains an EX4200 access switch connected to the
authentication server on port ge-0/0/10. Interfaces ge-0/0/8, ge-0/0/9, and ge-0/0/11 will be configured
for three different administrative modes.

NOTE: This figure also applies to QFX5100 switches.

 408

Figure 11: Topology for Configuring Supplicant Modes

 409

Table 29: Components of the Supplicant Mode Configuration Topology

Property Settings

Switch hardware EX4200 switch, 24 Gigabit Ethernet ports: 8 PoE ports

(ge-0/0/0 through ge-0/0/7) and 16 non-PoE ports (ge-0/0/8
through ge-0/0/23)

Connections to Avaya phones—with integrated hub, ge-0/0/8, ge-0/0/9, and ge-0/0/11

to connect phone and desktop PC to a single port;
(requires PoE)

To configure the administrative modes to support supplicants in different areas of the Enterprise network:

• Configure access port ge-0/0/8 for single supplicant mode authentication.

• Configure access port ge-0/0/9 for single secure supplicant mode authentication.

• Configure access port ge-0/0/11 for multiple supplicant mode authentication.

Single supplicant mode authenticates only the first end device that connects to an authenticator port. All
other end devices connecting to the authenticator port after the first has connected successfully, whether
they are 802.1X-enabled or not, are permitted access to the port without further authentication. If the
first authenticated end device logs out, all other end devices are locked out until an end device authenticates.

Single-secure supplicant mode authenticates only one end device to connect to an authenticator port. No
other end device can connect to the authenticator port until the first logs out.

Multiple supplicant mode authenticates multiple end devices individually on one authenticator port. If you
configure a maximum number of devices that can be connected to a port through port security, the lesser
of the configured values is used to determine the maximum number of end devices allowed per port.

Configuration of 802.1X to Support Multiple Supplicant Modes

CLI Quick Configuration
To quickly configure the ports with different 802.1X authentication modes, copy the following commands
and paste them into the switch terminal window:

[edit]
set protocols dot1x authenticator interface ge-0/0/8 supplicant single

set protocols dot1x authenticator interface ge-0/0/9 supplicant single-secure

set protocols dot1x authenticator interface ge-0/0/11 supplicant multiple

 410

Step-by-Step Procedure
Configure the administrative mode on the interfaces:

1. Configure the supplicant mode as single on interface ge-0/0/8:

[edit protocols]
user@switch# set dot1x authenticator interface ge-0/0/8 supplicant single

2. Configure the supplicant mode as single secure on interface ge-0/0/9:

[edit protocols]
user@switch# set dot1x authenticator interface ge-0/0/9 supplicant single-secure

3. Configure multiple supplicant mode on interface ge-0/0/11:

[edit protocols]
user@switch# set dot1x authenticator interface ge-0/0/11 supplicant multiple

Results

Check the results of the configuration:

[edit]
user@access-switch> show configuration
protocols {
dot1x {
authenticator {
interface {
ge-0/0/8.0 {
supplicant single;
)
ge-0/0/9.0 {
supplicant single-secure;
)
ge-0/0/11.0 {
supplicant multiple;
)
}
}
}
}
 411

Verification

IN THIS SECTION

Verifying the 802.1X Configuration | 411

To confirm that the configuration is working properly, perform these tasks:

Verifying the 802.1X Configuration

Purpose
Verify the 802.1X configuration on interfaces ge-0/0/8, ge-0/0/9, and ge-0/0/5.

Action

Verify the 802.1X configuration by issuing the operational mode command show dot1x interface:

user@switch> show dot1x interface ge-0/0/8.0 detail

ge-0/0/8.0
Role: Authenticator
Administrative state: Auto
Supplicant mode: Single
Number of retries: 3
Quiet period: 60 seconds
Transmit period: 30 seconds
Mac Radius: Disabled
Mac Radius Restrict: Disabled
Reauthentication: Enabled
Configured Reauthentication interval: 3600 seconds
Supplicant timeout: 30 seconds
Server timeout: 30 seconds
Maximum EAPOL requests: 2
Guest VLAN member: <not configured>

user@switch> show dot1x interface ge-0/0/9.0 detail

ge-0/0/9.0
Role: Authenticator
 412

Administrative state: Auto

Supplicant mode: Single-Secure
Number of retries: 3
Quiet period: 60 seconds
Transmit period: 30 seconds
Mac Radius: Disabled
Mac Radius Restrict: Disabled
Reauthentication: Enabled
Configured Reauthentication interval: 3600 seconds
Supplicant timeout: 30 seconds
Server timeout: 30 seconds
Maximum EAPOL requests: 2
Guest VLAN member: <not configured>
Number of connected supplicants: 0

user@switch> show dot1x interface ge-0/0/11.0 detail

ge-0/0/11.0
Role: Authenticator
Administrative state: Auto
Supplicant mode: Multiple
Number of retries: 3
Quiet period: 60 seconds
Transmit period: 30 seconds
Mac Radius: Disabled
Mac Radius Restrict: Disabled
Reauthentication: Enabled
Configured Reauthentication interval: 3600 seconds
Supplicant timeout: 30 seconds
Server timeout: 30 seconds
Maximum EAPOL requests: 2
Guest VLAN member: <not configured>
Number of connected supplicants: 0

Meaning
The Supplicant mode output field displays the configured administrative mode for each interface. Interface
ge-0/0/8.0 displays Single supplicant mode. Interface ge-0/0/9.0 displays Single-Secure supplicant mode.
Interface ge-0/0/11.0 displays Multiple supplicant mode.

RELATED DOCUMENTATION
 413

Controlling Authentication Session Timeouts (CLI Procedure) | 336

Example: Connecting a RADIUS Server for 802.1X to an EX Series Switch | 365
Example: Setting Up 802.1X in Conference Rooms to Provide Internet Access to Corporate Visitors
on an EX Series Switch | 413
Example: Setting Up VoIP with 802.1X and LLDP-MED on an EX Series Switch | 492
Configuring 802.1X RADIUS Accounting (CLI Procedure) | 403
Filtering 802.1X Supplicants by Using RADIUS Server Attributes | 360
Understanding Authentication on Switches | 326

Example: Setting Up 802.1X in Conference Rooms to

Provide Internet Access to Corporate Visitors on an
EX Series Switch

IN THIS SECTION

Requirements | 414

Overview and Topology | 414

Configuration of a Guest VLAN That Includes 802.1X Authentication | 416

Verification | 417

802.1X on EX Series switches provides LAN access to users who do not have credentials in the RADIUS
database. These users, referred to as guests, are authenticated and typically provided with access to the
Internet.

This example describes how to create a guest VLAN and configure 802.1X authentication for it.
 414

Requirements

This example uses the following software and hardware components:

NOTE: This example also applies to QFX5100 switches.

• Junos OS Release 9.0 or later for EX Series switches

• One EX Series switch acting as a port access entity (PAE). The interfaces on the authenticator PAE form
a control gate that blocks all traffic to and from supplicants until they are authenticated.

• One RADIUS authentication server that supports 802.1X. The authentication server acts as the backend
database and contains credential information for hosts (supplicants) that have permission to connect to
the network.

Before you configure guest VLAN authentication, be sure you have:

• Performed the initial switch configuration. See Connecting and Configuring an EX Series Switch (CLI
Procedure).

• Performed basic bridging and VLAN configuration on the switch. See the documentation that describes
setting up basic bridging and a VLAN for your switch. If you are using a switch that supports the Enhanced
Layer 2 Software (ELS) configuration style, see Example: Setting Up Basic Bridging and a VLAN for an EX
Series Switch with ELS Support or Example: Setting Up Basic Bridging and a VLAN on Switches. For all other
switches, see Example: Setting Up Basic Bridging and a VLAN for an EX Series Switch.

NOTE: For more about ELS, see: Using the Enhanced Layer 2 Software CLI

Overview and Topology

As part of IEEE 802.1X port-based network access control (PNAC), you can provide limited network access
to supplicants who do not belong to a VLAN authentication group by configuring authentication for a
guest VLAN. Typically, guest VLAN access is used to provide Internet access to visitors to a corporate site.
However, you can also use the guest VLAN feature to provide access to a VLAN with limited resources
to supplicants that fail 802.1X authentication on a corporate LAN.

NOTE: This figure also applies to QFX5100 switches.

 415

Figure 12 on page 415 shows the conference room connected to the switch at interface ge-0/0/1.

Figure 12: Topology for Guest VLAN Example

 416

Table 30: Components of the Guest VLAN Topology

Property Settings

Switch hardware EX4200 switch, 24 Gigabit Ethernet interfaces: 8 PoE interfaces (ge-0/0/0
through ge-0/0/7) and 16 non-PoE interfaces (ge-0/0/8 through ge-0/0/23)

VLAN names and tag IDs sales, tag 100

support, tag 200

guest-vlan, tag 300

One RADIUS server Backend database connected to the switch through interface ge-0/0/10

In this example, access interface ge-0/0/1 provides LAN connectivity in the conference room. Configure
this access interface to provide LAN connectivity to visitors in the conference room who are not
authenticated by the corporate VLAN.

Configuration of a Guest VLAN That Includes 802.1X Authentication

CLI Quick Configuration
To quickly configure a guest VLAN, with 802.1X authentication, copy the following commands and paste
them into the switch terminal window:

[edit]

set vlans guest-vlan vlan-id 300

set protocols dot1x authenticator interface all guest-vlan guest-vlan

Step-by-Step Procedure
To configure a guest VLAN that includes 802.1X authentication on an EX Series switch:

1. Configure the VLAN ID for the guest VLAN:

[edit]
user@switch# set vlans guest-vlan vlan-id 300

2. Configure the guest VLAN under dot1x protocol:

[edit]
user@switch# set protocols dot1x authenticator interface all guest-vlan guest-vlan
 417

Results
Check the results of the configuration:

user@switch> show configuration

protocols {
dot1x {
authenticator {
interface {
all {
guest-vlan {
guest-vlan;
}
}
}
}
}
}
vlans {
guest-vlan {
vlan-id 300;
}
}

Verification

IN THIS SECTION

Verifying That the Guest VLAN Is Configured | 417

To confirm that the configuration is working properly, perform these tasks:

Verifying That the Guest VLAN Is Configured

Purpose
Verify that the guest VLAN is created and that an interface has failed authentication and been moved to
the guest VLAN.
 418

NOTE: On switches running Junos OS for EX Series with support for ELS, the output for the
show vlans command will contain additional information. If your switch runs software that
supports ELS, see show vlans. For ELS details, see Using the Enhanced Layer 2 Software CLI.

Action

Issue the operational mode commands:

user@switch> show vlans

Name Tag Interfaces

default
ge-0/0/3.0*
dynamic 40
None
guest 30
None
guest—vlan 300
ge-0/0/1.0*
vlan_dyn
None

user@switch> show dot1x interface ge-0/0/1.0 detail

ge-0/0/1.0
Role: Authenticator
Administrative state: Auto
Supplicant mode: Single
Number of retries: 3
Quiet period: 60 seconds
Transmit period: 30 seconds
Mac Radius: Enabled
Mac Radius Restrict: Disabled
Reauthentication: Enabled
Configured Reauthentication interval: 3600 seconds
Supplicant timeout: 30 seconds
Server timeout: 30 seconds
Maximum EAPOL requests: 2
Guest VLAN member: guest-vlan
 419

Number of connected supplicants: 1

Supplicant: user1, 00:00:00:00:13:23
Operational state: Authenticated
Authentication method: Radius
Authenticated VLAN: vo11
Dynamic Filter: match source-dot1q-tag 10 action deny
Session Reauth interval: 60 seconds
Reauthentication due in 50 seconds

Meaning
The output of the show vlans command shows guest-vlan as the the name of the VLAN and the VLAN ID
as 300.

The output of the show dot1x interface ge-0/0/1.0 detail command displays the Guest VLAN membership
field, indicating that a supplicant at this interface failed 802.1X authentication and was passed through to
the guest-vlan.

RELATED DOCUMENTATION

Example: Connecting a RADIUS Server for 802.1X to an EX Series Switch | 365

Example: Setting Up 802.1X for Single-Supplicant or Multiple-Supplicant Configurations on an EX
Series Switch | 405
Example: Setting Up VoIP with 802.1X and LLDP-MED on an EX Series Switch | 492
Configuring 802.1X Interface Settings (CLI Procedure) | 355
 420

Interfaces Enabled for 802.1X or MAC RADIUS

Authentication

IN THIS SECTION

Example: Applying a Firewall Filter to 802.1X-Authenticated Supplicants by Using RADIUS Server Attributes
on an EX Series Switch | 420

Example: Applying Firewall Filters to Multiple Supplicants on Interfaces Enabled for 802.1X or MAC RADIUS
Authentication | 428

Example: Applying Firewall Filters to Multiple Supplicants on Interfaces Enabled for 802.1X or MAC RADIUS
Authentication on EX Series Switches with ELS Support | 435

EX Series switches support port firewall filters. Port firewall filters are configured on a single EX Series
switch, but in order for them to operate throughout an enterprise, they must be configured on multiple
switches. To reduce the need to configure the same port firewall filter on multiple switches, you can instead
apply the filter centrally on the RADIUS server by using RADIUS server attributes. Terms are applied after
a device is successfully authenticated through 802.1X. For more information, read this topic.

Example: Applying a Firewall Filter to 802.1X-Authenticated Supplicants

by Using RADIUS Server Attributes on an EX Series Switch

IN THIS SECTION

Requirements | 421

Overview and Topology | 422

Configuring the Port Firewall Filter and Counters | 424

Applying the Port Firewall Filter to the Supplicant User Profiles on the RADIUS Server | 426

Verification | 427

You can use RADIUS server attributes and a port firewall filter to centrally apply terms to multiple supplicants
(end devices) connected to an EX Series switch in your enterprise. Terms are applied after a device is
 421

successfully authenticated through 802.1X. If the firewall filter configuration is modified after end devices
are authenticated using the 802.1X authentication, then the established 802.1X authentication session
must be terminated and re-established for the firewall filter changes to take effect.

EX Series switches support port firewall filters. Port firewall filters are configured on a single EX Series
switch, but in order for them to operate throughout an enterprise, they must be configured on multiple
switches. To reduce the need to configure the same port firewall filter on multiple switches, you can instead
apply the filter centrally on the RADIUS server by using RADIUS server attributes.

The following example uses FreeRADIUS to apply a port firewall filter on a RADIUS server. For information
about configuring your server, consult the documentation that was included with your RADIUS server.

This example describes how to configure a port firewall filter with terms, create counters to count packets
for the supplicants, apply the filter to user profiles on the RADIUS server, and display the counters to
verify the configuration:

Requirements

This example uses the following software and hardware components:

NOTE: This example also applies to QFX5100 switches.

• Junos OS Release 9.3 or later for EX Series switches

• One EX Series switch acting as an authenticator port access entity (PAE). The ports on the authenticator
PAE form a control gate that blocks all traffic to and from supplicants until they are authenticated.

• One RADIUS authentication server. The authentication server acts as the backend database and contains
credential information for hosts (supplicants) that have permission to connect to the network.

Before you connect the server to the switch, be sure you have:

• Set up a connection between the switch and the RADIUS server. See “Example: Connecting a RADIUS
Server for 802.1X to an EX Series Switch” on page 365.

• Configured 802.1X authentication on the switch, with the supplicant mode for interface ge-0/0/2 set
to multiple. See “Configuring 802.1X Interface Settings (CLI Procedure)” on page 355 and “Example:
Setting Up 802.1X for Single-Supplicant or Multiple-Supplicant Configurations on an EX Series Switch”
on page 405.

• Configured users on the RADIUS authentication server (in this example, the user profiles for Supplicant
1 and Supplicant 2 in the topology are modified on the RADIUS server).
 422

Overview and Topology

When the 802.1X configuration on an interface is set to multiple supplicant mode, you can apply a single
port firewall filter configured through the Junos OS CLI on the EX Series switch to any number of end
devices (supplicants) by adding the filter centrally to the RADIUS server. Only a single filter can be applied
to an interface; however, the filter can contain multiple terms for separate end devices.

For more information about firewall filters, see Firewall Filters for EX Series Switches Overview or Overview
of Firewall Filters.

RADIUS server attributes are applied to the port where the end device is connected after the device is
successfully authenticated using 802.1X. To authenticate an end device, the switch forwards the end
device’s credentials to the RADIUS server. The RADIUS server matches the credentials against preconfigured
information about the supplicant located in the supplicant’s user profile on the RADIUS server. If a match
is found, the RADIUS server instructs the switch to open an interface to the end device. Traffic then flows
from and to the end device on the LAN. Further instructions configured in the port firewall filter and added
to the end device’s user profile using a RADIUS server attribute further define the access that the end
device is granted. Filtering terms configured in the port firewall filter are applied to the port where the
end device is connected after 802.1X authentication is complete.

NOTE: If you modify the port firewall filter after an end device is successfully authenticated
using 802.1X, you must terminate and re-establish the 802.1X authentication session for the
firewall filter configuration changes to be effective.

Figure 13 on page 423 shows the topology used for this example. The RADIUS server is connected to an
EX4200 switch on access port ge-0/0/10. Two end devices (supplicants) are accessing the LAN on interface
ge-0/0/2. Supplicant 1 has the MAC address 00:50:8b:6f:60:3a. Supplicant 2 has the MAC address
00:50:8b:6f:60:3b.

NOTE: This figure also applies to QFX5100 switches.

 423

Figure 13: Topology for Firewall Filter and RADIUS Server Attributes Configuration

Table 31 on page 423 describes the components in this topology.

Table 31: Components of the Firewall Filter and RADIUS Server Attributes Topology

Property Settings

Switch hardware EX4200 access switch, 24 Gigabit Ethernet ports: 16 non-PoE ports
and 8 PoE ports.

One RADIUS server Backend database with the address 10.0.0.100 connected to the
switch at port ge-0/0/10.
 424

Table 31: Components of the Firewall Filter and RADIUS Server Attributes Topology (continued)

Property Settings

802.1X supplicants connected to the switch • Supplicant 1 has MAC address 00:50:8b:6f:60:3a.
on interface ge-0/0/2 • Supplicant 2 has MAC address 00:50:8b:6f:60:3b.

Port firewall filter to be applied on the filter1

RADIUS server

Counters counter1 counts packets from Supplicant 1, and counter2 counts

packets from Supplicant 2.

Policer policer p1

User profiles on the RADIUS server • Supplicant 1 has the user profile supplicant1.
• Supplicant 2 has the user profile supplicant2.

In this example, you configure a port firewall filter named filter1. The filter contains terms that will be
applied to the end devices based on the MAC addresses of the end devices. When you configure the filter,
you also configure the counters counter1 and counter2. Packets from each end device are counted, which
helps you verify that the configuration is working. Policer p1 limits the traffic rate based on the values for
exceeding and discard parameters. Then, you check to see that the RADIUS server attribute is available
on the RADIUS server and apply the filter to the user profiles of each end device on the RADIUS server.
Finally, you verify the configuration by displaying output for the two counters.

Configuring the Port Firewall Filter and Counters

CLI Quick Configuration

To quickly configure a port firewall filter with terms for Supplicant 1 and Supplicant 2 and create parallel
counters for each supplicant, copy the following commands and paste them into the switch terminal
window:

[edit]

set firewall family ethernet-switching filter filter1 term supplicant1 from source-mac-address
00:50:8b:6f:60:3a

set firewall family ethernet-switching filter filter1 term supplicant2 from source-mac-address
00:50:8b:6f:60:3b

set firewall policer p1 if-exceeding bandwidth-limit 1m

set firewall policer p1 if-exceeding burst-size-limit 1k

set firewall policer p1 then discard

 425

set firewall family ethernet-switching filter filter1 term supplicant1 then count counter1

set firewall family ethernet-switching filter filter1 term supplicant1 then policer p1

set firewall family ethernet-switching filter filter1 term supplicant2 then count counter2

Step-by-Step Procedure
To configure a port firewall filter and counters on the switch:

1. Configure a port firewall filter (here, filter1) with terms for each end device based on the MAC address
of each end device:

[edit firewall family ethernet-switching]

user@switch# set filter filter1 term supplicant1 from source-mac-address 00:50:8b:6f:60:3a
user@switch# set filter filter1 term supplicant2 from source-mac-address 00:50:8b:6f:60:3b

2. Set policer definition:

[edit]
user@switch# set firewall policer p1 if-exceeding bandwidth-limit 1m
user@switch# set firewall policer p1 if-exceeding burst-size-limit 1k
user@switch# set firewall policer p1 then discard

3. Create two counters that will count packets for each end device and a policer that limits the traffic
rate:

[edit firewall family ethernet-switching]

user@switch# set filter filter1 term supplicant1 then count counter1
user@switch# set filter filter1 term supplicant1 then policer p1
user@switch# set filter filter1 term supplicant2 then count counter2

Results
Display the results of the configuration:

user@switch> show configuration

firewall {
family ethernet-switching {
filter filter1 {
term supplicant1 {
from {
source-mac-address {
00:50:8b:6f:60:3a;
 426

}
}
then count counter1;
then policer p1;
}
term supplicant2 {
from {
source-mac-address {
00:50:8b:6f:60:3b;
}
}
then count counter2;
}
}
}
}
policer p1 {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 1k;
}
then discard;
}

Applying the Port Firewall Filter to the Supplicant User Profiles on the RADIUS Server

Step-by-Step Procedure
To verify that the RADIUS server attribute Filter-ID is on the RADIUS server and to apply the filter to the
user profiles:

1. Display the dictionary dictionary.rfc2865 on the RADIUS server, and verify that the attribute Filter-ID
is in the dictionary:

[root@freeradius]# cd usr/share/freeradius/dictionary.rfc2865

2. Close the dictionary file.

3. Display the local user profiles of the end devices to which you want to apply the filter (here, the user
profiles are called supplicant1 and supplicant2):

[root@freeradius]# cat /usr/local/etc/raddb/users

The output shows:
 427

supplicant1 Auth-Type := EAP, User-Password == "supplicant1"

Tunnel-Type = VLAN,
Tunnel-Medium-Type = IEEE-802,
Tunnel-Private-Group-Id = "1005"

supplicant2 Auth-Type := EAP, User-Password == "supplicant2"

Tunnel-Type = VLAN,
Tunnel-Medium-Type = IEEE-802,
Tunnel-Private-Group-Id = "1005"

4. Apply the filter to both user profiles by adding the line Filter-Id = “filter1” to each profile, and then
close the file:

[root@freeradius]# cat /usr/local/etc/raddb/users

After you paste the line into the files, the files look like this:

supplicant1 Auth-Type := EAP, User-Password == "supplicant1"

Tunnel-Type = VLAN,
Tunnel-Medium-Type = IEEE-802,
Tunnel-Private-Group-Id = "1005",
Filter-Id = "filter1"

supplicant2 Auth-Type := EAP, User-Password == "supplicant2"

Tunnel-Type = VLAN,
Tunnel-Medium-Type = IEEE-802,
Tunnel-Private-Group-Id = "1005",
Filter-Id = "filter1"

Verification

Verifying That the Filter Has Been Applied to the Supplicants

Purpose
After the end devices are authenticated on interface ge-0/0/2, verify that the filter has been configured
on the switch and includes the results for both supplicants:

Action

user@switch> show dot1x firewall

 428

Filter: dot1x-filter-ge-0/0/2
Counters
counter1_dot1x_ge-0/0/2_user1 100
counter2_dot1x_ge-0/0/2_user2 400

Meaning
The output of the show dot1x firewall command displays counter1 and counter2. Packets from User_1
are counted using counter1, and packets from User 2 are counted using counter2. The output displays
packets incrementing for both counters. The filter has been applied to both end devices.

SEE ALSO

Example: Setting Up 802.1X for Single-Supplicant or Multiple-Supplicant Configurations on an EX

Series Switch | 405
Example: Configuring Firewall Filters for Port, VLAN, and Router Traffic on EX Series Switches
Configuring 802.1X RADIUS Accounting (CLI Procedure) | 403
Understanding Authentication on Switches | 326
Understanding Dynamic Filters Based on RADIUS Attributes | 370

Example: Applying Firewall Filters to Multiple Supplicants on Interfaces

Enabled for 802.1X or MAC RADIUS Authentication

IN THIS SECTION

Requirements | 429

Overview and Topology | 429

Configuration | 431

Verification | 433

On EX Series switches, firewall filters that you apply to interfaces enabled for 802.1X or MAC RADIUS
authentication are dynamically combined with the per-user policies sent to the switch from the RADIUS
server. The switch uses internal logic to dynamically combine the interface firewall filter with the user
 429

policies from the RADIUS server and create an individualized policy for each of the multiple users or
nonresponsive hosts that are authenticated on the interface.

This example describes how dynamic firewall filters are created for multiple supplicants on an
802.1X-enabled interface (the same principles shown in this example apply to interfaces enabled for MAC
RADIUS authentication):

Requirements

This example uses the following hardware and software components:

• Junos OS Release 9.5 or later for EX Series switches

• One EX Series switch

• One RADIUS authentication server. The authentication server acts as the backend database and contains
credential information for hosts (supplicants) that have permission to connect to the network.

Before you apply firewall filters to an interface for use with multiple supplicants, be sure you have:

• Set up a connection between the switch and the RADIUS server. See “Example: Connecting a RADIUS
Server for 802.1X to an EX Series Switch” on page 365.

• Configured 802.1X authentication on the switch, with the authentication mode for interface ge-0/0/2
set to multiple. See “Configuring 802.1X Interface Settings (CLI Procedure)” on page 355 and “Example:
Setting Up 802.1X for Single-Supplicant or Multiple-Supplicant Configurations on an EX Series Switch”
on page 405.

• Configured users on the RADIUS authentication server.

Overview and Topology

When the 802.1X configuration on an interface is set to multiple supplicant mode, the system dynamically
combines interface firewall filter with the user policies sent to the switch from the RADIUS server during
authentication and creates separate terms for each user. Because there are separate terms for each user
authenticated on the interface, you can, as shown in this example, use counters to view the activities of
individual users that are authenticated on the same interface.

When a new user (or a nonresponsive host) is authenticated on an interface, the system adds a term to
the firewall filter associated with the interface, and the term (policy) for each user is associated with the
MAC address of the user. The term for each user is based on the user-specific filters set on the RADIUS
server and the filters configured on the interface. For example, as shown in Figure 14 on page 430, when
User1 is authenticated by the EX Series switch, the system creates the firewall filter dynamic-filter-example.
When User2 is authenticated, another term is added to the firewall filter, and so on.
 430

Figure 14: Conceptual Model: Dynamic Filter Updated for Each New User

This is a conceptual model of the internal process—you cannot access or view the dynamic filter.

NOTE: If the firewall filter on the interface is modified after the user (or nonresponsive host) is
authenticated, the modifications are not reflected in the dynamic filter unless the user is
reauthenticated.

In this example, you configure a firewall filter to count the requests made by each endpoint authenticated
on interface ge-0/0/2 to the file server, which is located on subnet 192.0.2.16/28, and set policer definitions
to rate limit the traffic. Figure 15 on page 431 shows the network topology for this example.
 431

Figure 15: Multiple Supplicants on an 802.1X-Enabled Interface Connecting to a File Server

Configuration

IN THIS SECTION

Configuring Firewall Filters on Interfaces with Multiple Supplicants | 431

To configure firewall filters for multiple supplicants on 802.1X-enabled interfaces:

Configuring Firewall Filters on Interfaces with Multiple Supplicants

CLI Quick Configuration

To quickly configure firewall filters for multiple supplicants on an 802.1X-enabled interface copy the
following commands and paste them into the switch terminal window:

[edit]

set protocols dot1x authenticator interface ge-0/0/2 supplicant multiple

 432

set firewall family ethernet-switching filter filter1 term term1 from destination-address 192.0.2.16/28

set firewall policer p1 if-exceeding bandwidth-limit 1m

set firewall policer p1 if-exceeding burst-size-limit 1k

set firewall family ethernet-switching filter filter1 term term1 then count counter1

set firewall family ethernet-switching filter filter1 term term2 then policer p1

Step-by-Step Procedure
To configure firewall filters on an interface enabled for multiple supplicants:

1. Configure interface ge-0/0/2 for multiple supplicant mode authentication:

[edit protocols dot1x]

user@switch# set authenticator interface ge-0/0/2 supplicant multiple

2. Set policer definition:

user@switch# show policer p1 |display set

set firewall policer p1 if-exceeding bandwidth-limit 1m
set firewall policer p1 if-exceeding burst-size-limit 1k
set firewall policer p1 then discard

3. Configure a firewall filter to count packets from each user and a policer that limits the traffic rate. As
each new user is authenticated on the multiple supplicant interface, this filter term will be included in
the dynamically created term for the user:

[edit firewall family ethernet-switching]

user@switch# set filter filter1 term term1 from destination-address 192.0.2.16/28
user@switch# set filter filter1 term term1 then count counter1
user@switch# set filter filter1 term term2 then policer p1

Results
Check the results of the configuration:

user@switch> show configuration

firewall {
family ethernet-switching {
filter filter1 {
term term1 {
 433

from {
destination-address {
192.0.2.16/28;
}
}
then count counter1;
term term2 {
from {
destination-address {
192.0.2.16/28;
}
}
then policer p1;
}
}
}
policer p1 {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 1k;
}
then discard;
}
}
protocols {
dot1x {
authenticator
interface ge-0/0/2 {
supplicant multiple;
}
}
}

Verification

IN THIS SECTION

Verifying Firewall Filters on Interfaces with Multiple Supplicants | 434

To confirm that the configuration is working properly, perform these tasks:

 434

Verifying Firewall Filters on Interfaces with Multiple Supplicants

Purpose
Verify that firewall filters are functioning on the interface with multiple supplicants.

Action
1. Check the results with one user authenticated on the interface. In this case, the user is authenticated
on ge-0/0/2:

user@switch> show dot1x firewall

Filter: dot1x_ge-0/0/2
Counters
counter1_dot1x_ge-0/0/2_user1 100

2. When a second user, User2, is authenticated on the same interface, ge-0/0/2, you can verify that the
filter includes the results for both of the users authenticated on the interface:

user@switch> show dot1x firewall

Filter: dot1x-filter-ge-0/0/0
Counters
counter1_dot1x_ge-0/0/2_user1 100
counter1_dot1x_ge-0/0/2_user2 400

Meaning
The results displayed by the show dot1x firewall command output reflect the dynamic filter created with
the authentication of each new user. User1 accessed the file server located at the specified destination
address 100 times, while User2 accessed the same file server 400 times.

SEE ALSO

Example: Configuring Firewall Filters for Port, VLAN, and Router Traffic on EX Series Switches
Filtering 802.1X Supplicants by Using RADIUS Server Attributes | 360
 435

Example: Applying Firewall Filters to Multiple Supplicants on Interfaces

Enabled for 802.1X or MAC RADIUS Authentication on EX Series Switches
with ELS Support

IN THIS SECTION

Requirements | 435

Overview and Topology | 436

Configuration | 438

Verification | 440

NOTE: This example uses Junos OS for EX Series switches with support for the Enhanced Layer
2 Software (ELS) configuration style. If your switch runs software that does not support ELS, see
“Example: Applying Firewall Filters to Multiple Supplicants on Interfaces Enabled for 802.1X or
MAC RADIUS Authentication” on page 428. For ELS details, see Using the Enhanced Layer 2
Software CLI.

On EX Series switches, firewall filters that you apply to interfaces enabled for 802.1X or MAC RADIUS
authentication are dynamically combined with the per-user policies sent to the switch from the RADIUS
server. The switch uses internal logic to dynamically combine the interface firewall filter with the user
policies from the RADIUS server and create an individualized policy for each of the multiple users or
nonresponsive hosts that are authenticated on the interface.

This example describes how dynamic firewall filters are created for multiple supplicants on an
802.1X-enabled interface (the same principles shown in this example apply to interfaces enabled for MAC
RADIUS authentication):

Requirements

This example uses the following software and hardware components:

NOTE: This example also applies to QFX5100 switches.

• Junos OS Release 13.2 or later for EX Series switches

 436

• One EX Series switch with support for ELS

• One RADIUS authentication server. The authentication server acts as the backend database and contains
credential information for hosts (supplicants) that have permission to connect to the network.

Before you apply firewall filters to an interface for use with multiple supplicants, be sure you have:

• Set up a connection between the switch and the RADIUS server. See “Example: Connecting a RADIUS
Server for 802.1X to an EX Series Switch” on page 365.

• Configured 802.1X authentication on the switch, with the authentication mode for the interface ge-0/0/2
set to multiple. See “Configuring 802.1X Interface Settings (CLI Procedure)” on page 355 and “Example:
Setting Up 802.1X for Single-Supplicant or Multiple-Supplicant Configurations on an EX Series Switch”
on page 405.

• Configured users on the RADIUS authentication server.

Overview and Topology

When the 802.1X configuration on an interface is set to multiple supplicant mode, the system dynamically
combines the interface firewall filter with the user policies sent to the switch from the RADIUS server
during authentication and creates separate terms for each user. Because there are separate terms for each
user authenticated on the interface, you can, as shown in this example, use counters to view the activities
of individual users that are authenticated on the same interface.

When a new user (or a nonresponsive host) is authenticated on an interface, the system adds a term to
the firewall filter associated with the interface, and the term (policy) for each user is associated with the
MAC address of the user. The term for each user is based on the user-specific filters set on the RADIUS
server and the filters configured on the interface. For example, as shown in Figure 16 on page 437, when
User 1 is authenticated by the EX Series switch, the system adds a term to the firewall filter
dynamic-filter-example. When User 2 is authenticated, another term is added to the firewall filter, and so
on.

NOTE: This figure also applies to QFX5100 switches.

 437

Figure 16: Conceptual Model: Dynamic Filter Updated for Each New User

This is a conceptual model of the internal process—you cannot access or view the dynamic filter.

NOTE: If the firewall filter on the interface is modified after the user (or nonresponsive host) is
authenticated, the modifications are not reflected in the dynamic filter unless the user is
reauthenticated.

In this example, you configure a firewall filter to count the requests made by each endpoint authenticated
on interface ge-0/0/2 to the file server, which is located on subnet 192.0.2.16/28, and set policer definitions
to rate-limit the traffic. Figure 17 on page 438 shows the network topology for this example.
 438

Figure 17: Multiple Supplicants on an 802.1X-Enabled Interface Connecting to a File Server

Configuration

Configuring Firewall Filters on Interfaces with Multiple Supplicants

CLI Quick Configuration

To quickly configure firewall filters for multiple supplicants on an 802.1X-enabled interface copy the
following commands and paste them into the switch terminal window:

[edit]

set firewall family ethernet-switching filter filter1 term term1 from ip-destination-address 192.0.2.16/28

set firewall family ethernet-switching filter filter1 term term2 from ip-destination-address 192.0.2.16/28

set firewall policer p1 if-exceeding bandwidth-limit 1m

set firewall policer p1 if-exceeding burst-size-limit 1500

set firewall policer p1 then discard

set firewall family ethernet-switching filter filter1 term term1 then count counter1

set firewall family ethernet-switching filter filter1 term term2 then policer p1
 439

Step-by-Step Procedure
To configure firewall filters on an interface enabled for multiple supplicants:

1. Set the policer definition:

user@switch# show policer p1 |display set

set firewall policer p1 if-exceeding bandwidth-limit 1m
set firewall policer p1 if-exceeding burst-size-limit 1500
set firewall policer p1 then discard

2. Configure a firewall filter to count packets from each user and a policer that limits the traffic rate. As
each new user is authenticated on the multiple supplicant interface, this filter term will be included in
the dynamically created term for the user:

[edit firewall family ethernet-switching]

user@switch# set filter filter1 term term1 from ip-destination-address 192.0.2.16/28
user@switch# set filter filter1 term term2 from ip-destination-address 192.0.2.16/28 user@switch#
set filter filter1 term term1 then count counter1
user@switch# set filter filter1 term term2 then policer p1

Results
Check the results of the configuration:

user@switch> show configuration

firewall {
family ethernet-switching {
filter filter1 {
term term1 {
from {
ip-destination-address {
192.0.2.16/28;
}
}
then count counter1;
term term2 {
from {
ip-destination-address {
192.0.2.16/28;
}
}
then policer p1;
 440

}
}
}
policer p1 {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 1500;
}
then discard;
}
}
protocols {
dot1x {
authenticator
interface ge-0/0/2 {
supplicant multiple;
}
}
}

Verification

Verifying Firewall Filters on Interfaces with Multiple Supplicants

Purpose
Verify that firewall filters are functioning on the interface with multiple supplicants.

Action
1. Check the results with one user authenticated on the interface. In this case, User 1 is authenticated on
ge-0/0/2:

user@switch> show dot1x firewall

Filter: dot1x_ge-0/0/2
Counters
counter1_dot1x_ge-0/0/2_user1 100

2. When a second user, User 2, is authenticated on the same interface, ge-0/0/2, you can verify that the
filter includes the results for both of the users authenticated on the interface:

user@switch> show dot1x firewall

 441

Filter: dot1x-filter-ge-0/0/0
Counters
counter1_dot1x_ge-0/0/2_user1 100
counter1_dot1x_ge-0/0/2_user2 400

Meaning
The results displayed by the show dot1x firewall command output reflect the dynamic filter created with
the authentication of each new user. User 1 accessed the file server located at the specified destination
address 100 times, while User 2 accessed the same file server 400 times.

SEE ALSO

Example: Configuring Firewall Filters for Port, VLAN, and Router Traffic on EX Series Switches
Filtering 802.1X Supplicants by Using RADIUS Server Attributes | 360

RELATED DOCUMENTATION

Example: Setting Up 802.1X for Single-Supplicant or Multiple-Supplicant Configurations on an EX

Series Switch | 405

Static MAC Bypass of 802.1X and MAC RADIUS

Authentication

IN THIS SECTION

Configuring Static MAC Bypass of 802.1X and MAC RADIUS Authentication (CLI Procedure) | 442

Example: Configuring Static MAC Bypass of 802.1X and MAC RADIUS Authentication on an EX Series
Switch | 443

Junos OS allows you to configure access to your LAN through 802.1X-configured interfaces without
authentication, by configuring a static MAC bypass list on the EX Series switch. The static MAC bypass
 442

list, also known as the exclusion list, specifies MAC addresses that are allowed on the switch without sending
a request to an authentication server. For more information, read this topic.

Configuring Static MAC Bypass of 802.1X and MAC RADIUS Authentication

(CLI Procedure)

You can configure a static MAC bypass list (sometimes called the exclusion list) on the switch to specify
MAC addresses of devices allowed access to the LAN without 802.1X or MAC RADIUS authentication
requests to the RADIUS server.

To configure the static MAC bypass list:

• Specify a MAC address to bypass authentication:

[edit protocols dot1x]

user@switch# set authenticator static 00:04:0f:fd:ac:fe

• Configure a supplicant to bypass authentication if it is connected through a particular interface:

[edit protocols dot1x]

user@switch# set authenticator static 00:04:0f:fd:ac:fe interface ge-0/0/5

• Configure a supplicant to be moved to a specific VLAN after it is authenticated:

[edit protocols dot1x]

user@switch# set authenticator static 00:04:0f:fd:ac:fe interface ge-0/0/5 vlan-assignment
default-vlan

SEE ALSO

Configuring 802.1X Interface Settings (CLI Procedure) | 355

Configuring 802.1X Authentication (J-Web Procedure)
 443

Example: Configuring Static MAC Bypass of 802.1X and MAC RADIUS

Authentication on an EX Series Switch

IN THIS SECTION

Requirements | 443

Overview and Topology | 444

Configuration | 446

Verification | 448

To allow devices to access your LAN through 802.1X-configured interfaces without authentication, you
can configure a static MAC bypass list on the EX Series switch. The static MAC bypass list, also known as
the exclusion list, specifies MAC addresses that are allowed on the switch without sending a request to an
authentication server.

You can use static MAC bypass of authentication to allow connection for devices that are not
802.1X-enabled, such as printers. If a host's MAC address is compared and matched against the static
MAC address list, the nonresponsive host is authenticated and an interface opened for it.

This example describes how to configure static MAC bypass of authentication for two printers:

Requirements

This example uses the following software and hardware components:

NOTE: This example also applies to QFX5100 switches.

• Junos OS Release 9.0 or later for EX Series switches

• One EX Series switch acting as an authenticator port access entity (PAE). The ports on the authenticator
PAE form a control gate that blocks all traffic to and from supplicants until they are authenticated.

Before you configure static MAC bypass of authentication, be sure you have:

• Performed basic bridging and VLAN configuration on the switch. See the documentation that describes
setting up basic bridging and a VLAN for your switch. If you are using a switch that supports the Enhanced
Layer 2 Software (ELS) configuration style, see Example: Setting Up Basic Bridging and a VLAN for an EX
 444

Series Switch with ELS Support or Example: Setting Up Basic Bridging and a VLAN on Switches. For all other
switches, see Example: Setting Up Basic Bridging and a VLAN for an EX Series Switch.

For more about ELS, see: Using the Enhanced Layer 2 Software CLI.

• Specified the RADIUS server connections and configured an access profile on the switch. See “Example:
Connecting a RADIUS Server for 802.1X to an EX Series Switch” on page 365.

Overview and Topology

To permit printers access to the LAN, add them to the static MAC bypass list. The MAC addresses on this
list are permitted access without authentication from the RADIUS server.

Figure 18 on page 445 shows the two printers connected to the EX4200.

NOTE: This figure also applies to QFX5100 switches.

 445

Figure 18: Topology for Static MAC Bypass of Authentication Configuration

The interfaces shown in Table 32 on page 446 will be configured for static MAC bypass of authentication.
 446

Table 32: Components of the Static MAC Bypass of Authentication Configuration Topology

Property Settings

Switch hardware EX4200, 24 Gigabit Ethernet ports: 16 non-PoE ports and 8 PoE
ports (ge-0/0/0 through ge-0/0/23)

VLAN name default

Connections to integrated printer/fax/copier ge-0/0/19, MAC address 00:04:0f:fd:ac:fe

machines (no PoE required) ge-0/0/20, MAC address 00:04:ae:cd:23:5f

The printer with the MAC address 00:04:0f:fd:ac:fe is connected to access interface ge-0/0/19. A second
printer with the MAC address 00:04:ae:cd:23:5f is connected to access interface ge-0/0/20. Both printers
will be added to the static list and bypass 802.1X authentication.

Configuration

CLI Quick Configuration

To quickly configure the static MAC bypass list, copy the following commands and paste them into the
switch terminal window:

[edit]
set protocols dot1x authenticator static [00:04:0f:fd:ac:fe 00:04:ae:cd:23:5f]
set protocols dot1x authenticator interface all supplicant multiple
set protocols dot1x authenticator authenticaton-profile-name profile1

Step-by-Step Procedure
Configure the static MAC bypass list:

1. Configure MAC addresses 00:04:0f:fd:ac:fe and 00:04:ae:cd:23:5f as static MAC addresses:

[edit protocols]
user@switch# set dot1x authenticator static [00:04:0f:fd:ac:fe 00:04:ae:cd:23:5f]

2. Configure the 802.1X authentication method:

[edit protocols]
user@switch# set dot1x authenticator interface all supplicant multiple

3. Configure the authentication profile name (access profile name) to use for authentication:

[edit protocols]
user@switch# set dot1x authenticator authentication-profile-name profile1
 447

NOTE: Access profile configuration is required only for 802.1X clients, not for static MAC
clients.

Results
Display the results of the configuration:

user@switch> show
interfaces {
ge-0/0/19 {
unit 0 {
family ethernet-switching {
vlan members default;
}
}
}
ge-0/0/20 {
unit 0 {
family ethernet-switching {
vlan members default;
}
}
}
}
protocols {
dot1x {
authenticator {
authentication-profile-name profile1
static [00:04:0f:fd:ac:fe 00:04:ae:cd:23:5f];
interface {
all {
supplicant multiple;
}
}
}
}
}
 448

Verification

IN THIS SECTION

Verifying Static MAC Bypass of Authentication | 448

To confirm that the configuration is working properly, perform these tasks:

Verifying Static MAC Bypass of Authentication

Purpose
Verify that the MAC addresses of both printers are configured and associated with the correct interfaces.

Action

Issue the operational mode command:

user@switch> show dot1x static-mac-address

MAC address VLAN-Assignment Interface

00:04:0f:fd:ac:fe default ge-0/0/19.0
00:04:ae:cd:23:5f default ge-0/0/20.0

Meaning
The output field MAC address shows the MAC addresses of the two printers.

The output field Interface shows that the MAC address 00:04:0f:fd:ac:fe can connect to the LAN through
interface ge-0/0/19.0 and that the MAC address 00:04:ae:cd:23:5f can connect to the LAN through
interface ge-0/0/20.0.

SEE ALSO

Configuring 802.1X Authentication (J-Web Procedure)

Configuring 802.1X Interface Settings (CLI Procedure) | 355
Understanding Authentication on Switches | 326
 449

RELATED DOCUMENTATION

Interfaces Enabled for 802.1X or MAC RADIUS Authentication | 420

802.1X Authentication | 351
MAC RADIUS Authentication | 390

Captive Portal Authentication

IN THIS SECTION

Example: Setting Up Captive Portal Authentication on an EX Series Switch | 449

Configuring Captive Portal Authentication (CLI Procedure) | 456

Designing a Captive Portal Authentication Login Page on Switches | 458

Configuring Captive Portal Authentication (CLI Procedure) on an EX Series Switche with ELS Support | 461

Example: Setting Up Captive Portal Authentication on an EX Series Switch with ELS Support | 463

You can control access to your network through a switch by using several different authentication. Junos
OS switches support 802.1X, MAC RADIUS, and captive portal as an authentication methods to devices
requiring to connect to a network. You can set up captive portal authentication on a switch to redirect
Web browser requests to a login page that requires the user to input a username and password. For more
information, read this topic.

Example: Setting Up Captive Portal Authentication on an EX Series Switch

IN THIS SECTION

Requirements | 450

Overview and Topology | 450

Configuration | 450

Verification | 454

Troubleshooting | 455
 450

You can set up captive portal authentication (hereafter referred to as captive portal) on a switch to redirect
Web browser requests to a login page that requires the user to input a username and password. Upon
successful authentication, the user is allowed to continue with the original page request and subsequent
access to the network.

This example describes how to set up captive portal on an EX Series switch:

Requirements

This example uses the following hardware and software components:

• An EX Series switch that supports captive portal

• Junos OS Release 10.1 or later for EX Series switches

Before you begin, be sure you have:

• Performed basic bridging and VLAN configuration on the switch. See Example: Setting Up Basic Bridging
and a VLAN for an EX Series Switch.

• Generated an SSL certificate and installed it on the switch. See “Generating SSL Certificates to Be Used
for Secure Web Access (EX Series Switch)” on page 306.

• Designed your captive portal login page. See “Designing a Captive Portal Authentication Login Page on
Switches” on page 458.

Overview and Topology

This example shows the configuration required on the switch to enable captive portal on an interface. To
permit a printer connected to the captive portal interface to access the LAN without going through captive
portal, add its MAC address to the authentication whitelist. The MAC addresses in this list are permitted
access on the interface without captive portal.

The topology for this example consists of one EX Series switch connected to a RADIUS authentication
server. One interface on the switch is configured for captive portal. In this example, the interface is
configured in multiple supplicant mode.

Configuration

To configure captive portal on your switch:

CLI Quick Configuration

To quickly configure captive portal on the switch after completing the tasks in the Requirements section,
copy the following commands and paste them into the switch terminal window:

[edit]
 451

set access radius-server 10.204.96.165 port 1812

set access radius-server 10.204.96.165 secret "ABC123"
set access profile profile1 authentication-order radius
set access profile profile1 radius authentication-server 10.204.96.165
set system services web-management http
set system services web-management https local-certificate my-signed-cert
set services captive-portal secure-authentication https
set services captive-portal interface ge-0/0/10.0 supplicant multiple
set services captive-portal authentication-profile-name profile1
set ethernet-switching-options authentication-whitelist 00:10:12:e0:28:22
set services captive-portal custom-options post-authentication-url http://www.my-home-page.com

Step-by-Step Procedure
To configure captive portal on the switch:

1. Define the server IP address, the server authentication port number, and configure the secret password.
The secret password on the switch must match the secret password on the server:

[edit]
user@switch# set access radius-server 10.204.96.165 port 1812
[edit]
user@switch# set access radius-server 10.204.96.165 secret "ABC123"

2. Configure the authentication order, making radius the first method of authentication:

[edit]
user@switch# set access profile profile1 authentication-order radius

3. Configure the server IP address to be tried in order to authenticate the supplicant:

[edit]
user@switch# set access profile profile1 radius authentication-server 10.204.96.165

4. Enable HTTP access on the switch:

[edit]
user@switch# set system services web-management http

5. To create a secure channel for Web access to the switch, configure captive portal for HTTPS:
 452

NOTE: You can enable HTTP without enabling HTTPS, but we recommend HTTPS for security
purposes.

a. Associate the security certificate with the Web server and enable HTTPS access on the switch:

[edit]
user@switch# set system services web-management https local-certificate my-signed-cert

b. Configure captive portal to use HTTPS:

[edit]
user@switch# set services captive-portal secure-authentication https

6. Enable an interface for captive portal:

[edit]
user@switch# set services captive-portal interface ge-0/0/10 supplicant multiple

7. Specify the name of the access profile to be used for captive portal authentication:

[edit]
user@switch# set services captive-portal authentication-profile-name profile1

8. (Optional) Allow specific clients to bypass captive portal:

NOTE: If the client is already attached to the switch, you must clear its MAC address from
the captive portal authentication by using the clear captive-portal mac-address mac-address
command after adding its MAC address to the whitelist. Otherwise the new entry for the
MAC address will not be added to the Ethernet switching table and authentication bypass
will not be allowed.

[edit]
user@switch# set ethernet-switching-options authentication-whitelist 00:10:12:e0:28:22
 453

NOTE: Optionally, you can use set ethernet-switching-options authentication-whitelist

00:10:12:e0:28:22 interface ge-0/0/10.0 to limit the scope to the interface.

9. (Optional) To redirect clients to a specified page rather than the page they originally requested, configure
the post-authentication URL:

[edit]
user@switch# set services captive-portal custom-options post-authentication-url
http://www.my-home-page.com

Results
Display the results of the configuration:

[edit]
user@switch> show
system {
services {
web-management {
http;
https {
local-certificate my-signed-cert;
}
}
}
}
security {
certificates {
local {
my-signed-cert {
"-----BEGIN RSA PRIVATE KEY-----ABC123
...
ABC123-----END CERTIFICATE-----\n"; ## SECRET-DATA
}
}
}
}
services {
captive-portal {
interface {
ge-0/0/10.0 {
 454

supplicant multiple;
}
}
secure-authentication https;
}
}
ethernet-switching-options {
authentication-whitelist {
00:10:12:e0:28:22/48;
}
}

Verification

IN THIS SECTION

Verifying That Captive Portal Is Enabled on the Interface | 454

Verify That Captive Portal Is Working Correctly | 455

To confirm that captive portal is configured and working properly, perform these tasks:

Verifying That Captive Portal Is Enabled on the Interface

Purpose
Verify that captive portal is configured on interface ge-0/0/10.

Action

Use the operational mode command show captive-portal interface interface-name detail:

user@switch> show captive-portal interface ge-0/0/10.0 detail

ge-0/0/10.0
Supplicant mode: Multiple
Number of retries: 3
Quiet period: 60 seconds
Configured CP session timeout: 3600 seconds
Server timeout: 15 seconds
 455

Meaning
The output confirms that captive portal is configured on interface ge-0/0/10 with the default settings for
number of retries, quiet period, CP session timeout, and server timeout.

Verify That Captive Portal Is Working Correctly

Purpose
Verify that captive portal is working on the switch.

Action
Connect a client to interface ge-0/0/10. From the client, open a Web browser and request a webpage.
The captive portal login page that you designed should be displayed. After you enter your login information
and are authenticated against the RADIUS server, the Web browser should display either the page you
requested or the post-authentication URL that you configured.

Troubleshooting

IN THIS SECTION

Troubleshooting Captive Portal | 455

To troubleshoot captive portal, perform these tasks:

Troubleshooting Captive Portal

Problem
The switch does not return the captive portal login page when a user connected to a captive portal interface
on the switch requests a Web page.

Solution
You can examine the ARP, DHCP, HTTPS, and DNS counters—if one or more of these counters are not
incrementing, this provides an indication of where the problem lies. For example, if the client cannot get
an IP address, check the switch interface to determine whether the DHCP counter is incrementing—if the
counter increments, the DHCP packet was received by the switch.

user@switch> show captive-portal firewall ge-0/0/10.0

ge-0/0/10.0
Filter name: dot1x_ge-0/0/10
Counters:
Name Bytes Packets
 456

dot1x_ge-0/0/10_CP_arp 7616 119

dot1x_ge-0/0/10_CP_dhcp 0 0
dot1x_ge-0/0/10_CP_http 0 0
dot1x_ge-0/0/10_CP_https 0 0
dot1x_ge-0/0/10_CP_t_dns 0 0
dot1x_ge-0/0/10_CP_u_dns 0 0

Configuring Captive Portal Authentication (CLI Procedure)

Configure captive portal authentication (hereafter referred to as captive portal) on an EX Series switch so
that users connected to the switch are authenticated before being allowed to access the network. When
the user requests a web page, a login page is displayed that requires the user to input a username and
password. Upon successful authentication, the user is allowed to continue with the original page request
and subsequent access to the network.

Before you begin, be sure you have:

• Performed basic bridging and VLAN configuration on the switch. See Example: Setting Up Basic Bridging
and a VLAN for an EX Series Switch.

• Generated an SSL certificate and installed it on the switch. See “Generating SSL Certificates to Be Used
for Secure Web Access (EX Series Switch)” on page 306.

• Configured basic access between the EX Series switch and the RADIUS server. See “Example: Connecting
a RADIUS Server for 802.1X to an EX Series Switch” on page 365.

• Designed your captive portal login page. See “Designing a Captive Portal Authentication Login Page on
Switches” on page 458.

This topic includes the following tasks:

Configuring Secure Access for Captive Portal | 456

Enabling an Interface for Captive Portal | 457

Configuring Bypass of Captive Portal Authentication | 457

Configuring Secure Access for Captive Portal

To configure secure access for captive portal:

1. Enable HTTP access on the switch:

[edit]
 457

user@switch# set system services web-management http

2. Associate the security certificate with the Web server and enable HTTPS access on the switch:

[edit]
user@switch# set system services web-management https local-certificate my-signed-cert

NOTE: You can enable HTTP without HTTPS, but we recommend HTTPS for security
purposes.

3. Configure captive portal to use HTTPS:

[edit]
user@switch# set services captive-portal secure-authentication https

Enabling an Interface for Captive Portal

To enable an interface for captive portal:

[edit]
user@switch# set services captive-portal interface interface-name

For example, to enable captive portal on the interface ge-0/0/10:

[edit]
user@switch# set services captive-portal interface ge-0/0/10

Configuring Bypass of Captive Portal Authentication

To allow specific clients to bypass captive portal:

[edit]
user@switch# set ethernet-switching-options authentication-whitelist mac-address

For example, to allow specific clients to bypass captive portal:

[edit]
user@switch# set ethernet-switching-options authentication-whitelist 00:10:12:e0:28:22
 458

NOTE: Optionally, you can use set ethernet-switching-options authentication-whitelist

00:10:12:e0:28:22 interface ge-0/0/10.0 to limit the scope to the interface.

NOTE: If the client is already attached to the switch, you must clear its MAC address from the
captive portal authentication by using the clear captive-portal mac-address mac-address command
after adding its MAC address to the whitelist. Otherwise the new entry for the MAC address
will not be added to the Ethernet switching table and authentication bypass will not be allowed.

Designing a Captive Portal Authentication Login Page on Switches

You can set up captive portal authentication on your switch to redirect all Web browser requests to a login
page that requires users to input a username and password before they are allowed access. Upon successful
authentication, users are allowed access to the network and redirected to the original page requested.

Junos OS provides a customizable template for the captive portal window that allows you to easily design
and modify the look of the captive portal login page. You can modify the design elements of the template
to change the look of your captive portal login page and to add instructions or information to the page.
You can also modify any of the design elements of a captive portal login page.

The first screen displayed before the captive login page requires the user to read the terms and conditions
of use. By clicking the Agree button, the user can access the captive portal login page.

Figure 19 on page 459 shows an example of a captive portal login page:

 459

Figure 19: Example of a Captive Portal Login Page

Table 33 on page 459 summarizes the configurable elements of a captive portal login page.

Table 33: Configurable Elements of a Captive Portal Login Page

Element CLI Statement Description

Footer footer-bgcolor The HTML hexadecimal code for the background color of the captive
background color hex-color portal login page footer.

Footer message footer-message Text displayed in the footer of the captive portal login page. You can
text-string include copyright information, links, and additional information such
as help instructions, legal notices, or a privacy policy

The default text shown in the footer is Copyright @2010, Juniper

Networks Inc.

Footer text color footer- text-color color Color of the text in the footer. The default color is white.

Form header form-header-bgcolor The HTML hexadecimal code for the background color of the header
background color hex-color bar across the top of the form area of the captive portal login page.

Form header form-header-message Text displayed in the header of the captive portal login page. The default
message text-string text is Captive Portal User Authentication .

Form header text form-header- text- Color of the text in the form header. The default color is black.
color color color
 460

Table 33: Configurable Elements of a Captive Portal Login Page (continued)

Element CLI Statement Description

Form reset button form-reset-label Using the Reset button, the user can clear the username and password
label label-name fields on the form.

Form submit form-submit-label Using the Login button, the user can submit the login information.
button label label-name

Header header-bgcolor The HTML hexadecimal code for the background color of the captive
background color hex-color portal login page header.

Header logo header-logo filename Filename of the file containing the image of the logo that you want to
appear in the header of the captive portal login page. The image file
can be in GIF, JPEG, or PNG format.

You can upload a logo image file to the switch. Copy the logo to the
/var/tmp directory on the switch (during commit, the files are saved to
persistent locations).

If you do not specify a logo image, the Juniper Networks logo is

displayed.

Header message header-message Text displayed in the page header. The default text is User
text-string Authentication.

Header text color header-text- colorcolor Color of the text in the header. The default color is white.

Post-authentication post-authentication-url URL to which the users are directed on successful authentication. By
URL url default, users are directed to the page they had originally requested.

To design the captive portal login page:

1. (Optional) Upload your logo image file to the switch:

user@switch> file copy ftp://username:[email protected]/var/tmp/my-logo.jpeg

2. Configure the custom options to specify the background colors and text displayed in the captive portal
page:

[edit system services captive-portal]

user@switch# set custom-options header-bgcolor #006600
set custom-options header-message “Welcome to Our Network”
set custom-options banner-message “Please enter your username and password”.The banner displays
the message ”XXXXXXX” by default. The user can modify this message.
 461

set custom-options footer-message “Copyright ©2010, Our Network”

Now you can commit the configuration.

NOTE: For the custom options that you do not specify, the default value is used.

SEE ALSO

Understanding Authentication on Switches | 326

captive-portal | 1085

Configuring Captive Portal Authentication (CLI Procedure) on an EX Series

Switche with ELS Support

NOTE: This task uses Junos OS for switches with support for the Enhanced Layer 2 Software
(ELS) configuration style. If your switch runs software that does not support ELS, see “Configuring
Captive Portal Authentication (CLI Procedure)” on page 456. For ELS details, see Using the Enhanced
Layer 2 Software CLI.

Configure captive portal authentication (hereafter referred to as captive portal) on a switch so that users
connected to the switch are authenticated before being allowed to access the network. When the user
requests a webpage, a login page is displayed that requires the user to input a username and password.
Upon successful authentication, the user is allowed to continue with the original page request and
subsequent access to the network.

Before you begin, be sure you have:

• Performed basic bridging and VLAN configuration on the switch. See Example: Setting Up Basic Bridging
and a VLAN for an EX Series Switch with ELS Support .

• Generated an SSL certificate and installed it on the switch. See “Generating SSL Certificates to Be Used
for Secure Web Access (EX Series Switch)” on page 306.
 462

• Configured basic access between the switch and the RADIUS server. See “Example: Connecting a RADIUS
Server for 802.1X to an EX Series Switch” on page 365.

• Designed your captive portal login page. See “Designing a Captive Portal Authentication Login Page on
Switches” on page 458.

This topic includes the following tasks:

Configuring Secure Access for Captive Portal | 462

Enabling an Interface for Captive Portal | 462

Configuring Bypass of Captive Portal Authentication | 463

Configuring Secure Access for Captive Portal

To configure secure access for captive portal:

1. Associate the security certificate with the Web server and enable HTTPS on the switch:

[edit]
user@switch# set system services web-management https local-certificate certificate-name

NOTE: You can enable HTTP instead of HTTPS, but we recommend HTTPS for security
purposes.

2. Configure captive portal to use HTTPS:

[edit]
user@switch# set services captive-portal secure-authentication https

Enabling an Interface for Captive Portal

To enable an interface for use with captive portal authentication:

[edit]
user@switch# set services captive-portal interface interface-name
 463

Configuring Bypass of Captive Portal Authentication

You can allow specific clients to bypass captive portal authentication:

[edit]
user@switch# set switch-options authentication-whitelist mac-address

NOTE: Optionally, you can use set switch-options authentication-whitelist mac-address interface
interface-name to limit the scope to the interface.

NOTE: If the client is already attached to the switch, you must clear its MAC address from the
captive portal authentication by using the clear captive-portal mac-address session-mac-addr
command after adding its MAC address to the whitelist. Otherwise, the new entry for the MAC
address is not added to the Ethernet switching table and the authentication bypass is not allowed.

Example: Setting Up Captive Portal Authentication on an EX Series Switch

with ELS Support

IN THIS SECTION

Requirements | 464

Overview and Topology | 464

Configuration | 465

Verification | 467

Troubleshooting | 468
 464

NOTE: This example uses Junos OS for EX Series switches with support for the Enhanced Layer
2 Software (ELS) configuration style. If your switch runs software that does not support ELS, see
“Example: Setting Up Captive Portal Authentication on an EX Series Switch” on page 449. For
ELS details, see Using the Enhanced Layer 2 Software CLI.

You can set up captive portal authentication (hereafter referred to as captive portal) on a switch to redirect
Web browser requests to a login page that requires the user to input a username and password. Upon
successful authentication, the user is allowed to continue with the original page request and subsequent
access to the network.

This example describes how to set up captive portal on an EX Series switch:

Requirements

This example uses the following software and hardware components:

• Junos OS Release 13.2X50 or later for EX Series switches

• An EX Series switch with support for ELS

Before you begin, be sure you have:

• Performed basic bridging and VLAN configuration on the switch. See Example: Setting Up Basic Bridging
and a VLAN for an EX Series Switch with ELS Support .

• Generated an SSL certificate and installed it on the switch. See “Generating SSL Certificates to Be Used
for Secure Web Access (EX Series Switch)” on page 306.

• Configured basic access between the EX Series switch and the RADIUS server. See “Example: Connecting
a RADIUS Server for 802.1X to an EX Series Switch” on page 365.

• Designed your captive portal login page. See “Designing a Captive Portal Authentication Login Page on
Switches” on page 458.

Overview and Topology

This example shows the configuration required on the switch to enable captive portal on an interface. To
permit a printer connected to the captive portal interface to access the LAN, add its MAC address to the
authentication whitelist and assign it to a VLAN, vlan1. The MAC addresses on this list are permitted access
on the interface without captive portal authentication.

The topology for this example consists of one EX Series switch connected to a RADIUS authentication
server. One interface on the switch is configured for captive portal. In this example, the interface is
configured in multiple supplicant mode.
 465

Configuration

To configure captive portal on your switch:

CLI Quick Configuration

To quickly configure captive portal on the switch after completing the tasks in the Requirements section,
copy the following commands and paste them into the switch terminal window:

[edit]
set system services web-management https local-certificate my-signed-cert
set services captive-portal secure-authentication https
set services captive-portal interface ge-0/0/10.0 supplicant multiple
set switch-options authentication-whitelist 00:10:12:e0:28:22 vlan-assignment vlan1
set custom-options post-authentication-url http://www.my-home-page.com

Step-by-Step Procedure
1. To create a secure channel for Web access to the switch, configure captive portal for HTTPS:

a. Associate the security certificate with the Web server and enable HTTPS on the switch:

[edit]
user@switch# set system services web-management https local-certificate my-signed-cert

NOTE: You can enable HTTP instead of HTTPS, but we recommend that you enable
HTTPS for security purposes.

b. Configure captive portal to use HTTPS:

[edit]
user@switch# set services captive-portal secure-authentication https

2. Enable an interface for captive portal:

[edit]
user@switch# set services captive-portal interface ge-0/0/10 supplicant multiple

3. (Optional) Allow specific clients to bypass captive portal authentication:

 466

NOTE: If the client is already attached to the switch, you must clear its MAC address from
the captive portal authentication by using the clear captive-portal mac-address mac-address
command after adding its MAC address to the whitelist. Otherwise, the new entry for the
MAC address will not be added to the Ethernet switching table and the authentication bypass
will not be allowed.

[edit]
user@switch# set switch-options authentication-whitelist 00:10:12:e0:28:22 vlan-assignment
vlan1

NOTE: Optionally, you can use set switch-options authentication-whitelist 00:10:12:e0:28:22

vlan-assignment vlan1 interface ge-0/0/10.0 to limit the scope to the interface.

4. (Optional) To redirect clients to a specified page rather than the page they originally requested, configure
the post-authentication URL:

[edit services captive-portal]

user@switch# set custom-options post-authentication-url http://www.my-home-page.com

Results
Display the results of the configuration:

[edit]
user@switch# show
system {
services {
web-management {
https {
local-certificate my-signed-cert;
}
}
}
}
security {
certificates {
local {
my-signed-cert {
 467

"-----BEGIN RSA PRIVATE KEY-----\ABC123

ABC123ABC123ABC123 ... ABC123
----END CERTIFICATE-----\n"; ## SECRET-DATA
}
}
}
}
services {
captive-portal {
interface {
ge-0/0/10.0 {
supplicant multiple;
}
}
secure-authentication https;
custom-options {
post-authentication-url http://www.my-home-page.com;
}
}
}
switch-options {
authentication-whitelist {
00:10:12:e0:28:22/48 {
vlan-assignment vlan1;
}
}
}

Verification

IN THIS SECTION

Verifying That Captive Portal Is Enabled on the Interface | 467

Verify That Captive Portal Is Working Correctly | 468

To confirm that captive portal authentication is configured and working properly, perform these tasks:

Verifying That Captive Portal Is Enabled on the Interface

Purpose
 468

Verify that captive portal is configured on the interface ge-0/0/10.

Action

Use the operational mode command show captive-portal interface interface-name detail:

user@switch> show captive-portal interface ge-0/0/10.0 detail

ge-0/0/10.0
Supplicant mode: Multiple
Number of retries: 3
Quiet period: 60 seconds
Configured CP session timeout: 3600 seconds
Server timeout: 15 seconds

Meaning
The output confirms that captive portal is configured on the interface ge-0/0/10, with the default settings
for number of retries, quiet period, CP session timeout, and server timeout.

Verify That Captive Portal Is Working Correctly

Purpose
Verify that captive portal is working on the switch.

Action
Connect a client to the interface ge-0/0/10. From the client, open a Web browser and request a webpage.
The captive portal login page that you designed should be displayed. After you enter your login information
and are authenticated against the RADIUS server, the Web browser should display either the page you
requested or the post-authentication URL that you configured.

Troubleshooting

IN THIS SECTION

Troubleshooting Captive Portal | 468

To troubleshoot captive portal, perform this task:

Troubleshooting Captive Portal

Problem
 469

The switch does not return the captive portal login page when a user connected to a captive portal interface
on the switch requests a webpage.

Solution
You can examine the ARP, DHCP, HTTPS, and DNS counters—if one or more of these counters are not
incrementing, this provides an indication of where the problem lies. For example, if the client cannot get
an IP address, you might check the switch interface to determine whether the DHCP counter is
incrementing—if the counter increments, the DHCP packet was received by the switch.

user@switch> show captive-portal firewall ge-0/0/10.0

ge-0/0/10.0
Filter name: dot1x_ge-0/0/10
Counters:
Name Bytes Packets
dot1x_ge-0/0/10_CP_arp 7616 119
dot1x_ge-0/0/10_CP_dhcp 0 0
dot1x_ge-0/0/10_CP_http 0 0
dot1x_ge-0/0/10_CP_https 0 0
dot1x_ge-0/0/10_CP_t_dns 0 0
dot1x_ge-0/0/10_CP_u_dns 0 0

RELATED DOCUMENTATION

Flexible Authentication Order on EX Series Switches | 469

Central Web Authentication | 474
Centralized Access Control to Network Resources on EX Series Switches | 481

Flexible Authentication Order on EX Series Switches

IN THIS SECTION

Configuring Flexible Authentication Order | 470

Configuring EAPoL Block to Maintain an Existing Authentication Session | 472

 470

Junos OS switches support 802.1X, MAC RADIUS, and captive portal as an authentication methods to
devices requiring to connect to a network. You can use the flexible authentication order feature to specify
the order of authentication methods that the switch uses when attempting to authenticate a client. If
multiple authentication methods are configured on a single interface, when one authentication method
fails, the switch falls back to another method. For more information, read this topic.

Configuring Flexible Authentication Order

You can use the flexible authentication order feature to specify the order of authentication methods that
the switch uses when attempting to authenticate a client. If multiple authentication methods are configured
on a single interface, when one authentication method fails, the switch falls back to another method.

By default, the switch attempts to authenticate a client by using 802.1X authentication first. If 802.1X
authentication fails because there is no response from the client, and MAC RADIUS authentication is
configured on the interface, the switch will attempt authentication using MAC RADIUS. If MAC RADIUS
fails, and captive portal is configured on the interface, the switch attempts authentication using captive
portal.

With a flexible authentication order, the sequence of authentication method used can be changed based
on the type of clients connected to the interface. You can configure the authentication-order statement
to specify whether 802.1X authentication or MAC RADIUS authentication must be the first authentication
method tried. Captive portal is always the last authentication method tried.

If MAC RADIUS authentication is configured as the first authentication method in the order, then on
receiving data from any client, the switch attempts to authenticate the client by using MAC RADIUS
authentication. If MAC RADIUS authentication fails, then the switch uses 802.1X authentication to
authenticate the client. If 802.1X authentication fails, and captive portal is configured on the interface,
the switch attempts authentication using captive portal.

NOTE: If 802.1X authentication and MAC RADIUS authentication fail, and captive portal is not
configured on the interface, the client is denied access to the LAN unless a server fail fallback
method is configured. See “Configuring RADIUS Server Fail Fallback (CLI Procedure)” on page 349
for more information.

Different authentication methods can be used in parallel on an interface that is configured in

multiple-supplicant mode. Therefore, if an end device is authenticated on the interface by using captive
portal, another end device connected to that interface can still be authenticated using 802.1X or MAC
RADIUS authentication.

Before you configure the flexible authentication order on an interface, make sure that the authentication
methods are configured on that interface. The switch does not attempt authentication using a method
 471

that is not configured on the interface, even if that method is included in the authentication order; the
switch ignores that method and attempts the next method in the authentication order that is enabled on
that interface.

Use the following guidelines when configuring the authentication-order statement:

• The authentication order must include at least two methods of authentication.

• 802.1X authentication must be one of the methods included in the authentication order.

• If captive portal is included in the authentication order, it must be the last method in the order.

• If mac-radius-restrict is configured on an interface then the authentication order cannot be configured

on that interface.

To configure a flexible authentication order, use one of the following valid combinations:

NOTE: The authentication order can be configured globally using the interface all option as well
as locally using the individual interface name. If the authentication order is configured both for
an individual interface and for all interfaces, the local configuration for that interface overrides
the global configuration.

• To configure 802.1X authentication as the first authentication method, followed by MAC RADIUS
authentication, and then captive portal:

[edit]
user@switch# set protocols dot1x authenticator interface interface-name authentication-order
[dot1x mac-radius captive-portal]

• To configure 802.1X authentication as the first authentication method, followed by captive portal:

[edit]
user@switch# set protocols dot1x authenticator interface interface-name authentication-order
[dot1x captive-portal]

• To configure 802.1X authentication as the first authentication method, followed by MAC RADIUS
authentication:

[edit]
user@switch# set protocols dot1x authenticator interface interface-name authentication-order
[dot1x mac-radius]

• To configure MAC RADIUS authentication as the first authentication method, followed by 802.1X,
followed by captive portal:
 472

[edit]
user@switch# set protocols dot1x authenticator interface interface-name authentication-order
[mac-radius dot1x captive-portal]

After you configure the authentication order, you must use the insert command to make any modifications
to the authentication order. Using the set command does not change the configured order.

To change the authentication order after initial configuration:

[edit]
user@switch# insert protocols dot1x authenticator interface interface-name authentication-order
authentication-method before authentication-method

For example, to change the order from [mac-radius dot1x captive portal] to [dot1x mac-radius captive
portal]:

[edit]
user@switch# insert protocols dot1x authenticator interface interface-name authentication-order
dot1x before mac-radius

SEE ALSO

Understanding Authentication on Switches | 326

Example: Configuring MAC RADIUS Authentication on an EX Series Switch | 392

Configuring EAPoL Block to Maintain an Existing Authentication Session

When a switch acting as an 802.1X authenticator receives an EAP-Start message from an authenticated
client, the switch tries to re-authenticate the client using the 802.1X method and typically returns an
EAP-Request message, and waits for a response. If the client fails to respond, the switch attempts to
re-authenticate the client using MAC RADIUS or captive portal method if these methods were configured.
Clients that have been authenticated using MAC RADIUS or captive portal authentication are
non-responsive, and traffic is dropped on the interface as the switch attempts re-authentication.

If you have configured flexible authentication order on the interface so that MAC RADIUS is the first
method used to authenticate a client, the switch still reverts to using 802.1X for re-authentication if the
client sends an EAP-Start message, even if the client was successfully authenticated using MAC RADIUS
authentication. You can configure an EAPoL block with either a fixed or flexible authentication order. If
 473

you do not configure the authentication-order statement, the order is fixed by default. The eapol-block
statement can be configured with or without configuring the authentication-order statement.

You can configure a switch to ignore EAP-Start messages sent from a client that has been authenticated
using MAC RADIUS authentication or captive portal authentication using the eapol-block statement. With
a block of EAPoL messages in effect, if the switch receives an EAP-Start message from the client, it does
not return an EAP-Request message, and the existing authentication session is maintained.

NOTE: If the endpoint has not been authenticated with MAC RADIUS authentication or captive
portal authentication, the EAPoL block does not take effect. The endpoint can authenticate using
802.1X authentication.

If eapol-block is configured with the mac-radius option, then once the client is authenticated with MAC
RADIUS authentication or CWA (Central Web Authentication), the client remains in authenticated state
even if it sends an EAP-Start message. If eapol-block is configured with the captive-portal option, then
once the client is authenticated with captive portal, the client remains in authenticated state even if it
sends an EAP-Start message.

NOTE: This feature is supported on EX4300 and EX9200 switches.

To configure a block of EAPoL messages to maintain an existing authentication session:

• To configure EAPoL block for a client authenticated using MAC RADIUS authentication:

[edit]
user@switch# set protocols dot1x authenticator interface interface-name eapol-block mac-radius

• To configure EAPoL block for a client authenticated using captive portal authentication:

[edit]
user@switch# set protocols dot1x authenticator interface interface-name eapol-block captive-portal

SEE ALSO

Understanding Authentication on Switches | 326

RELATED DOCUMENTATION
 474

Access Control and Authentication on Switching Devices | 326

Central Web Authentication

IN THIS SECTION

Understanding Central Web Authentication | 474

Configuring Central Web Authentication | 477

Web authentication provides access to network for users by redirecting the client’s Web browser to a
central Web authentication server (CWA server), which handles the complete login process. Web
authentication can also be used as a fallback authentication method for regular network users who have
802.1X-enabled devices, but fail authentication because of other issues, such as expired network credentials.

Understanding Central Web Authentication

IN THIS SECTION

Central Web Authentication Process | 475

Dynamic Firewall Filters for Central Web Authentication | 476

Redirect URL for Central Web Authentication | 477

Web authentication redirects Web browser requests to a login page that requires the user to input a
username and password. Upon successful authentication, the user is allowed access to the network. Web
authentication is useful for providing network access to temporary users, such as visitors to a corporate
site, who try to access the network using devices that are not 802.1X-enabled. Web authentication can
also be used as a fallback authentication method for regular network users who have 802.1X-enabled
devices, but fail authentication because of other issues, such as expired network credentials.

Web authentication can be done locally on the switch using captive portal, but this requires that the Web
portal pages be configured on each switch used as a network access device. Central Web authentication
 475

(CWA) provides efficiency and scaling benefits by redirecting the client’s Web browser to a central Web
authentication server (CWA server), which handles the complete login process.

Central Web Authentication Process

Central Web authentication is invoked after a host has failed MAC RADIUS authentication. The host can
attempt authentication using 802.1X authentication first, but must then attempt MAC RADIUS
authentication before attempting central Web authentication. The switch, operating as the authenticator,
exchanges RADIUS messages with the authentication, authorization, and accounting (AAA) server. After
MAC RADIUS authentication fails, the switch receives an Access-Accept message from the AAA server.
This message includes a dynamic firewall filter and a redirect URL for central Web authentication. The
switch applies the filter, which allows the host to receive an IP address, and uses the URL to redirect the
host to the Web authentication page.

The host is prompted for login credentials and might also be asked to agree to an acceptable use policy.
If Web authentication is successful, the AAA server sends a Change of Authorization (CoA) message, which
updates the terms of the authorized session in progress. This enables the authenticator to update the filter
or VLAN assignment applied to the controlled port, to allow the host to access the LAN.

The sequence of events in central Web authentication is as follows (see Figure 20 on page 476):

1. A host connected to the switch (authenticator) initiates MAC RADIUS authentication.

2. MAC RADIUS authentication fails. Instead of sending an Access-Reject message to the switch, the AAA
server sends an Access-Accept message that includes a dynamic firewall filter and a CWA redirect URL.

3. The host is allowed by the terms of the filter to send DHCP requests.

4. The host receives an IP address and DNS information from the DHCP server. The AAA server initiates
a new session that has a unique session ID.

5. The host opens a Web browser.

6. The authenticator sends the CWA redirect URL to the host.

7. The host is redirected to the CWA server and is prompted for login credentials.

8. The host provides the username and password.

9. After successful Web authentication, the AAA server sends a CoA message to udpate the filter or VLAN
assignment applied on the controlled port, allowing the host to access the LAN.
 476

10. The authenticator responds with a CoA-ACK message and sends a MAC RADIUS authentication request
to the AAA server.

11. The AAA server matches the session ID to the appropriate access policy and sends an Access-Accept
message to authenticate the host.

Figure 20: Central Web Authentication Process

RADIUS/AAA
Host Server

Authenticator

5 DHCP Server

10

g043340
11

Dynamic Firewall Filters for Central Web Authentication

Central Web authentication uses dynamic firewall filters, which are centrally defined on the AAA server
and dynamically applied to supplicants that request authentication through that server. The filter allows
the host to get an IP address dynamically using DHCP. You define the filters by using RADIUS attributes,
which are included in the Access-Accept messages sent from the server. Filters can be defined using either
the Juniper-Switching-Filter attribute, which is a vendor-specific attribute (VSA), or the Filter-ID attribute,
which is an IETF RADIUS attribute.

To use the Juniper-Switching-Filter VSA for central Web authentication, you must configure the filter with
the correct terms that allow the destination IP address of the CWA server. This configuration is done
directly on the AAA server. To use the Filter-ID attribute for central web authentication, enter the value
as JNPR_RSVD_FILTER_CWA on the AAA server. The filter terms for this attribute are internally defined
for central Web authentication, because of which no additional configuration is required. For more
information about configuring dynamic firewall filters for central web authentication, see “Configuring
Central Web Authentication” on page 477.
 477

Redirect URL for Central Web Authentication

In central Web authentication, the authenticator redirects the host’s Web browser request to the CWA
server by using a redirect URL. After redirection, the CWA server completes the login process. The redirect
URL for central web authentication can be configured on the AAA server or on the authenticator. The
redirect URL, along with the dynamic firewall filter, must be present to trigger the central web authentication
process after the failure of MAC RADIUS authentication.

The redirect URL can be centrally defined on the AAA server by using the Juniper-CWA-Redirect VSA,
which is attribute number 50 in the Juniper RADIUS dictionary. The URL is forwarded from the AAA server
to the switch in the same RADIUS Access-Accept message that contains the dynamic firewall filter. You
can also configure the redirect URL locally on the host interface by using the CLI statement redirect-url
at the [edit protocols dot1x authenticator interface interface-name] hierarchy level. For more information
about configuring the redirect URL, see “Configuring Central Web Authentication” on page 477.

SEE ALSO

Understanding Dynamic Filters Based on RADIUS Attributes | 370

Understanding Dynamic VLAN Assignment Using RADIUS Attributes | 371
Filtering 802.1X Supplicants by Using RADIUS Server Attributes | 360

Configuring Central Web Authentication

IN THIS SECTION

Configuring Dynamic Firewall Filters for Central Web Authentication | 478

Configuring the Redirect URL for Central Web Authentication | 479

Guidelines for Configuring Central Web Authentication | 480

Central Web authentication is a fallback method of authentication in which the host’s Web browser is
redirected to a central Web authentication (CWA) server. The CWA server provides a web portal where
the user can enter a username and password. If these credentials are validated by the CWA server, the
user is authenticated and is allowed access to the network.

Central Web authentication is invoked after a host has failed MAC RADIUS authentication. The switch,
operating as the authenticator, receives a RADIUS Access-Accept message from the AAA server that
 478

includes a dynamic firewall filter and a redirect URL for central Web authentication. The dynamic firewall
filter and the redirect URL must both be present for the central Web authentication process to be triggered.

Configuring Dynamic Firewall Filters for Central Web Authentication

Dynamic firewall filters are used in central Web authentication to enable the host to get an IP address
from a DHCP server, which allows the host to access the network. The filters are defined on the AAA
server using RADIUS attributes, which are sent to the authenticator in an Access-Accept message. You
can define the filter using either the Juniper-Switching-Filter attribute, which is a vendor-specific attribute
(VSA), or the Filter-ID attribute, which is an IETF RADIUS attribute.

• To use the Juniper-Switching-Filter VSA for central Web authentication, you must configure the filter
terms directly on the AAA server. The filter must include a term to match the destination IP address of
the CWA server with the action allow.

For example:

001122334455 Auth-Type := EAP, Cleartext-Password :="001122334455"

Session-Timeout = "300",
Juniper-CWA-Redirect-URL = "https://10.10.10.10",
Juniper-Switching-Filter = "Match Destination-ip 10.10.10.10 Action allow,
Match ip-protocol 17 Action allow, Match Destination-mac 00:01:02:33:44:55 Action
deny"

NOTE: The switch does not resolve the DNS queries for the redirect URL. You must configure
the Juniper-Switching-Filter attribute to allow the destination IP address of the CWA server.

• To use the Filter-ID attribute for central Web authentication, enter JNPR_RSVD_FILTER_CWA as the
value for the attribute on the AAA server. The filter terms for this attribute are internally defined for
central Web authentication, because of which no additional configuration is required.

For example:

001122334455 Auth-Type := EAP, Cleartext-Password :="001122334455"

Session-Timeout = "300",
Juniper-CWA-Redirect-URL = "https://10.10.10.10",
Filter-Id = "JNPR_RSVD_FILTER_CWA",

For more information about configuring dynamic firewall filters on the AAA server, see the documentation
for your AAA server.
 479

Configuring the Redirect URL for Central Web Authentication

In central Web authentication, the authenticator redirects the host’s Web browser request to the CWA
server by using a redirect URL. The redirect URL for central Web authentication can be configured on the
AAA server or locally on the host interface.

• To configure the redirect URL on the AAA server, use the Juniper-CWA-Redirect VSA, which is attribute
number 50 in the Juniper RADIUS dictionary. The URL is forwarded from the AAA server to the switch
in the same RADIUS Access-Accept message that contains the dynamic firewall filter.

For example:

001122334455 Auth-Type := EAP, Cleartext-Password :="001122334455"

Session-Timeout = "300",
Juniper-CWA-Redirect-URL = "https://10.10.10.10",
Filter-Id = "JNPR_RSVD_FILTER_CWA",

NOTE: When the special Filter-ID attribute JNPR_RSVD_FILTER_CWA is used for the dynamic
firewall filter, the redirect URL must include the IP address of the AAA server, for example,
https://10.10.10.10.

• To configure the redirect URL locally on the host interface, use the following CLI statement:

[edit]
user@switch# set protocols dot1x authenticator interface interface-name redirect-url

For example:

user@switch# show protocols dot1x

authenticator {
authentication-name-profile auth1;
interface {
ge-0/0/1.0 {
supplicant single;
mac-radius;
redirect-url https://10.10.10.10;
}
}
}
 480

Guidelines for Configuring Central Web Authentication

Central Web authentication is triggered after the failure of MAC RADIUS authentication when the redirect
URL and dynamic firewall filter are both present. The redirect URL and dynamic firewall filter can be
configured in any of the following combinations:

1. The AAA server sends both the CWA redirect URL and dynamic firewall filter to the authenticator. The
redirect URL is configured on the AAA server by using the Juniper-CWA-Redirect VSA and the dynamic
firewall filter is configured on the AAA server by using the Juniper-Switching-Filter VSA. The filter must
be configured to allow the destination IP address of the CWA server in this case.

2. The AAA server sends the dynamic firewall filter to the authenticator and the redirect URL is configured
locally on the host port. The redirect URL is configured on the authenticator by using the redirect-url
CLI statement and the dynamic firewall filter is configured on the AAA server by using the
Juniper-Switching-Filter VSA. The filter must be configured to allow the destination IP address of the
CWA server in this case.

3. The AAA server sends both the CWA redirect URL and dynamic firewall filter to the authenticator. The
redirect URL is configured on the AAA server by using the Juniper-CWA-Redirect VSA and the dynamic
firewall filter is configured on the AAA server by using the Filter-ID attribute with the value
JNPR_RSVD_FILTER_CWA. The redirect URL must contain the IP address of the CWA server in this
case.

4. The AAA server sends the dynamic firewall filter to the authenticator and the redirect URL is configured
locally on the host port. The redirect URL is configured on the authenticator by using the redirect-url
CLI statement and the dynamic firewall filter is configured on the AAA server by using the Filter-ID
attribute with the value JNPR_RSVD_FILTER_CWA. The redirect URL must contain the IP address of
the CWA server in this case.

RELATED DOCUMENTATION

Configuring Central Web Authentication with EX Series Switches and Aruba ClearPass
 481

Centralized Access Control to Network Resources on

EX Series Switches

IN THIS SECTION

Understanding Centralized Network Access Control and EX Series Switches | 481

Configuring an EX Series Switch to Use Junos Pulse Access Control Service for Network Access Control
(CLI Procedure) | 484

OBSOLETE: Configuring the EX Series Switch for Captive Portal Authentication with Junos Pulse Access
Control Service (CLI Procedure) | 488

Network access control (NAC) allows you to control access to network resources such as servers,
applications, and stored data.

You can use Junos Pulse Access Control Service and the switches for a centralized end-to-end NAC system.
The Access Control Service eliminates the need to configure firewall filters on each switch. Instead, you
define resource access policies centrally on the NAC device. For more information, read this topic.

Understanding Centralized Network Access Control and EX Series Switches

IN THIS SECTION

NAC Using Any RADIUS Server and Access Polices Defined on the Local Switch | 482

Centralized NAC Using Junos Pulse Access Control Service | 482

Captive Portal Authentication | 483

 482

Network access control (NAC) allows you to control who is admitted to the network and what
resources—servers, applications, and stored data—those users are allowed to access. These controls include:

• Authentication—Pre-admission controls

• Authorization—Post-admission controls

You can use different methods to implement NAC on Juniper Networks EX Series Ethernet Switches.

This topic describes:

NAC Using Any RADIUS Server and Access Polices Defined on the Local Switch

For pre-admission controls, you can use the switch in combination with any RADIUS server as the
authentication server. For additional information, see “Understanding Authentication on Switches” on
page 326.

For post-admission controls, you can configure firewall filters to limit access to specific resources. For
additional information, see Firewall Filters for EX Series Switches Overview.

Centralized NAC Using Junos Pulse Access Control Service

You can use Junos Pulse Access Control Service and the switches for a centralized end-to-end NAC system,
including both pre-admission authentication and post-admission authorization.

When you configure such a system, the Juniper Networks MAG Series Junos Pulse Gateways or the Juniper
Networks IC Series Unified Access Control Appliances NAC device functions as the authentication server.
For messages relating to IEEE 802.1X and MAC RADIUS authentication, the NAC device communicates
with the switch using the RADIUS protocol.

The Access Control Service also performs additional functions. It eliminates the need to configure firewall
filters on each switch. Instead, you define resource access policies centrally on the NAC device. This
centralized method is particularly helpful when you have multiple switches in your network.

The resource access policy on the Access Control Service defines which network resources are allowed
and denied for a user, based upon the user’s role. The NAC device distributes these policies to all connected
switches. The NAC device thus functions as a centralized policy management server. For messages relating
to access policies, the NAC device communicates with the switch using the Junos UAC Enforcer Protocol
(JUEP). The switch converts the resource access policies into filter definitions and applies these to the
appropriate port.
 483

NOTE: With this solution, the EX Series switch serves as an Infranet Enforcer, that is, a policy
enforcement point for the Access Control Service. The Access Control Service sends auth table
entries and resource access policies when an endpoint successfully completes 802.1X
authentication or MAC authentication (unmanaged devices). Access for any endpoint is governed
by the resource access policies that you configure on the Access Control Service. Because
resource access policies are employed, firewall filters are not required for the switch configuration.

This integrated solution of Access Control Service and EX Series switches is easier to implement and much
more efficient than previous versions of Access Control Service and the switches. As soon the switch
connects to the MAG Series or IC Series NAC device, the Access Control Service pushes the role-based
policies to the switch via JUEP. This enables the user to access the network more quickly than previous
implementations, because the policy is already available on the switch and does not need to be pushed
from the centralized device at the time of user authentication. Moreover, the policy push happens only
once, which utilizes network bandwidth efficiently and makes this implementation suitable for scaled
environments.

If you change policies, the Access Control Service automatically pushes the updated policies to the
connected switch. The switch applies the policies dynamically without taking users through another
authentication transaction.

NOTE: Do not configure firewall filters on the switch and do not use RADIUS server attributes
for firewall filters if you are configuring the switch to use the Access Control Service. Instead,
specify or deny access to resources by using the Access Control Service resource access policies.

You create policies on the NAC device’s administrative interface to control access to resources and services.
Access is based on successful authentication, the user’s assigned role, and the security compliance of the
endpoint device. For example, you can provide full access to protected resources employee role and limited
access for a contractor role.

Captive Portal Authentication

Captive portal authentication allows you to authenticate users on the switches by redirecting Web browser
requests to a login page that requires users to input a username and password before they are allowed
access to the network. The details of configuring captive portal authentication differ depending on whether
you are using the Access Control Service:

• If you have connected the switch to the Access Control Service, use the Access Control Service NAC
device as an external captive portal server for redirecting Web browser requests. When users try to
access a protected network resource that is connected to the switch, the user must first sign in to the
 484

Access Control Service for authentication and endpoint security checking. The captive portal redirects
the user to a login page located on the Access Control Service. When the sign-in page for the Access
Control Service is displayed, the user signs in and the Access Control Service examines the endpoint for
compliance with security policies. If the endpoint passes the security check, access is granted to the
protected resource.

See “OBSOLETE: Configuring the EX Series Switch for Captive Portal Authentication with Junos Pulse
Access Control Service (CLI Procedure)” on page 488. You can use the same Access Control Service as
the external captive portal server for more than one switch.

• If you are not using the Access Control Service, you can use captive portal to redirect users to a login
page that you configure on the local switch. See “Designing a Captive Portal Authentication Login Page
on Switches” on page 458 for information about designing a login page on your switch.

Configuring an EX Series Switch to Use Junos Pulse Access Control Service

for Network Access Control (CLI Procedure)

You can connect the switch to Junos Pulse Access Control Service to set up a centralized, end-to-end
network access control (NAC) system, which allows you to control who is admitted to the network and
what resources those users are allowed to access.

The Access Control Service functions both as an authentication server (RADIUS server) and as a centralized
policy management server.

Before you begin configuring the switch to connect to the Access Control Service:

• Configure a resource access policy.

• Obtain the password of the Access Control Service.

• Obtain the IP address of the Access Control Service.

 485

NOTE: Specify the same IP address for the authentication server, the RADIUS server, and the
infranet controller (NAC device). These components refer to the same Access Control Service.

To configure the switch to work with the Access Control Service:

1. Configure the switch to use the Access Control Service for authentication and authorization:

[edit ethernet-switching-options]
user@switch# set uac-policy

2. Configure the access profile to specify the Access Control Service. The access profile contains the
authentication and authorization configuration that aids in handling authentication and authorization
requests, including the authentication method and sequence, and the Access Control Service address:

a. Configure radius as the authentication method to be used when attempting to authenticate a user.
For each login attempt, the software tries the authentication methods in order, starting with the
first one, until the password matches:

[edit access profile]

user@switch# set profile-name authentication-order radius

b. Specify the IP address of the authentication server:

NOTE: Specify the same IP address that you use for the RADIUS server and the NAC
device.

[edit access profile]

user@switch# set profile-name radius authentication-server ip-address

3. Configure the RADIUS server to use the same IP address that you specified for the authentication
server:

[edit access]
user@switch# set radius-server ip-address

4. Configure the password to use for connecting the switch with the RADIUS server:
 486

NOTE: The password specified here is used for RADIUS communications between the switch
and the Access Control Service. It does not need to match the password that is specified on
the Access Control Service through the administrative interface on the Access Control Service.

[edit access]
user@switch# set radius-server secret password

5. Configure the address of the Access Control Service MAG Series or the IC Series NAC device:

NOTE: Specify the hostname and IP address of the NAC device. This is the same IP address
that you used for specifying the authentication server.

[edit services united-access-control infranet-controller hostname]

user@switch# set address ip-address

6. Configure the switch’s management Ethernet interface for the NAC device:

[edit services united-access-control infranet-controller hostname]

user@switch# set interface me0.0

7. Configure the password for connecting the switch to the Access Control Service NAC device:

NOTE: This password must match the password specified on the Access Control Service
though its administrative interface. It is used for Junos UAC Enforcer Protocol (JUEP)
communications between the switch and the Access Control Service.

[edit services united-access-control infranet-controller hostname]

user@switch# set password password

8. Configure the amount of time that switch waits to receive a response from the Access Control Service:

[edit services united-access-control]

user@switch# set timeout seconds

9. Specify the time between continuity-check messages for the switch’s connection with the Access
Control Service:
 487

[edit services united-access-control]

user@switch# set interval seconds

10. Specify an action for the switch to take if a timeout occurs for the connection between the switch and
the Access Control Service:

[edit services united-access-control]

user@switch# set timeout-action action

11. Specify the name of the access profile to use for 802.1X, MAC RADIUS, or captive portal authentication:

NOTE: Use the same access profile that you configured previously (step 2).

[edit protocols dot1x]

user@switch# set authenticator authentication-profile-name profile-name

12. Configure the 802.1X interface that the switch will use for communicating with the Access Control
Service:

[edit protocols dot1x]

user@switch# set authenticator interface interface-name
 488

OBSOLETE: Configuring the EX Series Switch for Captive Portal

Authentication with Junos Pulse Access Control Service (CLI Procedure)

If you have connected the EX Series switch to the Junos Pulse Access Control Service and you want to
use the captive portal user authentication feature, configure the Access Control Service network access
control (NAC) device as an external captive portal server. The captive portal feature is required only for
user authentication. Unmanaged devices, such as printers or phones, can be authenticated through 802.1X
and MAC address authentication.

When users try to access a protected network resource that is connected to the switch, the user must
first sign in to the Access Control Service for authentication and endpoint security checking. The captive
portal redirects the user to a login page located on the Access Control Service.

When the sign-in page for the Access Control Service is displayed, the user signs in and the Access Control
Service examines the endpoint for compliance with security policies. If the endpoint passes the security
check, access is granted to the protected resource.

Before you begin, be sure you have:

• Designed your captive portal login page on the Access Control Service.

To configure the switch to use the Access Control Service for captive portal:

1. Configure captive portal to authenticate clients connected to the switch for access to use the
authentication profile that directs the client to the Access Control Service:

2. Enable an interface for use with captive portal authentication:

[edit]
user@switch# set services captive-portal interface interface-name supplicant multiple

3. (Optional) Specify which clients are to bypass captive portal authentication:

NOTE: You can use set ethernet-switching-options authentication-whitelist mac-address

interface interface-name to limit the scope to the interface.

RELATED DOCUMENTATION

Central Web Authentication | 474

Captive Portal Authentication | 449
 489

VoIP on EX Series Switches

IN THIS SECTION

Understanding 802.1X and VoIP on EX Series Switches | 489

Example: Setting Up VoIP with 802.1X and LLDP-MED on an EX Series Switch | 492

Example: Configuring VoIP on an EX Series Switch Without Including LLDP-MED Support | 501

Example: Configuring VoIP on an EX Series Switch Without Including LLDP-MED Support | 508

Example: Configuring VoIP on an EX Series Switch Without Including 802.1X Authentication | 514

Example: Setting Up VoIP with 802.1X and LLDP-MED on an EX Series Switch with ELS Support | 522

You can configure voice over IP (VoIP) on an EX Series switch to support IP telephones. When you use
VoIP, you can connect IP telephones to the switch and configure IEEE 802.1X authentication for
802.1X-compatible IP telephones. For more information, read this topic.

Understanding 802.1X and VoIP on EX Series Switches

When you use VoIP, you can connect IP telephones to the switch and configure IEEE 802.1X authentication
for 802.1X-compatible IP telephones. The 802.1X authentication provides network edge security, protecting
Ethernet LANs from unauthorized user access.

VoIP is a protocol used for the transmission of voice through packet-switched networks. VoIP transmits
voice calls by using a network connection instead of an analog phone line.

When VoIP is used with 802.1X, the RADIUS server authenticates the phone, and Link Layer Discovery
Protocol–Media Endpoint Discovery (LLDP-MED) provides the class-of-service (CoS) parameters to the
phone.

You can configure 802.1X authentication to work with VoIP in multiple supplicant or single supplicant
mode. In multiple supplicant mode, the 802.1X process allows multiple supplicants to connect to the
interface. Each supplicant is authenticated individually. For an example of a VoIP multiple supplicant
topology, see Figure 21 on page 490.
 490

Figure 21: VoIP Multiple Supplicant Topology

If an 802.1X-compatible IP telephone does not have an 802.1X host but has another 802.1X-compatible
device connected to its data port, you can connect the phone to an interface in single supplicant mode.
In single supplicant mode, the 802.1X process authenticates only the first supplicant. All other supplicants
who connect later to the interface are allowed full access without any further authentication. They
effectively “piggyback” on the first supplicant’s authentication. For an example of a VoIP single supplicant
topology, see Figure 22 on page 491 .
 491

Figure 22: VoIP Single Supplicant Topology

If an IP telephone does not support 802.1X, you can configure VoIP to bypass 802.1X and LLDP-MED
and have the packets forwarded to a VoIP VLAN.

Multi Domain 802.1X Authentication

Multi-domain 802.1X authentication is an extension of multiple supplicant mode that allows one default
VoIP device and multiple data devices to authenticate on a single port. Multi-domain 802.1X authentication
provides enhanced security over multiple supplicant mode by restricting the number of authenticated data
and VoIP sessions on the port. In multiple supplicant mode, any number of VoIP or data sessions can be
authenticated; the number of sessions can be restricted using MAC limiting, but there is no way to apply
the limit specifically to either data or VoIP sessions.

With multi-domain 802.1X authentication, the single port is divided into two domains; one is the data
domain and the other is the voice domain. Multi-domain 802.1X authentication maintains separate session
counts based on the domain. You can configure the maximum number of authenticated data sessions
allowed on the port. The number of VoIP sessions is not configurable; only one authenticated VoIP session
is allowed on the port.

If a new client attempts to authenticate on the interface after the maximum session count has been reached,
the default action is to drop the packet and generate an error log message. You can also configure the
action to shut down the interface. The port can be manually recovered from the down state by issuing the
 492

clear dot1x recovery-timeout command, or by can recover automatically after a configured recovery
timeout period.

Multi-domain authentication does not enforce the order of device authentication. However, for the best
results, the VoIP device should be authenticated before a data device on a multi domain 802.1X-enabled
port. Multi-domain authentication is supported only in multiple supplicant mode.

SEE ALSO

Understanding LLDP and LLDP-MED on EX Series Switches | 623

Example: Setting Up VoIP with 802.1X and LLDP-MED on an EX Series

Switch

IN THIS SECTION

Requirements | 493

Overview and Topology | 493

Configuration | 495

Verification | 498

You can configure voice over IP (VoIP) on an EX Series switch to support IP telephones. The Link Layer
Discovery Protocol–Media Endpoint Discovery (LLDP-MED) protocol forwards VoIP parameters from the
switch to the phone. You also configure 802.1X authentication to allow the telephone access to the LAN.
Authentication is done through a backend RADIUS server.

This example describes how to configure VoIP on an EX Series switch to support an Avaya IP phone, as
well as the LLDP-MED protocol and 802.1X authentication:

NOTE: If your switch runs Junos OS for EX Series switches with support for the Enhanced Layer
2 Software (ELS) configuration style, see “Example: Setting Up VoIP with 802.1X and LLDP-MED
on an EX Series Switch with ELS Support” on page 522. For ELS details, see Using the Enhanced
Layer 2 Software CLI.
 493

Requirements

This example uses the following hardware and software components:

• Junos OS Release 9.1 or later for EX Series switches

• One EX Series switch acting as an authenticator port access entity (PAE). The interfaces on the
authenticator PAE form a control gate that blocks all traffic to and from supplicants until they are
authenticated.

• An Avaya 9620 IP telephone that supports LLDP-MED and 802.1X

Before you configure VoIP, be sure you have:

• Installed your EX Series switch. See Installing and Connecting an EX3200 Switch.

• Performed the initial switch configuration. See Connecting and Configuring an EX Series Switch (J-Web
Procedure).

• Performed basic bridging and VLAN configuration on the switch. See Example: Setting Up Basic Bridging
and a VLAN for an EX Series Switch.

• Configured the RADIUS server for 802.1X authentication and set up the access profile. See “Example:
Connecting a RADIUS Server for 802.1X to an EX Series Switch” on page 365.

• (Optional) Configured interface ge-0/0/2 for Power over Ethernet (PoE). The PoE configuration is not
necessary if the VoIP supplicant is using a power adapter. For information about configuring PoE, see
Configuring PoE on EX Series Switches (CLI Procedure).

NOTE: If the IP address isn't configured on the Avaya IP phone, the phone exchanges LLDP-MED
information to get the VLAN ID for the voice VLAN. You must configure the voip statement on
the interface to designate the interface as a VoIP interface and allow the switch to forward the
VLAN name and VLAN ID for the voice VLAN to the IP telephone. The IP telephone then uses
the voice VLAN (that is, it references the voice VLAN’s ID) to send a DHCP discover request
and exchange information with the DHCP server (voice gateway).

Overview and Topology

Instead of using a regular telephone, you connect an IP telephone directly to the switch. An IP phone has
all the hardware and software needed to handle VoIP. You also can power an IP telephone by connecting
it to one of the Power over Ethernet (PoE) interfaces on the switch.

In this example, the access interface ge-0/0/2 on the EX4200 switch is connected to an Avaya 9620 IP
telephone. Avaya phones have a built-in bridge that allows you to connect a desktop PC to the phone, so
 494

the desktop and phone in a single office require only one interface on the switch. The EX Series switch is
connected to a RADIUS server on interface ge-0/0/10 (see Figure 23 on page 494).

Figure 23: VoIP Topology

In this example, you configure VoIP parameters and specify the forwarding class assured-forward for voice
traffic to provide the highest quality of service.

Table 34 on page 495 describes the components used in this VoIP configuration example.
 495

Table 34: Components of the VoIP Configuration Topology

Property Settings

Switch hardware EX4200 switch

VLAN names data-vlan

voice-vlan

Connection to Avaya phone—with integrated hub, to connect ge-0/0/2

phone and desktop PC to a single interface (requires PoE)

One RADIUS server Provides backend database connected to the switch

through interface ge-0/0/10.

As well as configuring a VoIP for interface ge-0/0/2, you configure:

• 802.1X authentication. Authentication is set to multiple supplicant to support more than one supplicant's
access to the LAN through interface ge-0/0/2.

• LLDP-MED protocol information. The switch uses LLDP-MED to forward VoIP parameters to the phone.
Using LLDP-MED ensures that voice traffic gets tagged and prioritized with the correct values at the
source itself. For example, 802.1p class of service and 802.1Q tag information can be sent to the IP
telephone.

NOTE: A PoE configuration is not necessary if an IP telephone is using a power adapter.

Configuration

To configure VoIP, LLDP-MED, and 802.1X authentication:

CLI Quick Configuration

To quickly configure VoIP, LLDP-MED, and 802.1X, copy the following commands and paste them into
the switch terminal window:

[edit]

set vlans data-vlan vlan-id 77

set vlans voice-vlan vlan-id 99

set vlans data-vlan interface ge-0/0/2.0

set interfaces ge-0/0/2 unit 0 family ethernet-switching vlan members data-vlan

 496

set interfaces ge-0/0/2 unit 0 family ethernet-switching port-mode access

set ethernet-switching-options voip interface ge-0/0/2.0 vlan voice-vlan

set ethernet-switching-options voip interface ge-0/0/2.0 forwarding-class assured-forwarding

set protocols lldp-med interface ge-0/0/2.0

set protocols dot1x authenticator interface ge-0/0/2.0 supplicant multiple

Step-by-Step Procedure
To configure VoIP with LLDP-MED and 802.1X:

1. Configure the VLANs for voice and data:

[edit vlans]
user@switch# set data-vlan vlan-id 77
user@switch# set voice-vlan vlan-id 99

2. Associate the VLAN data-vlan with the interface:

[edit vlans]
user@switch# set data-vlan interface ge-0/0/2.0

3. Configure the interface as an access interface, configure support for Ethernet switching, and add the
data-vlan VLAN:

[edit interfaces]
user@switch# set ge-0/0/2 unit 0 family ethernet-switching vlan members data-vlan
user@switch# set ge-0/0/2 unit 0 family ethernet-switching port-mode access

4. Configure VoIP on the interface and specify the assured-forwarding forwarding class to provide the
most dependable class of service:

[edit ethernet—switching—options]
user@switch# set voip interface ge-0/0/2.0 vlan voice-vlan
user@switch# set voip interface ge-0/0/2.0 forwarding-class assured-forwarding

5. Configure LLDP-MED protocol support:

[edit protocols]
user@switch# set lldp-med interface ge-0/0/2.0

6. To authenticate an IP phone and a PC connected to the IP phone on the interface, configure 802.1X
authentication support and specify multiple supplicant mode:
 497

NOTE: If you do not want to authenticate any device, skip the 802.1X configuration on this
interface.

[edit protocols]
user@switch# set dot1x authenticator interface ge-0/0/2.0 supplicant multiple

Results
Display the results of the configuration:

[edit]
user@switch# show configuration
interfaces {
ge-0/0/2 {
unit 0 {
family ethernet-switching {
port-mode access;
vlan {
members data-vlan;
}
}
}
}
}
protocols {
lldp-med {
interface ge-0/0/2.0;
}
dot1x {
authenticator {
interface {
ge-0/0/2.0 {
supplicant multiple;
}
}
}
}
}
vlans {
data-vlan {
vlan-id 77;
 498

interface {
ge-0/0/2.0;
}
}
voice-vlan {
vlan-id 99;
}
}
ethernet-switching options {
voip {
interface ge-0/0/2.0 {
vlan voice-vlan;
forwarding-class assured-forwarding;
}
}
}

Verification

IN THIS SECTION

Verifying LLDP-MED Configuration | 498

Verifying 802.1X Authentication for IP Phone and Desktop PC | 499

Verifying the VLAN Association with the Interface | 500

To confirm that the configuration is working properly, perform these tasks:

Verifying LLDP-MED Configuration

Purpose
Verify that LLDP-MED is enabled on the interface.

Action

user@switch> show lldp detail

LLDP : Enabled
Advertisement interval : 30 Second(s)
Transmit delay : 2 Second(s)
 499

Hold timer : 2 Second(s)

Config Trap Interval : 300 Second(s)
Connection Hold timer : 60 Second(s)

LLDP MED : Enabled

MED fast start count : 3 Packet(s)

Interface LLDP LLDP-MED Neighbor count

all Enabled - 0
ge-0/0/2.0 - Enabled 0

Interface VLAN-id VLAN-name

ge-0/0/0.0 0 default
ge-0/0/1.0 0 employee-vlan
ge-0/0/2.0 0 data-vlan
ge-0/0/2.0 99 voice-vlan
ge-0/0/3.0 0 employee-vlan
ge-0/0/8.0 0 employee-vlan
ge-0/0/10.0 0 default
ge-0/0/11.0 20 employee-vlan
ge-0/0/23.0 0 default

LLDP basic TLVs supported:

Chassis identifier, Port identifier, Port description, System name, System
description, System capabilities, Management address.

LLDP 802 TLVs supported:

Power via MDI, Link aggregation, Maximum frame size, Port VLAN tag, Port
VLAN name.

LLDP MED TLVs supported:

LLDP MED capabilities, Network policy, Endpoint location, Extended power
Via MDI.

Meaning
The show lldp detail output shows that both LLDP and LLDP-MED are configured on the ge-0/0/2.0
interface. The end of the output shows the list of supported LLDP basic TLVs, 802.3 TLVs, and LLDP-MED
TLVs that are supported.

Verifying 802.1X Authentication for IP Phone and Desktop PC

Purpose
 500

Display the 802.1X configuration to confirm that the VoIP interface has access to the LAN.

Action

user@switch> show dot1x interface ge/0/0/2.0 detail

ge-0/0/2.0
Role: Authenticator
Administrative state: Auto
Supplicant mode: Multiple
Number of retries: 3
Quiet period: 60 seconds
Transmit period: 30 seconds
Mac Radius: Disabled
Mac Radius Restrict: Disabled
Reauthentication: Enabled
Configured Reauthentication interval: 3600 seconds
Supplicant timeout: 30 seconds
Server timeout: 30 seconds
Maximum EAPOL requests: 2
Guest VLAN member: <not configured>
Number of connected supplicants: 1
Supplicant: user101, 00:04:0f:fd:ac:fe
Operational state: Authenticated
Authentication method: Radius
Authenticated VLAN: vo11
Dynamic Filter: match source-dot1q-tag 10 action deny
Session Reauth interval: 60 seconds
Reauthentication due in 50 seconds

Meaning
The field Role shows that the ge-0/0/2.0 interface is in the authenticator state. The Supplicant field shows
that the interface is configured in multiple supplicant mode, permitting multiple supplicants to be
authenticated on this interface. The MAC addresses of the supplicants currently connected are displayed
at the bottom of the output.

Verifying the VLAN Association with the Interface

Purpose
Display the interface state and VLAN membership.

Action

user@switch> show ethernet-switching interfaces

 501

Ethernet-switching table: 0 entries, 0 learned

user@switch> show ethernet-switching interfaces

Interface State VLAN members Blocking
ge-0/0/0.0 down default unblocked
ge-0/0/1.0 down employee-vlan unblocked
ge-0/0/5.0 down employee-vlan unblocked
ge-0/0/3.0 down employee-vlan unblocked
ge-0/0/8.0 down employee-vlan unblocked
ge-0/0/10.0 down default unblocked
ge-0/0/11.0 down employee-vlan unblocked
ge-0/0/23.0 down default unblocked
ge-0/0/2.0 up voice-vlan unblocked
data-vlan unblocked

Meaning
The field VLAN members shows that the ge-0/0/2.0 interface supports both the data-vlan VLAN and
voice-vlan VLAN. The State field shows that the interface is up.

SEE ALSO

Example: Connecting a RADIUS Server for 802.1X to an EX Series Switch | 365

Example: Setting Up 802.1X for Single-Supplicant or Multiple-Supplicant Configurations on an EX
Series Switch | 405
Defining CoS Forwarding Classes (CLI Procedure)
Defining CoS Forwarding Classes (J-Web Procedure)
Configuring LLDP-MED (CLI Procedure) | 627

Example: Configuring VoIP on an EX Series Switch Without Including

LLDP-MED Support

IN THIS SECTION

Requirements | 502

Overview | 502

Configuring VoIP Without LLDP-MED by Using a Voice VLAN on an Access Port | 503
 502

Configuring VoIP Without LLDP-MED by Using a Trunk Port with Native VLAN Option | 505

Verification | 507

You can configure voice over IP (VoIP) on an EX Series switch to support IP telephones. The Link Layer
Discovery Protocol–Media Endpoint Discovery (LLDP-MED) protocol is sometimes used with IP phones
to forward VoIP parameters from the switch to the phone. However, not all IP phones support LLDP-MED.

This example describes how to configure VoIP on an EX Series switch without using LLDP-MED:

Requirements

This example uses the following hardware and software components:

• One EX Series switch with support for ELS acting as an authenticator port access entity (PAE). The
interfaces on the authenticator PAE form a control gate that blocks all traffic to and from supplicants
until they are authenticated.

• An IP phone that does not support LLDP-MED.

• Junos OS Release 13.2X50 or later for EX Series switches.

Before you configure VoIP, be sure you have:

• Performed basic bridging and VLAN configuration on the switch. See Example: Setting Up Basic Bridging
and a VLAN for an EX Series Switch with ELS Support .

• Configured the IP phone as a member of the voice VLAN.

• (Optional) Configured interface ge-0/0/2 for Power over Ethernet (PoE). The PoE configuration is not
necessary if the VoIP supplicant is using a power adapter. See Configuring PoE on EX Series Switches (CLI
Procedure).

Overview

Instead of using a regular telephone, you connect an IP telephone directly to the switch. An IP phone has
all the hardware and software needed to handle VoIP. You can also power an IP telephone by connecting
it to one of the Power over Ethernet (PoE) interfaces on the switch.

EX Series switches can accommodate an IP telephone and end host connected to a single switch port. In
such a scenario, voice and data traffic must be separated into different broadcast domains, or VLANs. One
method for accomplishing this is by configuring a voice VLAN, which enables access ports to accept
untagged data traffic as well as tagged voice traffic from IP phones, and associate each type of traffic with
 503

separate and distinct VLANs. Voice traffic (tagged) can then be treated differently, generally with a higher
priority than data traffic (untagged).

The voice VLAN delivers the greatest benefit when used with IP phones that support LLDP-MED, but it
is flexible enough that IP phones that do not support LLDP-MED can also use it effectively. However, in
the absence of LLDP-MED, the voice VLAN ID must be set manually on the IP phone because LLDP-MED
is not available to accomplish this dynamically. For information about setting up a voice VLAN for IP phones
that support LLDP-MED, see “Example: Setting Up VoIP with 802.1X and LLDP-MED on an EX Series
Switch with ELS Support” on page 522.

Another method to separate voice (tagged) and data (untagged) traffic into different VLANs is to use a
trunk port with the native VLAN ID option. The trunk port is added as a member of the voice VLAN, and
processes only tagged voice traffic from that VLAN. The trunk port must also be configured with the native
VLAN ID for the data VLAN so that it can process untagged data traffic from the data VLAN. This
configuration also requires that the voice VLAN ID be set manually on the IP phone.

This example illustrates both methods. In this example, the interface ge-0/0/2 on the switch is connected
to a non-LLDP-MED IP phone.

NOTE: The implementation of a voice VLAN on an IP telephone is vendor-specific. Consult the

documentation that came with your IP telephone for instructions on configuring a voice VLAN.
For example, on an Avaya phone, you can ensure that the phone gets the correct VoIP VLAN
ID even in the absence of LLDP-MED by enabling DHCP option 176.

Configuring VoIP Without LLDP-MED by Using a Voice VLAN on an Access Port

CLI Quick Configuration

To quickly configure VoIP, copy the following commands and paste them into the switch terminal window:

[edit]

set vlans data-vlan vlan-id 77

set vlans voice-vlan vlan-id 99

set vlans data-vlan switch-options interface ge-0/0/2.0

set interfaces ge-0/0/2 unit 0 family ethernet-switching port-mode access

set interfaces ge-0/0/2 unit 0 family ethernet-switching vlan members data-vlan

set switch-options voip interface ge-0/0/2.0 vlan voice-vlan

set switch-options voip interface ge-0/0/2.0 forwarding-class assured-forwarding

 504

Step-by-Step Procedure
1. Configure two VLANs: one for data traffic and one for voice traffic:

[edit vlans]
user@switch# set data-vlan vlan-id 77
user@switch# set voice-vlan vlan-id 99

NOTE: The voice VLAN ID must be set manually on the IP phone.

2. Associate the VLAN data-vlan with the interface ge-0/0/2:

[edit vlans]
user@switch# set data-vlan switch-options interface ge-0/0/2.0

3. Configure the interface ge-0/0/2 as an access port belonging to the data VLAN:

[edit interfaces]
user@switch# set ge-0/0/2 unit 0 family ethernet-switching port-mode access
user@switch# set ge-0/0/2 unit 0 family ethernet-switching vlan member data-vlan

4. Configure VoIP on the interface ge-0/0/2 and add this interface to the voice VLAN:

[edit switch-options]
user@switch# set voip interface ge-0/0/2.0 vlan voice-vlan

5. Specify the assured-forwarding forwarding class to provide the most dependable class of service:

[edit switch-options]
user@switch# set voip interface ge-0/0/2.0 forwarding-class assured-forwarding

Results
Display the results of the configuration:

[edit]
user@switch> show configuration
interfaces {
ge-0/0/2 {
unit 0 {
family ethernet-switching {
port-mode access;
 505

vlan {
members data-vlan;
}
}
}
}
}
vlans {
data-vlan {
vlan-id 77;
interface {
ge-0/0/2.0;
}
}
voice-vlan {
vlan-id 99;
}
}
ethernet-switching options {
voip {
interface ge-0/0/2.0 {
vlan voice-vlan;
forwarding-class assured-forwarding;
}
}
}

Configuring VoIP Without LLDP-MED by Using a Trunk Port with Native VLAN Option

CLI Quick Configuration

To quickly configure VoIP, copy the following commands and paste them into the switch terminal window:

[edit]

set vlans data-vlan vlan-id 77

set vlans voice-vlan vlan-id 99

set interfaces ge-0/0/2 unit 0 family ethernet-switching port-mode trunk

set interfaces ge-0/0/2 unit 0 family ethernet-switching vlan members voice-vlan

set interfaces ge-0/0/2 unit 0 family ethernet-switching native-vlan-id data-vlan

Step-by-Step Procedure
 506

1. Configure two VLANs: one for data traffic and one for voice traffic:

[edit vlans]
user@switch# set data-vlan vlan-id 77
user@switch# set voice-vlan vlan-id 99

NOTE: The voice VLAN ID must be set manually on the IP phone.

2. Configure interface ge-0/0/2 as a trunk port that includes only the voice VLAN:

[edit interfaces]
user@switch# set ge-0/0/2 unit 0 family ethernet-switching port-mode trunk
user@switch# set ge-0/0/2 unit 0 family ethernet-switching vlan member voice-vlan

3. Configure the native VLAN ID for the data VLAN on the trunk port:

[edit interfaces]
user@switch# set ge-0/0/2 unit 0 family ethernet-switching native-vlan-id data-vlan

Results
Display the results of the configuration:

[edit]
user@switch> show configuration
interfaces {
ge-0/0/2 {
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members voice-vlan;
}
native-vlan-id data-vlan;
}
}
}
}
vlans {
data-vlan {
vlan-id 77;
 507

}
voice-vlan {
vlan-id 99;
}
}

Verification

IN THIS SECTION

Verifying the VLAN Association With the Interface | 507

To confirm that the configuration is working properly, perform the following task:

Verifying the VLAN Association With the Interface

Purpose
Display the interface state and VLAN membership.

Action

user@switch> show ethernet-switching interfaces

Ethernet-switching table: 0 entries, 0 learned

user@switch> show ethernet-switching interfaces

Interface State VLAN members Blocking
ge-0/0/0.0 down default unblocked
ge-0/0/1.0 down employee-vlan unblocked
ge-0/0/5.0 down employee-vlan unblocked
ge-0/0/3.0 down employee-vlan unblocked
ge-0/0/8.0 down employee-vlan unblocked
ge-0/0/10.0 down default unblocked
ge-0/0/11.0 down employee-vlan unblocked
ge-0/0/23.0 down default unblocked
ge-0/0/2.0 up voice-vlan unblocked
data-vlan unblocked

Meaning
 508

The field VLAN members shows that the ge-0/0/2.0 interface supports both the data VLAN, data-vlan,
and the voice VLAN, voice-vlan. The State field shows that the interface is up.

SEE ALSO

Understanding LLDP and LLDP-MED on EX Series Switches | 623

Example: Configuring VoIP on an EX Series Switch Without Including

LLDP-MED Support

IN THIS SECTION

Requirements | 508

Overview | 509

Configuring VoIP Without LLDP-MED by Using a Voice VLAN on an Access Port | 510

Configuring VoIP Without LLDP-MED by Using a Trunk Port with Native VLAN Option | 511

Verification | 513

You can configure voice over IP (VoIP) on an EX Series switch to support IP telephones. The Link Layer
Discovery Protocol–Media Endpoint Discovery (LLDP-MED) protocol is sometimes used with IP phones
to forward VoIP parameters from the switch to the phone. However, not all IP phones support LLDP-MED.

This example describes how to configure VoIP on an EX Series switch without using LLDP-MED:

Requirements

This example uses the following hardware and software components:

• One EX4200 switch acting as an authenticator port access entity (PAE). The interfaces on the
authenticator PAE form a control gate that blocks all traffic to and from supplicants until they are
authenticated.

• An IP phone that does not support LLDP-MED.

• Junos OS Release 9.1 or later for EX Series switches.

Before you configure VoIP, be sure you have:

 509

• Performed basic bridging and VLAN configuration on the switch. See Example: Setting Up Basic Bridging
and a VLAN for an EX Series Switch.

• Configured the IP phone as a member of the voice VLAN.

• (Optional) Configured interface ge-0/0/2 for Power over Ethernet (PoE). The PoE configuration is not
necessary if the VoIP supplicant is using a power adapter. See Configuring PoE on EX Series Switches (CLI
Procedure).

Overview

Instead of using a regular telephone, you connect an IP telephone directly to the switch. An IP phone has
all the hardware and software needed to handle VoIP. You can also power an IP telephone by connecting
it to one of the Power over Ethernet (PoE) interfaces on the switch.

EX Series switches can accommodate an IP telephone and end host connected to a single switch port. In
such a scenario, voice and data traffic must be separated into different broadcast domains, or VLANs. One
method for accomplishing this is by configuring a voice VLAN, which enables access ports to accept
untagged data traffic as well as tagged voice traffic from IP phones, and associate each type of traffic with
separate and distinct VLANs. Voice traffic (tagged) can then be treated differently, generally with a higher
priority than data traffic (untagged).

The voice VLAN delivers the greatest benefit when used with IP phones that support LLDP-MED, but it
is flexible enough that IP phones that do not support LLDP-MED can also use it effectively. However, in
the absence of LLDP-MED, the voice VLAN ID must be set manually on the IP phone because LLDP-MED
is not available to accomplish this dynamically. For information about setting up a voice VLAN for IP phones
that support LLDP-MED, see “Example: Setting Up VoIP with 802.1X and LLDP-MED on an EX Series
Switch” on page 492.

Another method to separate voice (tagged) and data (untagged) traffic into different VLANs is to use a
trunk port with the native VLAN ID option. The trunk port is added as a member of the voice VLAN, and
processes only tagged voice traffic from that VLAN. The trunk port must also be configured with the native
VLAN ID for the data VLAN so that it can process untagged data traffic from the data VLAN. This
configuration also requires that the voice VLAN ID be set manually on the IP phone.

This example illustrates both methods. In this example, the interface ge-0/0/2 on the EX4200 switch is
connected to a non-LLDP-MED IP phone.

NOTE: The implementation of a voice VLAN on an IP telephone is vendor-specific. Consult the

documentation that came with your IP telephone for instructions on configuring a voice VLAN.
For example, on an Avaya phone, you can ensure that the phone gets the correct VoIP VLAN
ID even in the absence of LLDP-MED by enabling DHCP option 176.
 510

Configuring VoIP Without LLDP-MED by Using a Voice VLAN on an Access Port

CLI Quick Configuration

To quickly configure VoIP, copy the following commands and paste them into the switch terminal window:

[edit]

set vlans data-vlan vlan-id 77

set vlans voice-vlan vlan-id 99

set vlans data-vlan interface ge-0/0/2.0

set interfaces ge-0/0/2 unit 0 family ethernet-switching port-mode access

set interfaces ge-0/0/2 unit 0 family ethernet-switching vlan members data-vlan

set ethernet-switching-options voip interface ge-0/0/2.0 vlan voice-vlan

Step-by-Step Procedure
1. Configure two VLANs: one for data traffic and one for voice traffic:

[edit vlans]
user@switch# set data-vlan vlan-id 77
user@switch# set voice-vlan vlan-id 99

NOTE: The voice VLAN ID must be set manually on the IP phone.

2. Configure the VLAN data-vlan on the interface ge-0/0/2:

[edit vlans]
user@switch# set data-vlan interface ge-0/0/2.0

3. Configure the interface ge-0/0/2 as an access port belonging to the data VLAN:

[edit interfaces]
user@switch# set ge-0/0/2 unit 0 family ethernet-switching port-mode access
user@switch# set ge-0/0/2 unit 0 family ethernet-switching vlan member data-vlan

4. Configure VoIP on the interface ge-0/0/2 and add this interface to the voice VLAN:

[edit ethernet-switching-options]
user@switch# set voip interface ge-0/0/2.0 vlan voice-vlan
 511

Results
Display the results of the configuration:

[edit]
user@switch> show configuration
interfaces {
ge-0/0/2 {
unit 0 {
family ethernet-switching {
port-mode access;
vlan {
members data-vlan;
}
}
}
}
}
vlans {
data-vlan {
vlan-id 77;
interface {
ge-0/0/2.0;
}
}
voice-vlan {
vlan-id 99;
}
}
ethernet-switching options {
voip {
interface ge-0/0/2.0 {
vlan voice-vlan;
}
}
}

Configuring VoIP Without LLDP-MED by Using a Trunk Port with Native VLAN Option

CLI Quick Configuration

To quickly configure VoIP, copy the following commands and paste them into the switch terminal window:

[edit]

set vlans data-vlan vlan-id 77

 512

set vlans voice-vlan vlan-id 99

set interfaces ge-0/0/2 unit 0 family ethernet-switching port-mode trunk

set interfaces ge-0/0/2 unit 0 family ethernet-switching vlan members voice-vlan

set interfaces ge-0/0/2 unit 0 family ethernet-switching native-vlan-id data-vlan

Step-by-Step Procedure
1. Configure two VLANs: one for data traffic and one for voice traffic:

[edit vlans]
user@switch# set data-vlan vlan-id 77
user@switch# set voice-vlan vlan-id 99

NOTE: The voice VLAN ID must be set manually on the IP phone.

2. Configure interface ge-0/0/2 as a trunk port that includes only the voice VLAN:

[edit interfaces]
user@switch# set ge-0/0/2 unit 0 family ethernet-switching port-mode trunk
user@switch# set ge-0/0/2 unit 0 family ethernet-switching vlan member voice-vlan

3. Configure the native VLAN ID for the data VLAN on the trunk port:

[edit interfaces]
user@switch# set ge-0/0/2 unit 0 family ethernet-switching native-vlan-id data-vlan

Results
Display the results of the configuration:

[edit]
user@switch> show configuration
interfaces {
ge-0/0/2 {
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members voice-vlan;
 513

}
native-vlan-id data-vlan;
}
}
}
}
vlans {
data-vlan {
vlan-id 77;
}
voice-vlan {
vlan-id 99;
}
}

Verification

IN THIS SECTION

Verifying the VLAN Association With the Interface | 513

To confirm that the configuration is working properly, perform the following task:

Verifying the VLAN Association With the Interface

Purpose
Display the interface state and VLAN membership.

Action

user@switch> show ethernet-switching interfaces

Ethernet-switching table: 0 entries, 0 learned

user@switch> show ethernet-switching interfaces

Interface State VLAN members Blocking
ge-0/0/0.0 down default unblocked
ge-0/0/1.0 down employee-vlan unblocked
ge-0/0/5.0 down employee-vlan unblocked
ge-0/0/3.0 down employee-vlan unblocked
 514

ge-0/0/8.0 down employee-vlan unblocked

ge-0/0/10.0 down default unblocked
ge-0/0/11.0 down employee-vlan unblocked
ge-0/0/23.0 down default unblocked
ge-0/0/2.0 up voice-vlan unblocked
data-vlan unblocked

Meaning
The field VLAN members shows that the ge-0/0/2.0 interface supports both the data VLAN, data-vlan,
and the voice VLAN, voice-vlan. The State field shows that the interface is up.

SEE ALSO

Understanding LLDP and LLDP-MED on EX Series Switches | 623

Example: Configuring VoIP on an EX Series Switch Without Including 802.1X

Authentication

IN THIS SECTION

Requirements | 515

Overview | 515

Configuration | 516

Verification | 519

You can configure voice over IP (VoIP) on an EX Series switch to support IP telephones.

To configure VoIP on an EX Series switch to support an IP phone that does not support 802.1X
authentication, you must either add the MAC address of the phone to the static MAC bypass list or enable
MAC RADIUS authentication on the switch.

This example describes how to configure VoIP on an EX Series switch without 802.1X authentication using
static MAC bypass of authentication:
 515

Requirements

This example uses the following hardware and software components:

• Junos OS Release 9.1 or later for EX Series switches

• An IP telephone

Before you configure VoIP, be sure you have:

• Installed your EX Series switch. See the installation information for your switch.

• Performed the initial switch configuration. See Connecting and Configuring an EX Series Switch (CLI
Procedure).

• Performed basic bridging and VLAN configuration on the switch. See Example: Setting Up Basic Bridging
and a VLAN for an EX Series Switch.

• Configured the RADIUS server for 802.1X authentication and set up the access profile. See “Example:
Connecting a RADIUS Server for 802.1X to an EX Series Switch” on page 365.

• (Optional) Configured interface ge-0/0/2 for Power over Ethernet (PoE). The PoE configuration is not
necessary if the VoIP supplicant is using a power adapter. For information about configuring PoE, see
Configuring PoE on EX Series Switches (CLI Procedure).

NOTE: If the IP address isn't configured on the Avaya IP phone, the phone exchanges LLDP-MED
information to get the VLAN ID for the voice VLAN. You must configure the voip statement on
the interface to designate the interface as a VoIP interface and allow the switch to forward the
VLAN name and VLAN ID for the voice VLAN to the IP telephone. The IP telephone then uses
the voice VLAN (that is, it references the voice VLAN’s ID) to send a DHCP discover request
and exchange information with the DHCP server (voice gateway).

Overview

Instead of using a regular telephone, you connect an IP telephone directly to the switch. An IP phone has
all the hardware and software needed to handle VoIP. You also can power an IP telephone by connecting
it to one of the Power over Ethernet (PoE) interfaces on the switch.

In this example, the access interface ge-0/0/2 on the EX4200 switch is connected to a non-802.1X IP
phone.

To configure VoIP on an EX Series switch to support an IP phone that does not support 802.1X
authentication, add the MAC address of the phone as a static entry in the authenticator database and set
the supplicant mode to multiple.
 516

Configuration

To configure VoIP without 802.1X authentication:

CLI Quick Configuration

To quickly configure VoIP, copy the following commands and paste them into the switch terminal window:

[edit]

set vlans data-vlan vlan-id 77

set vlans voice-vlan vlan-id 99

set vlans data-vlan interface ge-0/0/2.0

set interfaces ge-0/0/2 unit 0 family ethernet-switching vlan members data-vlan

set interfaces ge-0/0/2 unit 0 family ethernet-switching port-mode access

set ethernet-switching-options voip interface ge-0/0/2.0 vlan voice-vlan

set ethernet-switching-options voip interface ge-0/0/2.0 forwarding-class assured-forwarding

set protocols lldp-med interface ge-0/0/2.0

set protocols dot1x authenticator authentication-profile-name auth-profile

set protocols dot1x authenticator static 00:04:f2:11:aa:a7

set protocols dot1x authenticator interface ge-0/0/2.0 supplicant multiple

Step-by-Step Procedure
To configure VoIP without 802.1X:

1. Configure the VLANs for voice and data:

[edit vlans]
user@switch# set data-vlan vlan-id 77
user@switch# set voice-vlan vlan-id 99

2. Associate the VLAN data-vlan with the interface:

[edit vlans]
user@switch# set data-vlan interface ge-0/0/2.0

3. Configure the interface as an access interface, configure support for Ethernet switching, and add the
data-vlan VLAN:
 517

[edit interfaces]
user@switch# set ge-0/0/2 unit 0 family ethernet-switching vlan members data-vlan
user@switch# set ge-0/0/2 unit 0 family ethernet-switching port-mode access

4. Configure VoIP on the interface and specify the assured-forwarding forwarding class to provide the
most dependable class of service:

[edit ethernet-switching-options]
user@switch# set voip interface ge-0/0/2.0 vlan voice-vlan
user@switch# set voip interface ge-0/0/2.0 forwarding-class assured-forwarding

5. Configure LLDP-MED protocol support:

[edit protocols]
user@switch# set lldp-med interface ge-0/0/2.0

6. Set the authentication profile (see “Configuring 802.1X Interface Settings (CLI Procedure)” on page 355
and “Configuring 802.1X RADIUS Accounting (CLI Procedure)” on page 403):

[edit protocols]
set dot1x authenticator authentication-profile-name auth-profile

7. Add the MAC address of the phone to the static MAC bypass list:

[edit protocols]
set dot1x authenticator static 00:04:f2:11:aa:a7

8. Set the supplicant mode to multiple:

[edit protocols]
set dot1x authenticator interface ge-0/0/2.0 supplicant multiple

Results
Display the results of the configuration:

[edit]
user@switch# show configuration
interfaces {
ge-0/0/2 {
unit 0 {
family ethernet-switching {
port-mode access;
vlan {
 518

members data-vlan;
}
}
}
}
}
protocols {
lldp-med {
interface ge-0/0/2.0;
}
dot1x {
authenticator {
authentication-profile-name auth-profile;
static {
00:04:f2:11:aa:a7;
}
}
interface {
ge-0/0/2.0 {
supplicant multiple;
}
}
}
}
vlans {
data-vlan {
vlan-id 77;
interface {
ge-0/0/2.0;
}
}
voice-vlan {
vlan-id 99;
}
}
ethernet-switching options {
voip {
interface ge-0/0/2.0 {
vlan voice-vlan;
forwarding-class assured-forwarding;
}
}
}
 519

Verification

IN THIS SECTION

Verifying LLDP-MED Configuration | 519

Verifying Authentication for the Desktop PC | 520

Verifying the VLAN Association with the Interface | 521

To confirm that the configuration is working properly, perform these tasks:

Verifying LLDP-MED Configuration

Purpose
Verify that LLDP-MED is enabled on the interface.

Action

user@switch> show lldp detail

LLDP : Enabled
Advertisement interval : 30 Second(s)
Transmit delay : 2 Second(s)
Hold timer : 2 Second(s)
Config Trap Interval : 300 Second(s)
Connection Hold timer : 60 Second(s)

LLDP MED : Enabled

MED fast start count : 3 Packet(s)

Interface LLDP LLDP-MED Neighbor count

all Enabled - 0
ge-0/0/2.0 - Enabled 0

Interface VLAN-id VLAN-name

ge-0/0/0.0 0 default
ge-0/0/1.0 0 employee-vlan
ge-0/0/2.0 0 data-vlan
ge-0/0/2.0 99 voice-vlan
ge-0/0/3.0 0 employee-vlan
ge-0/0/8.0 0 employee-vlan
 520

ge-0/0/10.0 0 default
ge-0/0/11.0 20 employee-vlan
ge-0/0/23.0 0 default

LLDP basic TLVs supported:

Chassis identifier, Port identifier, Port description, System name, System
description, System capabilities, Management address.

LLDP 802 TLVs supported:

Power via MDI, Link aggregation, Maximum frame size, Port VLAN tag, Port
VLAN name.

LLDP MED TLVs supported:

LLDP MED capabilities, Network policy, Endpoint location, Extended power
Via MDI.

Meaning
The show lldp detail output shows that both LLDP and LLDP-MED are configured on the ge-0/0/2.0
interface. The end of the output shows the list of supported LLDP basic TLVs, 802.3 TLVs, and LLDP-MED
TLVs that are supported.

Verifying Authentication for the Desktop PC

Purpose
Display the 802.1X configuration for the desktop PC connected to the VoIP interface through the IP phone.

Action

user@switch> show dot1x interface ge/0/0/2.0 detail

ge-0/0/2.0
Role: Authenticator
Administrative state: Auto
Supplicant mode: Multiple
Number of retries: 3
Quiet period: 60 seconds
Transmit period: 30 seconds
Mac Radius: Disabled
Mac Radius Restrict: Disabled
Reauthentication: Enabled
Configured Reauthentication interval: 3600 seconds
Supplicant timeout: 30 seconds
 521

Server timeout: 30 seconds

Maximum EAPOL requests: 2
Guest VLAN member: <not configured>
Number of connected supplicants: 1
Supplicant: user101, 00:04:0f:fd:ac:fe
Operational state: Authenticated
Authentication method: Radius
Authenticated VLAN: vo11
Dynamic Filter: match source-dot1q-tag 10 action deny
Session Reauth interval: 60 seconds
Reauthentication due in 50 seconds

Meaning
The field Role shows that the ge-0/0/2.0 interface is in the authenticator state. The Supplicant field shows
that the interface is configured in multiple supplicant mode, permitting multiple supplicants to be
authenticated on this interface. The MAC addresses of the supplicants currently connected are displayed
at the bottom of the output.

Verifying the VLAN Association with the Interface

Purpose
Display the interface state and VLAN membership.

Action

user@switch> show ethernet-switching interfaces

Ethernet-switching table: 0 entries, 0 learned

user@switch> show ethernet-switching interfaces

Interface State VLAN members Blocking
ge-0/0/0.0 down default unblocked
ge-0/0/1.0 down employee-vlan unblocked
ge-0/0/5.0 down employee-vlan unblocked
ge-0/0/3.0 down employee-vlan unblocked
ge-0/0/8.0 down employee-vlan unblocked
ge-0/0/10.0 down default unblocked
ge-0/0/11.0 down employee-vlan unblocked
ge-0/0/23.0 down default unblocked
ge-0/0/2.0 up voice-vlan unblocked
data-vlan unblocked

Meaning
 522

The field VLAN members shows that the ge-0/0/2.0 interface supports both the data-vlan VLAN and
voice-vlan VLAN. The State field shows that the interface is up.

SEE ALSO

Understanding LLDP and LLDP-MED on EX Series Switches | 623

Example: Setting Up VoIP with 802.1X and LLDP-MED on an EX Series

Switch with ELS Support

IN THIS SECTION

Requirements | 523

Overview and Topology | 524

Configuration | 526

Verification | 529

NOTE: This example uses Junos OS for EX Series switches with support for the Enhanced Layer
2 Software (ELS) configuration style. If your switch runs software that does not support ELS, see
“Example: Setting Up VoIP with 802.1X and LLDP-MED on an EX Series Switch” on page 492.
For ELS details, see Using the Enhanced Layer 2 Software CLI.

You can configure VoIP on an EX Series switch to support IP telephones. The Link Layer Discovery
Protocol–Media Endpoint Discovery (LLDP-MED) protocol forwards VoIP parameters from the switch to
the phone. You also configure 802.1X authentication to allow the telephone access to the LAN.
Authentication is done through a backend RADIUS server.

This example describes how to configure VoIP on an EX Series switch to support an Avaya IP phone, as
well as how to configure the LLDP-MED protocol and 802.1X authentication:
 523

Requirements

This example uses the following software and hardware components:

NOTE: This example also applies to QFX5100 switches.

• Junos OS Release 13.2X50 or later for EX Series switches

• One EX Series switch with support for ELS acting as an authenticator port access entity (PAE). The
interfaces on the authenticator PAE form a control gate that blocks all traffic to and from supplicants
until they are authenticated.

• An Avaya IP telephone that supports LLDP-MED and 802.1X

Before you configure VoIP, be sure you have:

• Installed your EX Series switch. See the installation information for your switch.

• Performed the initial switch configuration. See Connecting and Configuring an EX Series Switch (CLI
Procedure).

• Performed basic bridging and VLAN configuration on the switch. See Example: Setting Up Basic Bridging
and a VLAN for an EX Series Switch with ELS Support or Example: Setting Up Basic Bridging and a VLAN on
Switches.

• Configured the RADIUS server for 802.1X authentication and set up the access profile. See “Example:
Connecting a RADIUS Server for 802.1X to an EX Series Switch” on page 365.

• (Optional) Configured the interface ge-0/0/2 for Power over Ethernet (PoE). The PoE configuration is
not necessary if the VoIP supplicant uses a power adapter. For information about configuring PoE, see
Configuring PoE on EX Series Switches (CLI Procedure).

NOTE: If the IP address is not configured on the Avaya IP phone, the phone exchanges LLDP-MED
information to get the VLAN ID for the voice VLAN. You must configure the voip statement on
the interface to designate the interface as a VoIP interface and allow the switch to forward the
VLAN name and VLAN ID for the voice VLAN to the IP telephone. The IP telephone then uses
the voice VLAN (that is, it references the voice VLAN’s ID) to send a DHCP discover request
and exchange information with the DHCP server (voice gateway).
 524

Overview and Topology

Instead of using a regular telephone, you connect an IP telephone directly to the switch. An IP phone has
all the hardware and software needed to handle VoIP. You also can power an IP telephone by connecting
it to one of the Power over Ethernet (PoE) interfaces on the switch.

EX Series switches can accommodate an IP telephone and end host connected to a single switch port. In
such a scenario, voice and data traffic must be separated into different broadcast domains, or VLANs. One
method for accomplishing this is by configuring a voice VLAN, which enables access ports to accept
untagged data traffic as well as tagged voice traffic from IP phones, and associate each type of traffic with
separate and distinct VLANs. Voice traffic (tagged) can then be treated differently, generally with a higher
priority than data traffic (untagged).

NOTE: If a MAC addresses has been learned on both the data and voice VLANs, it remains active
unless it ages out of both VLANs, or both VLANs are deleted.

In this example, the access interface ge-0/0/2 on the EX Series switch is connected to an Avaya IP telephone.
Avaya phones have a built-in bridge that enables you to connect a desktop PC to the phone, so the desktop
and phone in a single office require only one interface on the switch. The EX Series switch is connected
to a RADIUS server on the ge-0/0/10 interface (see Figure 24 on page 525).

NOTE: This figure also applies to QFX5100 switches.

 525

Figure 24: VoIP Topology

In this example, you configure VoIP parameters and specify the forwarding class assured-forward for voice
traffic to provide the highest quality of service.

Table 35 on page 525 describes the components used in this VoIP configuration example.

Table 35: Components of the VoIP Configuration Topology

Property Settings

Switch hardware EX Series switch with support for ELS.

 526

Table 35: Components of the VoIP Configuration Topology (continued)

Property Settings

VLAN names and IDs data-vlan, 77

voice-vlan, 99

Connection to Avaya phone—with integrated hub, to ge-0/0/2

connect phone and desktop PC to a single interface (requires
PoE)

One RADIUS server Provides backend database connected to the switch

through interface ge-0/0/10.

Besides configuring a VoIP for interface ge-0/0/2, you configure:

• 802.1X authentication. Authentication is set to multiple supplicant mode to support more than one
supplicant's access to the LAN through interface ge-0/0/2.

• LLDP-MED protocol information. The switch uses LLDP-MED to forward VoIP parameters to the phone.
Using LLDP-MED ensures that voice traffic gets tagged and prioritized with the correct values at the
source itself. For example, 802.1p class of service and 802.1Q tag information can be sent to the IP
telephone.

NOTE: A PoE configuration is not necessary if an IP telephone uses a power adapter.

Configuration

CLI Quick Configuration

To quickly configure VoIP, LLDP-MED, and 802.1X, copy the following commands and paste them into
the switch terminal window:

[edit]

set vlans data-vlan vlan-id 77

set vlans voice-vlan vlan-id 99

set vlans data-vlan switch-options interface ge-0/0/2.0

set interfaces ge-0/0/2 unit 0 family ethernet-switching interface-mode access

set interfaces ge-0/0/2 unit 0 family ethernet-switching vlan members data-vlan

 527

set switch-options voip interface ge-0/0/2.0 vlan voice-vlan

set switch-options voip interface ge-0/0/2.0 forwarding-class assured-forwarding

set protocols lldp-med interface ge-0/0/2

set protocols dot1x authenticator interface ge-0/0/2.0 supplicant multiple

Step-by-Step Procedure
To configure VoIP with LLDP-MED and 802.1X:

1. Configure the VLANs for voice and data:

[edit vlans]
user@switch# set data-vlan vlan-id 77
user@switch# set voice-vlan vlan-id 99

2. Associate the VLAN data-vlan with the interface:

[edit vlans]
user@switch# set data-vlan switch-options interface ge-0/0/2.0

3. Configure the interface as an access interface, configure support for Ethernet switching, and add the
interface as a member of the data-vlan VLAN:

[edit interfaces]
user@switch# set ge-0/0/2 unit 0 family ethernet-switching interface-mode access
user@switch# set ge-0/0/2 unit 0 family ethernet-switching vlan members data-vlan

4. Configure VoIP on the interface and specify the assured-forwarding forwarding class to provide the
most dependable class of service:

[edit switch—options]
user@switch# set voip interface ge-0/0/2.0 vlan voice-vlan
user@switch# set voip interface ge-0/0/2.0 forwarding-class assured-forwarding

5. Configure LLDP-MED protocol support:

[edit protocols]
user@switch# set lldp-med interface ge-0/0/2

6. To authenticate an IP phone and a PC connected to the IP phone on the interface, configure 802.1X
authentication support and specify multiple supplicant mode:
 528

NOTE: If you do not want to authenticate any device, skip the 802.1X configuration on this
interface.

[edit protocols]
user@switch# set dot1x authenticator interface ge-0/0/2.0 supplicant multiple

Results
Display the results of the configuration:

[edit]
user@switch# show configuration
interfaces {
ge-0/0/2 {
unit 0 {
family ethernet-switching {
interface-mode access;
vlan {
members data-vlan;
}
}
}
}
}
protocols {
lldp-med {
interface ge-0/0/2;
}
dot1x {
authenticator {
interface {
ge-0/0/2.0 {
supplicant multiple;
}
}
}
}
}
vlans {
data-vlan {
vlan-id 77;
 529

switch-options {
interface ge-0/0/2.0;
}
}
voice-vlan {
vlan-id 99;
}
}
switch-options {
voip {
interface ge-0/0/2.0 {
vlan voice-vlan;
forwarding-class assured-forwarding;
}
}
}

Verification

IN THIS SECTION

Verifying LLDP-MED Configuration | 529

Verifying 802.1X Authentication for IP Phone and Desktop PC | 531

Verifying the VLAN Association with the Interface | 531

To confirm that the configuration is working properly, perform these tasks:

Verifying LLDP-MED Configuration

Purpose
Verify that LLDP-MED is enabled on the interface.

Action

user@switch> show lldp detail

LLDP : Enabled
Advertisement interval : 30 seconds
Transmit delay : 2 seconds
 530

Hold timer : 120 seconds

Notification interval : 0 Second(s)
Config Trap Interval : 0 seconds
Connection Hold timer : 300 seconds

LLDP MED : Enabled

MED fast start count : 3 Packets

Port ID TLV subtype : locally-assigned

Interface Parent Interface LLDP LLDP-MED Power Negotiation

Neighbor count
all - Enabled Enabled Enabled
0
ge-0/0/2 - - Enabled -
0

Interface Parent Interface Vlan-id Vlan-name

ge-0/0/0 - 1 vlan-1
ge-0/0/1 - 1 vlan-1
ge-0/0/2 - 77 vlan-77
ge-0/0/2 - 99 vlan-99
ge-0/0/3 - 1 vlan-1
ge-0/0/4 - 1 vlan-1
ge-0/0/5 - 1 vlan-1
ge-0/0/6 - 1 vlan-1
ge-0/0/7 - 1 vlan-1
ge-0/0/8 - 1 vlan-1
ge-0/0/9 - 1 vlan-1
ge-0/0/10 - 1 vlan-1

Basic Management TLVs supported:

End Of LLDPDU, Chassis ID, Port ID, Time To Live, Port Description, System Name,
System Description, System Capabilities, Management Address

Organizationally Specific TLVs supported:

MAC/PHY configuration/status, Power via MDI, Link aggregation, Maximum Frame Size,

Port VLAN tag, Port VLAN name.

Meaning
The show lldp detail output shows that both LLDP and LLDP-MED are configured on the ge-0/0/2
interface. The end of the output shows the list of supported LLDP basic management TLVs and
organizationally specific TLVs that are supported.
 531

Verifying 802.1X Authentication for IP Phone and Desktop PC

Purpose
Display the 802.1X configuration to confirm that the VoIP interface has access to the LAN.

Action

user@switch> show dot1x interface ge/0/0/2.0 detail

ge-0/0/2.0
Role: Authenticator
Administrative state: Auto
Supplicant mode: Multiple
Number of retries: 3
Quiet period: 60 seconds
Transmit period: 30 seconds
Mac Radius: Disabled
Mac Radius Restrict: Disabled
Reauthentication: Enabled
Configured Reauthentication interval: 3600 seconds
Supplicant timeout: 30 seconds
Server timeout: 30 seconds
Maximum EAPOL requests: 2
Guest VLAN member: <not configured>
Number of connected supplicants: 1
Supplicant: user101, 00:04:0f:fd:ac:fe
Operational state: Authenticated
Authentication method: Radius
Authenticated VLAN: vo11
Dynamic Filter: match source-dot1q-tag 10 action deny
Session Reauth interval: 60 seconds
Reauthentication due in 50 seconds

Meaning
The field Role shows that the ge-0/0/2.0 interface is in the authenticator state. The Supplicant mode field
shows that the interface is configured in multiple supplicant mode, permitting multiple supplicants to be
authenticated on this interface. The MAC addresses of the supplicants currently connected are displayed
at the bottom of the output.

Verifying the VLAN Association with the Interface

Purpose
Display the interface’s VLAN membership.
 532

Action

user@switch> show ethernet-switching interface ge-0/0/2.0

Routing Instance Name : default-switch

Logical Interface flags (DL - disable learning, AD - packet action drop,
LH - MAC limit hit, DN - interface down )
Logical Vlan TAG MAC STP Logical Tagging
interface members limit state interface flags
ge-0/0/2.0 65535 untagged
voice-vlan 99
65535 Discarding
data-vlan 77
65535 Discarding

Meaning
The field VLAN members shows that the ge-0/0/2.0 interface supports both the data-vlan VLAN and
voice-vlan VLAN.

SEE ALSO

Example: Connecting a RADIUS Server for 802.1X to an EX Series Switch | 365

Example: Setting Up 802.1X for Single-Supplicant or Multiple-Supplicant Configurations on an EX
Series Switch | 405
Defining CoS Forwarding Classes (CLI Procedure)
Defining CoS Forwarding Classes (J-Web Procedure)
Configuring LLDP-MED (CLI Procedure) | 627

RELATED DOCUMENTATION

RADIUS Server Configuration for Authentication | 343

802.1X Authentication | 351
7 CHAPTER

Configuring IEEE 802.1x Port-Based

Network Access Control

IEEE 802.1x Port-Based Network Access Control Overview | 534

Understanding the Administrative State of the Authenticator Port | 535

Understanding the Administrative Mode of the Authenticator Port | 535

Configuring the Authenticator | 536

Viewing the dot1x Configuration | 537

 534

IEEE 802.1x Port-Based Network Access Control

Overview

MX Series routers support the IEEE 802.1x Port-Based Network Access Control (dot1x) protocol on
Ethernet interfaces for validation of client and user credentials to prevent unauthorized access to a specified
router port. Before authentication is complete, only 802.1x control packets are allowed and forwarded to
the router control plane for processing. All other packets are dropped.

Authentication methods used must be 802.1x compliant. Authentication using RADIUS and Microsoft
Active Directory servers is supported. The following user/client authentication methods are allowed:

• EAP-MD5 (RFC 3748)

• EAP-TTLS requires a server certificate (RFC 2716)

• EAP-TLS requires a client and server certificate

• PEAP requires only a server certificate

You can use both client and server certificates in all types of authentication except EAP-MD5.

NOTE: On the MX Series router, 802.1x can be enabled on bridged ports only and not on routed
ports.

Dynamic changes to a user session are supported to allow the router administrator to terminate an already
authenticated session by using the “RADIUS disconnect” message defined in RFC 3576.

RELATED DOCUMENTATION

Understanding the Administrative State of the Authenticator Port | 535

Understanding the Administrative Mode of the Authenticator Port | 535
Configuring the Authenticator | 536
Viewing the dot1x Configuration | 537
Ethernet Interfaces User Guide for Routing Devices
 535

Understanding the Administrative State of the

Authenticator Port

The administrative state of an authenticator port can take any of the following three states:

• Force authorized—Allows network access to all users of the port without requiring them to be
authenticated. This is equivalent to not having any authentication enabled on the port.

• Force unauthorized—Denies network access to all users of the port. This is equivalent to disabling the
port.

• Automatic—This is the default mode where the authentication server response determines if the port
is opened for traffic or not. Only the successfully authenticated clients are allowed access, all others are
denied.

In Junos OS, the default mode is “automatic.” The “force authorized” and “force unauthorized” admin
modes are not supported. You can achieve the functionality of “force authorized” mode by disabling dot1x
on the required port. You can achieve the functionality of “force unauthorized” mode by disabling the port
itself.

RELATED DOCUMENTATION

IEEE 802.1x Port-Based Network Access Control Overview | 534

Understanding the Administrative Mode of the Authenticator Port | 535
Configuring the Authenticator | 536
Viewing the dot1x Configuration | 537
Ethernet Interfaces User Guide for Routing Devices

Understanding the Administrative Mode of the

Authenticator Port

Junos OS supports the supplicant mode “single” and not the “single secure” nor “multiple” modes. The
“Single” mode option authenticates only the first client that connects to a port. All other clients that connect
later (802.1x compliant or noncompliant) are allowed free access on that port without any further
authentication. If the first authenticated client logs out, all other users are locked out until a client
authenticates again.
 536

RELATED DOCUMENTATION

IEEE 802.1x Port-Based Network Access Control Overview | 534

Understanding the Administrative State of the Authenticator Port | 535
Configuring the Authenticator | 536
Viewing the dot1x Configuration | 537
Ethernet Interfaces User Guide for Routing Devices

Configuring the Authenticator

To configure the IEEE 802.1x Port-Based Network Access Control protocol on Ethernet interfaces you
must configure the authenticator statement at the [edit protocols dot1x] hierarchy level. Use the
authentication-profile-name access-profile-name statement to specify the authenticating RADIUS server,
and use the interface statement to specify and configure the Gigabit Ethernet or Fast Ethernet interface
on the router specifically for IEEE 802.1x protocol use; both at the [edit protocols dot1x authenticator]
hierarchy level.

[edit protocols dot1x]

authenticator {
authentication-profile-name access-profile-name;
interface (xe-fpc/pic/port | ge-fpc/pic/port | fe-fpc/pic/port) {
maximum-requests seconds;
quiet-period seconds;
reauthentication (disable | interval seconds);
retries integer;
server-timeout seconds;
supplicant (single);
supplicant-timeout seconds;
transmit-period seconds;
}
}

RELATED DOCUMENTATION

IEEE 802.1x Port-Based Network Access Control Overview | 534

Understanding the Administrative State of the Authenticator Port | 535
Understanding the Administrative Mode of the Authenticator Port | 535
 537

Viewing the dot1x Configuration | 537

Ethernet Interfaces User Guide for Routing Devices

Viewing the dot1x Configuration

Purpose
To review and verify the dot1x configuration.

Action
To view all dot1x configurations, use the show dot1x interface operational mode command. To view a
dot1x configuration for a specific interface, use the show dot1x interface (xe-fpc/pic/port | ge-fpc/pic/port
| fe-fpc/pic/port) detail operational mode command. See the Network Interfaces Command Reference for
more information about this command.

RELATED DOCUMENTATION

IEEE 802.1x Port-Based Network Access Control Overview | 534

Understanding the Administrative State of the Authenticator Port | 535
Understanding the Administrative Mode of the Authenticator Port | 535
Configuring the Authenticator | 536
Ethernet Interfaces User Guide for Routing Devices
8 CHAPTER

Configuring IEEE 802.1x Port-Based

Network Access Control in Enhanced
LAN Mode

802.1X for MX Series Routers in Enhanced LAN Mode Overview | 540

Understanding 802.1X and LLDP and LLDP-MED on MX Series Routers in Enhanced

LAN Mode | 544

Understanding 802.1X and RADIUS Accounting on MX Series Routers in Enhanced

LAN Mode | 547

Understanding 802.1X and VoIP on MX Series Routers in Enhanced LAN Mode | 548

Understanding Guest VLANs for 802.1X on MX Series Routers in Enhanced LAN

Mode | 551

Understanding Dynamic VLANs for 802.1X on MX Series Routers in Enhanced LAN

Mode | 551

Understanding Server Fail Fallback and Authentication on MX Series Routers in

Enhanced LAN Mode | 552

Configuring 802.1X RADIUS Accounting on MX Series Routers in Enhanced LAN

Mode | 553
Configuring 802.1X Interface Settings on MX Series Routers in Enhanced LAN
Mode | 556

Configuring LLDP-MED on MX Series Routers in Enhanced LAN Mode | 558

Configuring LLDP on MX Series Routers in Enhanced LAN Mode | 560

Configuring Server Fail Fallback on MX Series Routers in Enhanced LAN Mode | 564

Understanding Captive Portal Authentication on the MX Series Routers | 566

Understanding Authentication Session Timeout on MX Series Routers | 567

Authentication Process Flow for MX Series Routers in Enhanced LAN Mode | 568

Specifying RADIUS Server Connections on an MX Series Router in Enhanced LAN

Mode | 570

Configuring Captive Portal Authentication on MX Series Routers in Enhanced LAN

Mode | 571

Designing a Captive Portal Authentication Login Page on an MX Series Router | 574

Configuring Static MAC Bypass of Authentication on MX Series Routers in Enhanced

LAN Mode | 577

Controlling Authentication Session Timeouts on an MX Series Router in Enhanced

LAN Mode | 578

Configuring MAC RADIUS Authentication on MX Series Routers in Enhanced LAN

Mode | 580

Example: Configuring MAC RADIUS Authentication on an MX Series Router | 582

Example: Setting Up Captive Portal Authentication on an MX Series Router | 587

Example: Connecting a RADIUS Server for 802.1X to an MX Series Router | 594

Example: Setting Up 802.1X in Conference Rooms to Provide Internet Access to

Corporate Visitors on an MX Series Router | 598

Example: Configuring Static MAC Bypass of Authentication on an MX Series

Router | 602

Example: Applying Firewall Filters to Multiple Supplicants on Interfaces Enabled for

802.1X or MAC RADIUS Authentication on MX Series Routers | 607
 540

802.1X for MX Series Routers in Enhanced LAN Mode

Overview
 541

Starting with Junos os Release 14.2, IEEE 802.1X provides network edge security, protecting Ethernet
LANs from unauthorized user access. Support is implemented for controlling access to your network
through an MX Series router by using several different authentication methods, such as 802.1X, MAC
RADIUS, or a captive portal.

This functionality is supported on the following MPCs on MX240, MX480, and MX960 routers in enhanced
LAN mode:

• MPC4E with two 100-Gigabit Ethernet ports and eight 10-Gigabit Ethernet ports

• MPC4E with thirty-two 10-Gigabit Ethernet ports

• MPC3E that contains a 2-port 40-Gigabit Ethernet MIC with QSFP+

• MPC1E with forty 1-Gigabit Ethernet ports or twenty 1-Gigabit Ethernet ports

You must reboot the router when you configure or delete the enhanced LAN mode on the router.
Configuring the network-services lan option implies that the system is running in the enhanced IP mode.
When you configure a device to function in MX-LAN mode, only the supported configuration statements
and operational show commands that are available for enabling or viewing in this mode are displayed in
the CLI interface. If your system contains parameters that are not supported in MX-LAN mode in a
configuration file, you cannot commit those unsupported attributes. You must remove the settings that
are not supported and then commit the configuration. After the successful CLI commit, a system reboot
is required for the attributes to be come effective. Similarly, if you remove the network-services lan
statement, the system does not run in MX-LAN mode. Therefore, all of the settings that are supported
outside of the MX-LAN mode are displayed and are available for definition in the CLI interface. If your
configuration file contains settings that are supported only in MX-LAN mode, you must remove those
attributes before you commit the configuration. After the successful CLI commit, a system reboot will be
required for the CLI settings to take effect. The Layer 2 Next-Generation CLI configuration settings are
supported in MX-LAN mode. As a result, the typical MX Series-format of CLI configurations might differ
in MX-LAN mode.

This functionality is supported on an MX Series Virtual Chassis combination that functions in enhanced
LAN mode (by entering the network-services lan statement at the [edit chassis] hierarchy level). Port-based
network access control is supported on MX240, MX480, and MX960 routers with MPCs in both the
MX-LAN mode and the non-MX-LAN mode (with other supported network services modes on MPCs on
these routers). To configure the IEEE 802.1x port-based network access control (PNAC) protocol on
Ethernet interfaces, you must configure the authenticator statement at the [edit protocols
authentication-access- control] hierarchy level. You can also configure captive portal authentication on
a router so that users connected to the switch are authenticated before being allowed to access the
network. You can also configure Junos Pulse Access Control Service as the access policy to authenticate
and authorize users connected to the switch for admission to the network and for access to protected
network resources by using the uac-policy statement.
 542

How 802.1X Authentication Works

802.1X authentication works by using an Authenticator Port Access Entity (the switch) to block all traffic
to and from a supplicant (end device) at the port until the supplicant's credentials are presented and
matched on the Authentication server (a RADIUS server). When authenticated, the switch stops blocking
traffic and opens the port to the supplicant.

The end device is authenticated in either single mode, single-secure mode, or multiple mode:

• single—Authenticates only the first end device. All other end devices that connect later to the port are
allowed full access without any further authentication. They effectively “piggyback” on the end devices’
authentication.

• single-secure—Allows only one end device to connect to the port. No other end device is allowed to
connect until the first logs out.

• multiple—Allows multiple end devices to connect to the port. Each end device will be authenticated
individually.

Network access can be further defined using VLANs and firewall filters, which both act as filters to separate
and match groups of end devices to the areas of the LAN they require. For example, you can configure
VLANs to handle different categories of authentication failures depending upon:

• Whether or not the end device is 802.1X-enabled.

• Whether or not MAC RADIUS authentication has been configured on the switch interfaces to which
the hosts are connected.

• Whether the RADIUS authentication server becomes unavailable or sends a RADIUS access-reject
message. See “Configuring RADIUS Server Fail Fallback (CLI Procedure)” on page 349.
 543

802.1X Features Overview

NOTE: The 802.1X features available on the MX Series routers depend upon which switch you
are using.

802.1X features on Juniper Networks MX Series routers are:

• Guest VLAN—Provides limited access to a LAN, typically just to the Internet, for nonresponsive end
devices that are not 802.1X-enabled when MAC RADIUS authentication has not been configured on
the switch interfaces to which the hosts are connected . Also, a guest VLAN can be used to provide
limited access to a LAN for guest users. Typically, the guest VLAN provides access just to the Internet
and to other guests’ end devices.

• Server-reject VLAN—Provides limited access to a LAN, typically just to the Internet, for responsive end
devices that are 802.1X-enabled but that have sent the wrong credentials.

• Server-fail VLAN—Provides limited access to a LAN, typically just to the Internet, for 802.1X end devices
during a RADIUS server timeout.

• Dynamic VLAN—Enables an end device, after authentication, to be a member of a VLAN dynamically.

• Private VLAN—Enables configuration of 802.1X authentication on interfaces that are members of private
VLANs (PVLANs).

• Dynamic changes to a user session—Allows the switch administrator to terminate an already authenticated
session. This feature is based on support of the RADIUS Disconnect Message defined in RFC 3576.

• RADIUS accounting—Sends accounting information to the RADIUS accounting server. Accounting

information is sent to the server whenever a subscriber logs in or logs out and whenever a subscriber
activates or deactivates a subscription.

Supported Features Related to 802.1X Authentication

802.1X does not replace other security technologies. 802.1X works together with port security features,
such as DHCP snooping, dynamic ARP inspection (DAI), and MAC limiting, to guard against spoofing.

Supported features related to authentication include:

• Static MAC bypass—Provides a bypass mechanism to authenticate devices that are not 802.1X-enabled
(such as printers). Static MAC bypass connects these devices to 802.1X-enabled ports, bypassing 802.1X
authentication.
 544

• MAC RADIUS authentication—Provides a means to enable or disable MAC authentication independently

of whether 802.1X authentication is enabled.

Release History Table

Release Description

14.2 Starting with Junos os Release 14.2, IEEE 802.1X provides network edge security, protecting
Ethernet LANs from unauthorized user access. Support is implemented for controlling access to
your network through an MX Series router by using several different authentication methods,
such as 802.1X, MAC RADIUS, or a captive portal.

Understanding 802.1X and LLDP and LLDP-MED on

MX Series Routers in Enhanced LAN Mode

Starting with Junos OS Release 14.2, Juniper Networks MX Series routers use Link Layer Discovery Protocol
(LLDP) and Link Layer Discovery Protocol–Media Endpoint Discovery (LLDP-MED) to learn and distribute
device information on network links. The information allows the router to quickly identify a variety of
devices, resulting in a LAN that interoperates smoothly and efficiently.

LLDP-capable devices transmit information in type, length, and value (TLV) messages to neighbor devices.
Device information can include information such as chassis and port identification and system name and
system capabilities. The TLVs leverage this information from parameters that have already been configured
in the Juniper Networks Junos operating system (Junos OS).

LLDP-MED goes one step further than LLDP, exchanging IP-telephony messages between the router and
the IP telephone.

LLDP and LLDP-MED also provide PoE power management capabilities. LLDP power negotiation allows
the router to manage PoE power by negotiating with LLDP-enabled powered devices to dynamically
allocate PoE power as needed. LLDP power priority allows an LLDP-enabled powered device to set the
PoE power priority on the router interface to which it connects.

The router also uses these protocols to ensure that voice traffic gets tagged and prioritized with the correct
values at the source itself. For example, 802.1p CoS and 802.1Q tag information can be sent to the IP
telephone.

EX Series routeres support the following basic TLVs:

 545

• Chassis Identifier—The MAC address associated with the local system.

NOTE: The Chassis ID TLV has a subtype for Network Address Family. LLDP frames are
validated only if this subtype has a value of 1 (IPv4) or 2 (IPv6). For any other value, the
transmitting device is detected by LLDP as a neighbor and displayed in the output of the "show
lldp neighbors" command, but is not assigned to the VLAN.

• Port Identifier—The port identification for the specified port in the local system.

• Port Description—Textual description of the interface or the logical unit. The description for the logical
unit is used, if available; otherwise, the Port Description TLV will contain the description configured on
the physical interface. For example, LAG member interfaces do not contain a logical unit, so only the
description configured on the physical interface can be used.

• System Name—The user-configured name of the local system. The system name can be a maximum of
256 characters.

• System Description—The system description containing information about the software and current
image running on the system. This information is not configurable, but taken from the software.

• System Capabilities—The primary function performed by the system. The capabilities that system
supports; for example, bridge or router. This information is not configurable, but based on the model of
the product.

• Management Address—The IPv4 or IPv6 management address of the local system.

EX Series routeres support the following 802.3 TLVs:

• Power via MDI—A TLV that advertises MDI power support, PSE power pair, and power class information.

• MAC/PHY Configuration Status—A TLV that advertises information about the physical interface, such
as autonegotiation status and support and MAU type. The information is not configurable, but based on
the physical interface structure.

NOTE: The MAC/PHY Configuration Status TLV has a subtype for the PMD Auto-Negotiation
Advertised Capability field. This field will contain a value of other or unknown if the LLDP
packet was transmitted from a 10-gigabit SFP+ port.

• Link Aggregation—A TLV that advertises if the port is aggregated and its aggregated port ID.

• Maximum Frame Size—A TLV that advertises the Maximum Transmission Unit (MTU) of the interface
sending LLDP frames.

• Port Vlan—A TLV that advertises the VLAN name configured on the interface.

EX Series routeres support the following LLDP-MED TLVs:

 546

• LLDP MED Capabilities—A TLV that advertises the primary function of the port. The capabilities values
range 0 through 15:

• 0— Capabilities

• 1— Network Policy

• 2— Location Identification

• 3— Extended Power via MDI-PSE

• 4— Inventory

• 5–15— Reserved

• LLDP-MED Device Class Values:

• 0— Class not defined.

• 1— Class 1 Device.

• 2— Class 2 Device.

• 3— Class 3 Device.

• 4— Network Connectivity Device

• 5–255— Reserved.

• Network Policy—A TLV that advertises the port VLAN configuration and associated Layer 2 and Layer
3 attributes. Attributes include the policy identifier, application types, such as voice or streaming video,
802.1Q VLAN tagging, and 802.1p priority bits and Diffserv code points.

• Endpoint Location— A TLV that advertises the physical location of the endpoint.

• Extended Power via MDI— A TLV that advertises the power type, power source, power priority, and
power value of the port. It is the responsibility of the PSE device (network connectivity device) to
advertise the power priority on a port.

Release History Table

Release Description

14.2 Starting with Junos OS Release 14.2, Juniper Networks MX Series routers use Link Layer Discovery
Protocol (LLDP) and Link Layer Discovery Protocol–Media Endpoint Discovery (LLDP-MED) to
learn and distribute device information on network links. The information allows the router to
quickly identify a variety of devices, resulting in a LAN that interoperates smoothly and efficiently.
 547

Understanding 802.1X and RADIUS Accounting on

MX Series Routers in Enhanced LAN Mode

Juniper Networks MX Series routers support IETF RFC 2866, RADIUS Accounting. Starting with Junos OS
Release 14.2, you can configure RADIUS accounting on an MX Series router which enables statistical data
about users logging onto or off a LAN to be collected and sent to a RADIUS accounting server. The statistical
data gathered can be used for general network monitoring, to analyze and track usage patterns, or to bill
a user based upon the amount of time or type of services accessed.

To configure RADIUS accounting, specify one or more RADIUS accounting servers to receive the statistical
data from the switch, and select the type of accounting data to be collected.

The RADIUS accounting server you specify can be the same server used for RADIUS authentication, or it
can be a separate RADIUS server. You can specify a list of RADIUS accounting servers. In the event that
the primary server (the first one configured) is unavailable, each RADIUS server in the list is tried in the
order in which they are configured in the Juniper Networks Junos operating system (Junos OS).

The RADIUS accounting process between a switch and a RADIUS server works like this:

1. A RADIUS accounting server listens for User Datagram Protocol (UDP) packets on a specific port. For
example, on FreeRADIUS, the default port is 1813.

2. The switch forwards an accounting-request packet containing an event record to the accounting server.
For example, a supplicant is authenticated through 802.1X authentication and connected to the LAN.
The event record associated with this supplicant contains an Acct-Status-Type attribute whose value
indicates the beginning of user service for this supplicant. When the supplicant's session ends, the
accounting request will contain an Acct-Status-Type attribute value indicating the end of user service.
The RADIUS accounting server records this as a stop-accounting record containing session information
and the length of the session.

3. The RADIUS accounting server logs these events as start-accounting or stop-accounting records. The
records are in a file. On FreeRADIUS, the file name is the server's address; for example, 122.69.1.250.

4. The accounting server sends an accounting-response packet back to the switch confirming it has received
the accounting request.

5. If the switch does not receive a response from the server, it continues to send accounting requests
until an accounting response is returned from the accounting server.

The statistics collected through this process can be displayed from the RADIUS server; to see those
statistics, the user accesses the log file configured to receive them.
 548

Release History Table

Release Description

14.2 Starting with Junos OS Release 14.2, you can configure RADIUS accounting on an MX Series router
which enables statistical data about users logging onto or off a LAN to be collected and sent to a
RADIUS accounting server. The statistical data gathered can be used for general network monitoring,
to analyze and track usage patterns, or to bill a user based upon the amount of time or type of
services accessed.

Understanding 802.1X and VoIP on MX Series Routers

in Enhanced LAN Mode

When you use Voice over IP (VoIP), you can connect IP telephones to the router and configure IEEE 802.1X
authentication for 802.1X-compatible IP telephones. Starting with Junos OS Release 14.2, 802.1X
authentication provides network edge security, protecting Ethernet LANs from unauthorized user access.

VoIP is a protocol used for the transmission of voice through packet-switched networks. VoIP transmits
voice calls using a network connection instead of an analog phone line.

When VoIP is used with 802.1X, the RADIUS server authenticates the phone, and Link Layer Discovery
Protocol–Media Endpoint Discovery (LLDP-MED) provides the class-of-service (CoS) parameters to the
phone.

You can configure 802.1X authentication to work with VoIP in multiple supplicant or single supplicant
mode. In multiple-supplicant mode, the 802.1X process allows multiple supplicants to connect to the
interface. Each supplicant will be authenticated individually. For an example of a VoIP multiple supplicant
topology, see Figure 21 on page 490.
 549

Figure 25: VoIP Multiple Supplicant Topology

If an 802.1X-compatible IP telephone does not have an 802.1X host but has another 802.1X-compatible
device connected to its data port, you can connect the phone to an interface in single-supplicant mode.
In single-supplicant mode, the 802.1X process authenticates only the first supplicant. All other supplicants
who connect later to the interface are allowed full access without any further authentication. They
effectively “piggyback” on the first supplicant’s authentication. For an example of a VoIP single supplicant
topology, see Figure 22 on page 491 .
 550

Figure 26: VoIP Single Supplicant Topology

If an IP telephone does not support 802.1X, you can configure VoIP to bypass 802.1X and LLDP-MED
and have the packets forwarded to a VoIP VLAN,

Release History Table

Release Description

14.2 Starting with Junos OS Release 14.2, 802.1X authentication provides network edge security,
protecting Ethernet LANs from unauthorized user access.
 551

Understanding Guest VLANs for 802.1X on MX Series

Routers in Enhanced LAN Mode

Starting with Junos OS Release 14.2, guest VLANs can be configured on switches that are using 802.1X
authentication to provide limited access—typically only to the Internet—for:

• Corporate guests

• End devices that are not 802.1X-enabled

• Nonresponsive end devices when MAC RADIUS authentication has not been configured on the switch
interfaces to which the hosts are connected

A guest VLAN is not used for supplicants sending incorrect credentials. Those supplicants are directed to
the server-reject VLAN instead.

For end devices that are not 802.1X-enabled, a guest VLAN can allow limited access to a server from
which the non-802.1X-enabled end device can download the supplicant software and attempt authentication
again.

A guest VLAN is not used when MAC RADIUS authentication has been configured on the switch interfaces
to which the hosts are connected. Some end devices, such as a printer, cannot be enabled for 802.1X. The
hosts for such devices should be connected to switch interfaces that are configured for MAC RADIUS
authentication.

Release History Table

Release Description

14.2 Starting with Junos OS Release 14.2, guest VLANs can be configured on switches that are
using 802.1X authentication to provide limited access—typically only to the Internet

Understanding Dynamic VLANs for 802.1X on MX

Series Routers in Enhanced LAN Mode

Starting with Junos OS Release 14.2, dynamic VLANs, in conjunction with the 802.1X authentication
process, provide secure access to the LAN for end devices belonging to different VLANs on a single port.

When this feature is configured on the RADIUS server, an end device or user authenticating on the RADIUS
server is assigned to the VLAN configured for it. The end device or user becomes a member of a VLAN
 552

dynamically after successful 802.1X authentication. For information on configuring dynamic VLANs on
your RADIUS server, see the documentation for your RADIUS server.

Successful authentication requires that the VLAN ID or VLAN name exist on the router and match the
VLAN ID or VLAN name sent by the RADIUS server during authentication. If neither exists, the end device
is unauthenticated. If a guest VLAN is established, the unauthenticated end device is automatically moved
to the guest VLAN.

Release History Table

Release Description

14.2 Starting with Junos OS Release 14.2, dynamic VLANs, in conjunction with the 802.1X
authentication process, provide secure access to the LAN for end devices belonging to different
VLANs on a single port.

Understanding Server Fail Fallback and Authentication

on MX Series Routers in Enhanced LAN Mode

Starting with Junos OS Release 14.2, server fail fallback allows you to specify how end devices connected
to the router are supported if the RADIUS authentication server becomes unavailable or sends a RADIUS
access-reject message.

Juniper Networks MX Series routers in enhanced LAN mode use authentication to implement access
control in an enterprise network. If 802.1X, MAC RADIUS, or captive portal authentication are configured
on the interface, end devices are evaluated at the initial connection by an authentication (RADIUS) server.
If the end device is configured on the authentication server, the device is granted access to the LAN and
the MX Series router opens the interface to permit access.

A RADIUS server timeout occurs if no RADIUS authentication servers are reachable when an end device
logs in and attempts to access the LAN. Server fail fallback allows you to specify one of four actions to be
taken toward end devices awaiting authentication when the server is timed out:

• Permit authentication, allowing traffic to flow from the end device through the interface as if the end
device were successfully authenticated by the RADIUS server.

• Deny authentication, preventing traffic from flowing from the end device through the interface. This is
the default.
 553

• Move the end device to a specified VLAN. (The VLAN must already exist on the router.)

• Sustain authenticated end devices that already have LAN access and deny unauthenticated end devices.
If the RADIUS servers time out during reauthentication, previously authenticated end devices are
reauthenticated and new users are denied LAN access.

Server fail fallback is triggered most often during reauthentication when the already configured and in-use
RADIUS server becomes inaccessible. However, server fail fallback can also be triggered by an end device’s
first attempt at authentication through the RADIUS server.

Server fail fallback allows you to specify that an end device be moved to a specified VLAN if the router
receives a RADIUS access-reject message. The configured VLAN name overrides any attributes sent by
the server.

Release History Table

Release Description

14.2 Starting with Junos OS Release 14.2, server fail fallback allows you to specify how end devices
connected to the router are supported if the RADIUS authentication server becomes unavailable
or sends a RADIUS access-reject message.

Configuring 802.1X RADIUS Accounting on MX Series

Routers in Enhanced LAN Mode

Starting with Junos OS Release 14.2, RADIUS accounting permits statistical data about users logging onto
or off a LAN to be collected and sent to a RADIUS accounting server.The statistical data gathered can be
used for general network monitoring, to analyze and track usage patterns, or to bill a user based upon the
amount of time or type of services accessed.

To configure basic RADIUS accounting using the CLI:

1. Specify the accounting servers to which the switch will forward accounting statistics:

[edit access ]
user@router# set profile profile1 radius accounting-serveraccounting-server [122.69.1.250
122.69.1.252]

2. Define the RADIUS accounting servers:

[edit access]
user@router# set radius-server 122.69.1.250 secret juniper
 554

user@router# set radius-server 122.69.1.252 secret juniper1

3. Enable accounting for an access profile:

[edit access]
user@router# set profile profile1 accounting

4. Configure the RADIUS servers to use while sending accounting messages and updates:

[edit access]
user@router# set profile profile1 accounting order radius

5. Configure the statistics to be collected on the router and forwarded to the accounting server:

[edit access ]
user@router# set profile profile1 accounting accounting-stop-on-access-deny
user@router# set profile profile1 accounting accounting-stop-on-failure

6. Display accounting statistics collected on the router:

user@router> show network-access aaa statistics accounting

Accounting module statistics

Requests received: 1
Accounting Response failures: 0
Accounting Response Success: 1
Requests timedout: 0

7. Open an accounting log on the RADIUS accounting server using the server's address, and view accounting
statistics:

[root@freeradius]# cd /usr/local/var/log/radius/radacct/122.69.1.250
[root@freeradius 122.69.1.250]# ls

detail-20071214

[root@freeradius 122.69.1.250]# vi details-20071214

User-Name = "000347e1bab9"
NAS-Port = 67
Acct-Status-Type = Stop
Acct-Session-Id = "8O2.1x811912"
 555

Acct-Input-Octets = 17454
Acct-Output-Octets = 4245
Acct-Session-Time = 1221041249
Acct-Input-Packets = 72
Acct-Output-Packets = 53
Acct-Terminate-Cause = Lost-Carrier
Acct-Input-Gigawords = 0
Acct-Output-Gigawords = 0
Called-Station-Id = "00-19-e2-50-52-60"
Calling-Station-Id = "00-03-47-e1-ba-b9"
Event-Timestamp = "Sep 10 2008 16:52:39 PDT"
NAS-Identifier = "esp48t-1b-01"
NAS-Port-Type = Virtual

User-Name = "000347e1bab9"
NAS-Port = 67
Acct-Status-Type = Start
Acct-Session-Id = "8O2.1x811219"
Called-Station-Id = "00-19-e2-50-52-60"
Calling-Station-Id = "00-03-47-e1-ba-b9"
Event-Timestamp = "Sep 10 2008 18:58:52 PDT"
NAS-Identifier = "esp48t-1b-01"
NAS-Port-Type = Virtual

Release History Table

Release Description

14.2 Starting with Junos OS Release 14.2, RADIUS accounting permits statistical data about users
logging onto or off a LAN to be collected and sent to a RADIUS accounting server.

RELATED DOCUMENTATION
 556

Configuring 802.1X Interface Settings on MX Series

Routers in Enhanced LAN Mode

Starting with Junos OS Release 14.2, IEEE 802.1X authentication provides network edge security, protecting
Ethernet LANs from unauthorized user access by blocking all traffic to and from a supplicant (client) at the
interface until the supplicant's credentials are presented and matched on the authentication server (a
RADIUS server). When the supplicant is authenticated, the switch stops blocking access and opens the
interface to the supplicant.

NOTE:
• You can also specify an 802.1X exclusion list to specify supplicants can that can bypass
authentication and be automatically connected to the LAN.

• You cannot configure 802.1X user authentication on interfaces that have been enabled for
Q-in-Q tunneling.

• You cannot configure 802.1X user authentication on redundant trunk groups (RTGs).

Before you begin, specify the RADIUS server or servers to be used as the authentication server.

To configure 802.1X on an interface:

1. Configure the supplicant mode as single (authenticates the first supplicant), single-secure (authenticates
only one supplicant), or multiple (authenticates multiple supplicants):

[edit protocols authentication-access-control]

user@switch# set interface ge-0/0/5 supplicant multiple

2. Enable reauthentication and specify the reauthentication interval:

[edit protocols authentication-access-control]

user@switch# set interface ge-0/0/5/0 dot1x reauthentication interval 5

3. Configure the interface timeout value for the response from the supplicant:

[edit protocols authentication-access-control]

user@switch# set interface ge-0/0/5 dot1x supplicant-timeout 5

4. Configure the timeout for the interface before it resends an authentication request to the RADIUS
server:

[edit protocols authentication-access-control]

 557

user@switch# set interface ge-0/0/5 server-timeout 5

5. Configure how long, in seconds, the interface waits before retransmitting the initial EAPOL PDUs to
the supplicant:

[edit protocols authentication-access-control]

user@switch# set interface ge-0/0/5 dot1x transmit-period 60

6. Configure the maximum number of times an EAPOL request packet is retransmitted to the supplicant
before the authentication session times out:

[edit protocols authentication-access-control]

user@switch# set interface ge-0/0/5 dot1x maximum-requests 5

7. Configure the number of times the switch attempts to authenticate the port after an initial failure. The
port remains in a wait state during the quiet period after the authentication attempt.

[edit protocols authentication-access-control]

user@switch# set interface ge-0/0/5 retries 1

NOTE: This setting specifies the number of tries before the switch puts the interface in a “HELD”
state.

Release History Table

Release Description

14.2 Starting with Junos OS Release 14.2, IEEE 802.1X authentication provides network edge security,
protecting Ethernet LANs from unauthorized user access by blocking all traffic to and from a
supplicant (client) at the interface until the supplicant's credentials are presented and matched on
the authentication server (a RADIUS server).

RELATED DOCUMENTATION
 558

Configuring LLDP-MED on MX Series Routers in

Enhanced LAN Mode

Link Layer Discovery Protocol–Media Endpoint Discovery (LLDP-MED) is an extension of LLDP. Starting
with Junos OS Release 14.2, the router uses LLDP-MED to support device discovery of VoIP telephones
and to create location databases for these telephone locations.

LLDP-MED is turned on by default on MX Series routers.

This topic describes:

Enabling LLDP-MED on Interfaces | 558

Configuring Location Information Advertised by the Router | 558

Configuring for Fast Start | 559

Enabling LLDP-MED on Interfaces

LLDP-MED is enabled on all interfaces by default. If it is disabled, you can enable LLDP-MED by configuring
it on all interfaces or on specific interfaces.

To configure LLDP-MED on all interfaces or on a specific interface:

[edit protocols lldp-med]

user@router# set interface (LLDP-MED) ge-0/0/2.0

Configuring Location Information Advertised by the Router

You can configure the location information that is advertised from the router to the LLDP-MED device.
You can specify a civic-based location (geographic location) or a location based on an ELIN (Emergency
Location Identification Number):

• To specify a location by geography:

[edit protocols lldp-med]

user@router# set interface ge-0/0/2.0 location civic-based country-code US
user@router# set interface ge-0/0/2.0 location civic-based ca-type 1 ca-value “El Dorado County”
user@router# set interface ge-0/0/2.0 location civic-based ca-type 2 ca-value CA
 559

user@router# set interface ge-0/0/2.0 location civic-based ca-type 3 ca-value Somerset

user@router# set interface ge-0/0/2.0 location civic-based ca-type 6 ca-value “Mount Aukum Road”
user@router# set interface ge-0/0/2.0 location civic-based ca-type 19 ca-value 6450
user@router# set interface ge-0/0/2.0 location civic-based ca-type 21 ca-value “Holiday Market”

• To specify a location using an elin string:

[edit protocols lldp-med]

user@router# set interface ge-0/0/2.0 location elin 4085551212

Configuring for Fast Start

You can specify the number of LLDP-MED advertisements sent from the router in the first second after
it has detected an LLDP-MED device. The default is 3; to set it to another value:

[edit protocols lldp-med]

user@router# set fast-start 6

NOTE: If an interface is configured as a VoIP interface, then the router does not wait for an
attached phone to identify itself as an LLDP-MED device before it performs an LLDP-MED fast
start after a graceful Routing Engine switchover (GRES) or a reboot. Instead, it immediately
performs an LLDP-MED fast start after a GRES or reboot. This behavior prevents certain models
of IP phones from resetting after a GRES.

Release History Table

Release Description

14.2 Starting with Junos OS Release 14.2, the router uses LLDP-MED to support device discovery
of VoIP telephones and to create location databases for these telephone locations.

RELATED DOCUMENTATION
 560

Configuring LLDP on MX Series Routers in Enhanced

LAN Mode

Starting with Junos OS Release 14.2, devices use Link Layer Discovery Protocol (LLDP) and Link Layer
Discovery Protocol–Media Endpoint Discovery (LLDP-MED) to learn and distribute device information on
network links.The information enables the device to quickly identify a variety of other devices, resulting
in a LAN that interoperates smoothly and efficiently.

This topic describes:

Enabling LLDP on Interfaces | 560

Adjusting LLDP Advertisement Settings | 561

Adjusting SNMP Notification Settings of LLDP Changes | 562

Specifying a Management Address for the LLDP Management TLV | 563

Enabling LLDP on Interfaces

LLDP is enabled on all interfaces by default. If it is disabled, you can enable LLDP by configuring it on all
interfaces or on specific interfaces.

• To configure LLDP on all interfaces:

[edit protocols lldp]

user@router# set interface all

• To configure LLDP on a specific interface:

[edit protocols lldp]

user@router# set interface interface-name

NOTE: On MX Series routers, LLDP cannot be configured on the management Ethernet interface.
Issuing the command set protocols lldp interfaceem0 generates the following error message:

error: name: 'em0': Invalid interface

error: statement creation failed: interface
 561

Adjusting LLDP Advertisement Settings

You can adjust the following settings for LLDP advertisements for troubleshooting or verification purposes.
The default values are applied when LLDP is enabled. For normal operations, we recommend that you do
not change the default values.

• To specify the frequency at which LLDP advertisements are sent (in seconds):

[edit protocols lldp]

user@router# set advertisement-interval seconds

For example, using the default value:

[edit protocols lldp]

user@router# set advertisement-interval 45

• To specify the number of seconds that LLDP information is held before it is discarded (the multiplier
value is used in combination with the advertisement-interval value):

[edit protocols lldp]

user@router# set hold-multiplier seconds

For example, using the default value:

[edit protocols lldp]

user@router# set hold-multiplier 5

• To specify the number of seconds the device delays before sending advertisements to neighbors after
a change is made in a TLV (type, length, or value) element in LLDP or in the state of the local system,
such as a change in hostname or management address, set the transmit delay. The transmit delay is
enabled by default on switches to reduce the delay in notifying neighbors of a change in the local system.
The default value is 2 seconds (if the advertisement-interval value is set to 8 seconds or more) or 1
second (if the advertisement-interval value is set to less than 8 seconds).

[edit protocols lldp]

user@router# set transmit-delay seconds

For example:

[edit protocols lldp]

user@router# set transmit-delay 2
 562

NOTE: The advertisement-interval value must be greater than or equal to four times the
transmit-delay value; otherwise, an error is returned when you attempt to commit the
configuration.

Adjusting SNMP Notification Settings of LLDP Changes

You can adjust the following settings for SNMP notifications of LLDP changes. If the values are not specified
or if the interval values are set to 0, the notifications are disabled.

• To specify the frequency at which LLDP database changes are sent (in seconds):

[edit protocols lldp]

user@router# set lldp-configuration-notification-interval seconds

For example:

[edit protocols lldp]

user@router# set lldp-configuration-notification-interval 600

• To configure the time interval for SNMP trap notifications to wait for topology changes (in seconds):

[edit protocols lldp]

user@router# set ptopo-configuration-trap-interval seconds

For example:

[edit protocols lldp]

user@router# set ptopo-configuration-trap-interval 600

• To specify the holding time (used in combination with the ptopo-configuration-trap-interval value) to
maintain dynamic topology entries (in seconds):

[edit protocols lldp]

user@router# set ptopo-configuration-maximum-hold-time seconds

For example:

[edit protocols lldp]

user@router# set ptopo-configuration-maximum-hold-time 2147483647
 563

Specifying a Management Address for the LLDP Management TLV

You can configure an IPv4 or IPv6 management address to be used in the LLDP Management Address
type, length, and value (TLV) messages. Only out-of-band management addresses must be used as the
value for the management-address statement.

To configure the management address:

[edit protocols lldp]

user@router# set management-address ip-address

NOTE: Ensure that the interface with the configured management address has LLDP enabled
using the set protocols lldp interface command. If you configure a customized management
address for LLDP on an interface that has LLDP disabled, the show lldp local-information
command output will not display the correct interface information.

Release History Table

Release Description

14.2 Starting with Junos OS Release 14.2, devices use Link Layer Discovery Protocol (LLDP) and
Link Layer Discovery Protocol–Media Endpoint Discovery (LLDP-MED) to learn and distribute
device information on network links.
 564

Configuring Server Fail Fallback on MX Series Routers

in Enhanced LAN Mode

Starting with Junos OS Release 14.2, server fail fallback allows you to specify how end devices connected
to the router are supported if the RADIUS authentication server becomes unavailable or sends a RADIUS
access-reject message.

802.1X and MAC RADIUS authentication work by using an authenticator port access entity (the router) to
block all traffic to and from an end device at the interface until the end device's credentials are presented
and matched on the authentication server (a RADIUS server). When the end device has been authenticated,
the router stops blocking and opens the interface to the end device.

When you set up 802.1X or MAC RADIUS authentication on the router, you specify a primary authentication
server and one or more backup authentication servers. If the primary authentication server cannot be
reached by the router and the secondary authentication servers are also unreachable, a RADIUS server
timeout occurs. Because the authentication server grants or denies access to the end devices awaiting
authentication, the router does not receive access instructions for end devices attempting access to the
LAN and normal authentication cannot be completed. Server fail fallback allows you to configure
authentication alternatives that permit the router to take appropriate actions toward end devices awaiting
authentication or reauthentication.

NOTE: The authentication fallback method called server-reject VLAN provi