Configuring IPsec - HPE Support Center

HPE FlexNetwork HSR6800 Routers
Security Configuration Guide
Part number: 5998-4496R
Software version: HSR6800-CMW520-R3303P25
Document version: 6W105-20151231
© Copyright 2015 Hewlett Packard Enterprise Development LP
The information contained herein is subject to change without notice. The only warranties for Hewlett Packard
Enterprise products and services are set forth in the express warranty statements accompanying such
products and services. Nothing herein should be construed as constituting an additional warranty. Hewlett
Packard Enterprise shall not be liable for technical or editorial errors or omissions contained herein.
Confidential computer software. Valid license from Hewlett Packard Enterprise required for possession, use, or
copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software
Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s
standard commercial license.
Links to third-party websites take you outside the Hewlett Packard Enterprise website. Hewlett Packard
Enterprise has no control over and is not responsible for information outside the Hewlett Packard Enterprise
website.
Acknowledgments
Intel®, Itanium®, Pentium®, Intel Inside®, and the Intel Inside logo are trademarks of Intel Corporation in the
United States and other countries.
Microsoft® and Windows® are trademarks of the Microsoft group of companies.
Adobe® and Acrobat® are trademarks of Adobe Systems Incorporated.
Java and Oracle are registered trademarks of Oracle and/or its affiliates.
UNIX® is a registered trademark of The Open Group.
Contents
Security overview ···························································································· 1
Network security threats ···································································································································· 1
Network security services ·································································································································· 1
Network security technologies ··························································································································· 1
Identity authentication ································································································································ 1
Access security ·········································································································································· 2
Data security ·············································································································································· 2
Firewall and connection control·················································································································· 3
Attack detection and protection ·················································································································· 4
Other security technologies························································································································ 5
Configuring AAA ····························································································· 6
Overview ···························································································································································· 6
RADIUS······················································································································································ 7
HWTACACS············································································································································· 11
Domain-based user management ············································································································ 14
AAA for MPLS L3VPNs ···························································································································· 15
Protocols and standards ·························································································································· 15
RADIUS attributes ···································································································································· 16
AAA configuration considerations and task list ································································································ 19
Configuring AAA schemes ······························································································································· 20
Configuring local users····························································································································· 20
Configuring RADIUS schemes ················································································································· 24
Configuring HWTACACS schemes ·········································································································· 36
Configuring AAA methods for ISP domains ····································································································· 42
Creating an ISP domain ··························································································································· 42
Configuring ISP domain attributes ··········································································································· 43
Configuring authentication methods for an ISP domain ··········································································· 44
Configuring authorization methods for an ISP domain············································································· 46
Configuring accounting methods for an ISP domain ················································································ 47
Tearing down user connections ······················································································································· 49
Configuring a NAS ID-VLAN binding ··············································································································· 49
Displaying and maintaining AAA ······················································································································ 50
AAA configuration examples ···························································································································· 50
RADIUS authentication/authorization for Telnet/SSH users ···································································· 50
Local authentication/authorization for Telnet/FTP users ·········································································· 54
AAA for PPP users by an HWTACACS server ························································································ 55
Level switching authentication for Telnet users by a RADIUS server ······················································ 56
AAA for portal users by a RADIUS server································································································ 60
Troubleshooting AAA ······································································································································· 66
Troubleshooting RADIUS ························································································································· 66
Troubleshooting HWTACACS ·················································································································· 68
802.1X overview ··························································································· 69
802.1X architecture ·········································································································································· 69
Controlled/uncontrolled port and port authorization status ·············································································· 69
802.1X-related protocols ·································································································································· 70
Packet formats ········································································································································· 70
EAP over RADIUS ··································································································································· 71
Initiating 802.1X authentication ························································································································ 72
802.1X client as the initiator ····················································································································· 72
Access device as the initiator ··················································································································· 72
802.1X authentication procedures ··················································································································· 72
A comparison of EAP relay and EAP termination ···················································································· 73
EAP relay ················································································································································· 73
EAP termination ······································································································································· 75
i
Configuring 802.1X ······················································································· 77
Hewlett Packard Enterprise implementation of 802.1X ···················································································· 77
Access control methods ··························································································································· 77
Using 802.1X authentication with other features······················································································ 77
Configuration prerequisites ······························································································································ 81
802.1X configuration task list ··························································································································· 81
Enabling 802.1X ··············································································································································· 82
Enabling EAP relay or EAP termination ··········································································································· 82
Setting the port authorization state ·················································································································· 83
Specifying an access control method ·············································································································· 83
Setting the maximum number of concurrent 802.1X users on a port ······························································· 84
Setting the maximum number of authentication request attempts ··································································· 84
Setting the 802.1X authentication timeout timers ···························································································· 85
Configuring the online user handshake function ······························································································ 85
Configuration guidelines··························································································································· 85
Configuration procedure··························································································································· 86
Enabling the proxy detection function ·············································································································· 86
Configuring the authentication trigger function ································································································ 87
Configuration guidelines··························································································································· 87
Configuration procedure··························································································································· 87
Specifying a mandatory authentication domain on a port ················································································ 87
Configuring the quiet timer ······························································································································· 88
Enabling the periodic online user re-authentication function ··········································································· 88
Configuring an 802.1X guest VLAN ················································································································· 89
Configuring an Auth-Fail VLAN ························································································································ 89
Configuring an 802.1X critical VLAN ················································································································ 90
Specifying supported domain name delimiters ································································································ 91
Displaying and maintaining 802.1X ·················································································································· 91
802.1X authentication configuration example ·································································································· 92
Network requirements ······························································································································ 92
Configuration procedure··························································································································· 92
Verifying the configuration························································································································ 94
802.1X guest VLAN and VLAN assignment configuration example ································································ 94
Network requirements ······························································································································ 94
Configuration procedure··························································································································· 95
Verifying the configuration························································································································ 96
802.1X with ACL assignment configuration example ······················································································· 97
Network requirements ······························································································································ 97
Configuration procedure··························································································································· 97
Verifying the configuration························································································································ 98
Configuring EAD fast deployment ································································· 99
Overview ·························································································································································· 99
Free IP ····················································································································································· 99
URL redirection ········································································································································ 99
Configuration prerequisites ······························································································································ 99
Configuring a free IP ········································································································································ 99
Configuring the redirect URL ························································································································· 100
Setting the EAD rule timer ····························································································································· 100
Displaying and maintaining EAD fast deployment ························································································· 100
EAD fast deployment configuration example ································································································· 101
Network requirements ···························································································································· 101
Configuration procedure························································································································· 101
Verifying the configuration······················································································································ 102
Troubleshooting EAD fast deployment ·········································································································· 103
Web browser users cannot be correctly redirected ················································································ 103
Configuring MAC authentication ································································· 104
Overview ························································································································································ 104
User account policies ····························································································································· 104
Authentication methods·························································································································· 104
ii
MAC authentication timers ····················································································································· 105
Using MAC authentication with other features ······························································································· 105
VLAN assignment ·································································································································· 105
ACL assignment ····································································································································· 105
Configuration task list ····································································································································· 105
Basic configuration for MAC authentication ··································································································· 106
Configuring MAC authentication globally ······························································································· 106
Configuring MAC authentication on a port ····························································································· 106
Specifying a MAC authentication domain ······································································································ 107
Displaying and maintaining MAC authentication ···························································································· 107
MAC authentication configuration examples ·································································································· 108
Local MAC authentication configuration example ·················································································· 108
RADIUS-based MAC authentication configuration example ·································································· 109
ACL assignment configuration example································································································· 111
Configuring portal authentication ································································ 114
Overview ························································································································································ 114
Extended portal functions······················································································································· 114
Portal system components ····················································································································· 114
Portal authentication modes··················································································································· 116
Portal support for EAP ··························································································································· 117
Layer 3 portal authentication process ···································································································· 117
Portal authentication across VPNs········································································································· 121
Portal configuration task list ··························································································································· 121
Configuration prerequisites ···························································································································· 122
Specifying a portal server for Layer 3 portal authentication ··········································································· 123
Enabling Layer 3 portal authentication ··········································································································· 123
Controlling access of portal users ·················································································································· 124
Configuring a portal-free rule ················································································································· 124
Configuring an authentication source subnet ························································································· 125
Configuring an authentication destination subnet ·················································································· 125
Setting the maximum number of online portal users ·············································································· 126
Specifying an authentication domain for portal users ············································································ 126
Configuring RADIUS related attributes ·········································································································· 127
Specifying the NAS ID value carried in a RADIUS request···································································· 127
Specifying NAS-Port-Type for an interface ···························································································· 127
Specifying the NAS-Port-ID for an interface··························································································· 128
Specifying a NAS ID profile for an interface ··························································································· 128
Specifying a source IP address for outgoing portal packets ·········································································· 129
Specifying a device ID for the access device ································································································· 129
Specifying an autoredirection URL for authenticated portal users ································································· 130
Configuring portal detection functions ············································································································ 130
Configuring online Layer 3 portal user detection···················································································· 130
Configuring the portal server detection function····················································································· 131
Configuring portal user information synchronization ·············································································· 132
Logging off portal users ································································································································· 133
Displaying and maintaining portal ·················································································································· 133
Portal configuration examples ························································································································ 134
Configuring direct portal authentication·································································································· 134
Configuring re-DHCP portal authentication ···························································································· 138
Configuring cross-subnet portal authentication ······················································································ 140
Configuring direct portal authentication with extended functions ··························································· 142
Configuring re-DHCP portal authentication with extended functions ····················································· 144
Configuring cross-subnet portal authentication with extended functions ··············································· 146
Configuring portal server detection and portal user information synchronization ·································· 148
Cross-subnet portal authentication across VPNs··················································································· 153
Troubleshooting portal ··································································································································· 154
Inconsistent keys on the access device and the portal server ······························································· 154
Incorrect server port number on the access device ··············································································· 155
Configuring port security ············································································· 156
Overview ························································································································································ 156
iii
Configuring port security ························································································································ 156
Port security modes ······························································································································· 156
Working with guest VLAN and Auth-Fail VLAN······················································································ 159
Configuration task list ····································································································································· 159
Enabling port security ···································································································································· 159
Setting port security's limit on the number of MAC addresses on a port ······················································· 160
Setting the port security mode ······················································································································· 160
Configuration prerequisites ···················································································································· 160
Configuration procedure························································································································· 160
Configuring port security features ·················································································································· 161
Configuring NTK····································································································································· 161
Configuring intrusion protection ············································································································· 162
Enabling port security traps···················································································································· 162
Configuring secure MAC addresses ·············································································································· 163
Configuration prerequisites ···················································································································· 163
Configuration procedure························································································································· 163
Ignoring authorization information from the server ························································································ 164
Displaying and maintaining port security ······································································································· 165
Port security configuration examples ············································································································· 165
Configuring the autoLearn mode············································································································ 165
Configuring the userLoginWithOUI mode ······························································································ 167
Configuring the macAddressElseUserLoginSecure mode ····································································· 171
Troubleshooting port security ························································································································· 174
Cannot set the port security mode ········································································································· 174
Cannot configure secure MAC addresses ····························································································· 175
Cannot change port security mode when a user is online ····································································· 175
Configuring a user profile ············································································ 176
Overview ························································································································································ 176
User profile configuration task list ·················································································································· 176
Creating a user profile ···································································································································· 176
Performing configurations in user profile view ······························································································· 177
Enabling a user profile ··································································································································· 177
Displaying and maintaining user profile ········································································································· 177
Configuring password control ····································································· 178
Overview ························································································································································ 178
FIPS compliance ············································································································································ 180
Password control configuration task list ········································································································· 180
Enabling password control ····························································································································· 181
Setting global password control parameters ·································································································· 181
Setting user group password control parameters ·························································································· 182
Setting local user password control parameters ···························································································· 183
Setting super password control parameters ·································································································· 184
Setting a local user password in interactive mode ························································································· 184
Displaying and maintaining password control ································································································ 184
Password control configuration example ······································································································· 185
Configuring RSH ························································································· 188
Configuration prerequisites ···························································································································· 188
Configuration procedure ································································································································ 188
RSH configuration example ··························································································································· 188
Managing public keys ················································································· 191
FIPS compliance ············································································································································ 191
Configuration task list ····································································································································· 191
Creating a local asymmetric key pair ············································································································· 192
Displaying or exporting the local host public key ··························································································· 192
Displaying and recording the host public key information ·············································································· 193
Displaying the host public key in a specific format and saving it to a file ······················································· 193
Exporting the host public key in a specific format to a file ············································································· 193
Destroying a local asymmetric key pair ········································································································· 194
iv
Exporting an RSA key pair ····························································································································· 194
Importing an RSA key pair ····························································································································· 194
Specifying the peer public key on the local device ························································································ 195
Displaying public keys ···································································································································· 196
Public key configuration examples ················································································································· 196
Manually specifying the peer public key on the local device ·································································· 196
Importing a public key from a public key file ·························································································· 198
Exporting and importing an RSA key pair ······························································································ 200
Configuring PKI ··························································································· 204
Overview ························································································································································ 204
PKI terms ··············································································································································· 204
PKI architecture······································································································································ 205
PKI operation ········································································································································· 205
PKI applications ····································································································································· 206
FIPS compliance ············································································································································ 206
PKI configuration task list ······························································································································· 206
Configuring a PKI entity ································································································································· 206
Configuring a PKI domain ······························································································································ 208
Requesting a certificate ································································································································· 209
Configuring automatic certificate request ······························································································· 209
Manually requesting a certificate············································································································ 210
Obtaining certificates ····································································································································· 211
Verifying PKI certificates ································································································································ 211
Verifying PKI certificates with CRL checking ························································································· 212
Verifying PKI certificates without CRL checking ···················································································· 212
Destroying the local RSA key pair ················································································································· 212
Removing a certificate ··································································································································· 213
Configuring an access control policy ············································································································· 213
Displaying and maintaining PKI ····················································································································· 213
PKI configuration examples ··························································································································· 214
Certificate request from an RSA Keon CA server ·················································································· 214
Certificate request from a Windows 2003 CA server ············································································· 217
IKE negotiation with RSA digital signature ····························································································· 220
Troubleshooting PKI ······································································································································ 222
Failed to obtain a CA certificate ············································································································· 222
Failed to request a local certificate········································································································· 222
Failed to obtain CRLs····························································································································· 223
Configuring IPsec ························································································ 224
Overview ························································································································································ 224
Basic concepts ······································································································································· 224
IPsec tunnel interface····························································································································· 226
IPsec for IPv6 routing protocols ············································································································· 227
IPsec RRI ··············································································································································· 228
Protocols and standards ························································································································ 228
FIPS compliance ············································································································································ 228
Implementing IPsec ······································································································································· 229
Implementing ACL-based IPsec ···················································································································· 229
Configuring an ACL ································································································································ 230
Configuring an IPsec transform set ········································································································ 232
Configuring an IPsec policy···················································································································· 233
Applying an IPsec policy group to an interface ······················································································ 238
Enabling the encryption engine ·············································································································· 239
Enabling ACL checking of de-encapsulated IPsec packets ··································································· 239
Configuring the IPsec anti-replay function ····························································································· 240
Configuring packet information pre-extraction ······················································································· 240
Enabling invalid SPI recovery ················································································································ 241
Configuring IPsec RRI···························································································································· 241
Enabling IPsec packet fragmentation before/after encryption································································ 242
Implementing tunnel interface-based IPsec ··································································································· 243
Configuring an IPsec profile ··················································································································· 244
v
Configuring an IPsec tunnel interface ···································································································· 245
Enabling packet information pre-extraction on the IPsec tunnel interface ············································· 246
Applying a QoS policy to an IPsec tunnel interface ··············································································· 247
Configuring IPsec for IPv6 routing protocols ·································································································· 247
Displaying and maintaining IPsec ·················································································································· 248
IPsec configuration examples ························································································································ 249
Configuring a manual mode IPsec tunnel for IPv4 packets ··································································· 249
Configuring an IKE-based IPsec tunnel for IPv4 packets ······································································ 251
Configuring IKE-based IPsec tunnel for IPv6 packets ··········································································· 253
Configuring IPsec with IPsec tunnel interfaces ······················································································ 255
Configuring IPsec for RIPng··················································································································· 259
Configuring IPsec RRI···························································································································· 262
Configuring IKE ··························································································· 266
Overview ························································································································································ 266
IKE security mechanism························································································································· 266
IKE operation ········································································································································· 266
IKE functions ·········································································································································· 267
Relationship between IKE and IPsec ····································································································· 268
Protocols and standards ························································································································ 268
FIPS compliance ············································································································································ 268
IKE configuration task list ······························································································································· 268
Configuring a name for the local security gateway ························································································ 269
Configuring an IKE proposal ·························································································································· 269
Configuring an IKE peer ································································································································· 270
Setting keepalive timers ································································································································· 273
Setting the NAT keepalive timer ···················································································································· 273
Configuring a DPD detector ··························································································································· 273
Disabling next payload field checking ············································································································ 274
Displaying and maintaining IKE ····················································································································· 274
IKE configuration examples ··························································································································· 275
Configuring main mode IKE with pre-shared key authentication ··························································· 275
Configuring aggressive mode IKE with NAT traversal ··········································································· 279
Troubleshooting IKE ······································································································································ 282
Invalid user ID ········································································································································ 282
Proposal mismatch································································································································· 282
Failing to establish an IPsec tunnel········································································································ 283
ACL configuration error ·························································································································· 283
Configuring SSH ························································································· 284
Overview ························································································································································ 284
How SSH works ····································································································································· 284
SSH authentication ································································································································ 285
SSH support for MPLS L3VPN ·············································································································· 286
FIPS compliance ············································································································································ 286
Configuring the device as an SSH server ······································································································ 286
SSH server configuration task list ·········································································································· 286
Generating local DSA or RSA key pairs································································································· 287
Enabling the SSH server function ·········································································································· 287
Enabling the SFTP server function ········································································································ 288
Configuring the user interfaces for SSH clients ····················································································· 288
Configuring a client's host public key ····································································································· 289
Configuring an SSH user ······················································································································· 290
Setting the SSH management parameters ···························································································· 291
Configuring the device as an Stelnet client ···································································································· 292
Stelnet client configuration task list ········································································································ 292
Specifying a source IP address or source interface for the Stelnet client ·············································· 292
Enabling and disabling first-time authentication ····················································································· 293
Establishing a connection to an Stelnet server ······················································································ 293
Configuring the device as an SFTP client ······································································································ 294
SFTP client configuration task list ·········································································································· 294
Specifying a source IP address or source interface for the SFTP client ················································ 295
vi
Establishing a connection to an SFTP server ························································································ 295
Working with SFTP directories ··············································································································· 296
Working with SFTP files ························································································································· 297
Displaying help information ···················································································································· 298
Terminating the connection with the SFTP server ················································································· 298
Configuring the device as an SCP client ········································································································ 298
SCP client configuration task list ············································································································ 298
Transferring files with an SCP server····································································································· 298
Displaying and maintaining SSH ···················································································································· 299
Stelnet configuration examples ······················································································································ 300
Password authentication enabled Stelnet server configuration example ··············································· 300
Publickey authentication enabled Stelnet server configuration example ··············································· 302
Password authentication enabled Stelnet client configuration example ················································ 307
Publickey authentication enabled Stelnet client configuration example ················································· 310
SFTP configuration examples ························································································································ 312
Password authentication enabled SFTP server configuration example ················································· 312
Publickey authentication enabled SFTP client configuration example ··················································· 314
SCP file transfer with password authentication ······························································································ 317
Network requirements ···························································································································· 318
Configuration procedure························································································································· 318
Configuring firewall ····················································································· 320
Overview ························································································································································ 320
ACL based packet-filter ·························································································································· 320
ASPF ······················································································································································ 320
Configuring a packet-filter firewall ·················································································································· 322
Packet-filter firewall configuration task list ····························································································· 322
Enabling the firewall function ················································································································· 323
Configuring the default filtering action of the firewall·············································································· 323
Configuring packet filtering on an interface ···························································································· 324
Displaying and maintaining a packet-filter firewall ················································································· 325
Packet-filter firewall configuration example ···························································································· 325
Configuring an ASPF ····································································································································· 326
ASPF configuration task list ··················································································································· 326
Enabling the firewall function ················································································································· 327
Configuring an ASPF policy ··················································································································· 327
Applying an ASPF policy to an interface ································································································ 327
Configuring port mapping ······················································································································· 328
Displaying ASPF ···································································································································· 328
ASPF configuration example·················································································································· 328
Configuring ALG ························································································· 330
ALG process ·················································································································································· 330
Enabling ALG ················································································································································· 331
FTP ALG configuration example ···················································································································· 332
SIP/H.323 ALG configuration example ·········································································································· 332
NBT ALG configuration example ··················································································································· 333
Managing sessions ····················································································· 335
Overview ························································································································································ 335
Session management operation ············································································································ 335
Session management functions ············································································································· 335
Session management task list ······················································································································· 336
Setting session aging times based on protocol state ············································································· 336
Configuring session aging time based on application layer protocol type·············································· 337
Configuring early aging for sessions ······································································································ 337
Setting the maximum number of sessions ····························································································· 338
Enabling checksum verification ·············································································································· 338
Specifying the persistent session rule ···································································································· 339
Clearing sessions manually ··················································································································· 339
Configuring session logging ··························································································································· 340
Enabling session logging ······················································································································· 340
vii
Setting session logging thresholds········································································································· 340
Configuring session log export ··············································································································· 341
Displaying and maintaining session management ························································································· 341
Configuring connection limits ······································································ 344
Overview ························································································································································ 344
Connection limit configuration task list ··········································································································· 344
Creating a connection limit policy ·················································································································· 344
Configuring the connection limit policy ··········································································································· 344
Applying the connection limit policy ··············································································································· 345
Displaying and maintaining connection limiting ····························································································· 345
Connection limit configuration example ········································································································· 345
Network requirements ···························································································································· 345
Configuration procedure························································································································· 346
Verifying the configuration······················································································································ 346
Troubleshooting connection limiting ··············································································································· 347
Connection limit rules with overlapping segments ················································································· 347
Connection limit rules with overlapping protocol types ·········································································· 347
Configuring Web filtering ············································································· 348
Overview ························································································································································ 348
URL address filtering······························································································································ 348
IP address-supported URL address filtering ·························································································· 348
URL parameter filtering ·························································································································· 349
Java blocking ········································································································································· 349
ActiveX blocking ····································································································································· 349
Configuring Web filtering ································································································································ 350
Configuring URL address filtering ·········································································································· 350
Configuring IP address-supported URL address filtering ······································································· 350
Configuring URL parameter filtering······································································································· 351
Configuring Java blocking ······················································································································ 351
Configuring ActiveX blocking ················································································································· 351
Displaying and maintaining Web filtering ······································································································· 352
URL address filtering configuration example ································································································· 352
URL parameter filtering configuration example ······························································································ 354
Java blocking configuration example ············································································································· 355
Troubleshooting Web filtering ························································································································ 356
Failed to add filtering entry or suffix keyword due to upper limit ···························································· 356
Invalid characters are present in the configured parameter ··································································· 356
Invalid use of wildcard ···························································································································· 357
Invalid blocking suffix ····························································································································· 358
ACL configuration failed ························································································································· 358
Unable to access the HTTP server by IP address ················································································· 358
Configuring attack detection and protection ···················································· 1
Overview ···························································································································································· 1
Types of network attacks the device can defend against··········································································· 1
Blacklist function ········································································································································ 2
Traffic statistics function ····························································································································· 3
TCP proxy ·················································································································································· 4
Attack detection and protection configuration task list ······················································································· 6
Configuring attack protection functions for an interface ····················································································· 6
Creating an attack protection policy ··········································································································· 6
Configuring an attack protection policy ······································································································ 7
Applying an attack protection policy to an interface ················································································· 10
Configuring TCP proxy ····································································································································· 10
Configuring the blacklist function ····················································································································· 11
Enabling traffic statistics on an interface ·········································································································· 11
Configuring TCP fragment attack protection ···································································································· 12
Displaying and maintaining attack detection and protection ············································································ 12
Attack detection and protection configuration examples ·················································································· 13
Attack protection functions on interfaces configuration example ····························································· 13
viii
Blacklist configuration example ················································································································ 15
Traffic statistics configuration example ···································································································· 16
TCP proxy configuration example ············································································································ 18
Configuring TCP attack protection ································································ 20
Overview ·························································································································································· 20
Enabling the SYN Cookie feature ···················································································································· 20
Enabling protection against Naptha attacks ····································································································· 21
Displaying and maintaining TCP attack protection ·························································································· 21
Configuring IP source guard ········································································· 22
Overview ·························································································································································· 22
Static IP source guard entries ·················································································································· 22
Dynamic IP source guard entries ············································································································· 23
Configuring IPv4 source guard ························································································································ 23
Enabling IPv4 source guard on a port ······································································································ 23
Configuring a static IPv4 source guard entry ··························································································· 24
Setting the maximum number of IPv4 source guard entries ···································································· 24
Displaying and maintaining IP source guard ···································································································· 25
Static IPv4 source guard entry configuration example ····················································································· 25
Dynamic IPv4 source guard by DHCP snooping configuration example ························································· 27
Dynamic IPv4 source guard by DHCP relay configuration example ································································ 28
Troubleshooting IP source guard ····················································································································· 29
Configuring ARP attack protection ································································ 31
Overview ·························································································································································· 31
ARP attack protection configuration task list ···································································································· 31
Configuring unresolvable IP attack protection ································································································· 32
Configuring ARP source suppression ······································································································ 32
Enabling ARP blackhole routing··············································································································· 32
Displaying and maintaining ARP source suppression·············································································· 32
Configuration example ····························································································································· 32
Configuring ARP packet rate limit ···················································································································· 33
Configuring ARP packet source MAC consistency check ················································································ 34
Configuring ARP active acknowledgement ······································································································ 34
Configuring authorized ARP ···························································································································· 34
Configuration example (on a DHCP server)····························································································· 35
Authorized ARP configuration example (on a DHCP relay agent) ··························································· 36
Configuring ARP detection ······························································································································· 38
Configuring user validity check ················································································································ 38
Configuring ARP packet validity check ···································································································· 39
Configuring ARP restricted forwarding ····································································································· 40
Displaying and maintaining ARP detection ······························································································ 40
User validity check configuration example ······························································································· 40
User validity check and ARP packet validity check configuration example·············································· 42
ARP restricted forwarding configuration example ···················································································· 43
Configuring ARP automatic scanning and fixed ARP ······················································································ 45
Configuration guidelines··························································································································· 45
Configuration procedure··························································································································· 46
Configuring ARP gateway protection ··············································································································· 46
ARP gateway protection configuration example ······················································································ 47
Configuring ARP filtering ·································································································································· 47
ARP filtering configuration example ········································································································· 48
Configuring ND attack defense ····································································· 50
Overview ·························································································································································· 50
Enabling source MAC consistency check for ND packets ··············································································· 51
Configuring URPF ························································································· 52
Overview ·························································································································································· 52
URPF check modes ································································································································· 52
URPF features ········································································································································· 52
ix
URPF work flow ······································································································································· 52
Network application ·································································································································· 54
Configuring URPF on an interface ··················································································································· 55
URPF configuration example ··························································································································· 55
Network requirements ······························································································································ 55
Configuration procedure··························································································································· 55
Configuring FIPS ··························································································· 57
Overview ·························································································································································· 57
FIPS self-tests ·················································································································································· 57
Power-up self-tests ·································································································································· 57
Conditional self-tests ································································································································ 58
Triggering a self-test ································································································································ 58
Configuration changes in FIPS mode ·············································································································· 58
Configuration considerations ··························································································································· 59
Enabling FIPS mode ········································································································································ 59
Displaying and maintaining FIPS ····················································································································· 59
FIPS configuration example ····························································································································· 59
Network requirements ······························································································································ 59
Configuration procedure··························································································································· 60
Verifying the configuration························································································································ 61
Configuring group domain VPN ···································································· 62
Overview ·························································································································································· 62
Group domain VPN structure ··················································································································· 62
Group domain VPN establishment ··········································································································· 63
KS redundancy········································································································································· 64
Protocols and standards ·························································································································· 65
Configuration restrictions and guidelines ········································································································· 65
Configuring the GDOI KS ································································································································· 66
GDOI KS configuration task list················································································································ 66
Configuring basic settings for a GDOI KS group······················································································ 66
Configuring GDOI KS redundancy ··········································································································· 67
Specifying the source address for packets sent by the KS ······································································ 68
Configuring rekey parameters ·················································································································· 69
Displaying and maintaining GDOI KS ······································································································ 69
Configuring the GDOI GM ································································································································ 70
GDOI GM configuration task list··············································································································· 70
Configuring a GDOI GM group················································································································· 70
Configuring a GDOI IPsec policy ············································································································· 71
Applying a GDOI IPsec policy to an interface ·························································································· 72
Displaying and maintaining GM ··············································································································· 72
Group domain VPN configuration example ······································································································ 73
Network requirements ······························································································································ 73
Configuration procedure··························································································································· 74
Troubleshooting group domain VPN ················································································································ 87
IKE SA negotiation failure ························································································································ 87
GM registration failure ······························································································································ 88
KS redundancy failure ······························································································································ 88
Document conventions and icons ································································· 90
Conventions ····················································································································································· 90
Network topology icons ···································································································································· 91
Support and other resources ········································································ 92
Accessing Hewlett Packard Enterprise Support ······························································································ 92
Accessing updates ··········································································································································· 92
Websites ·················································································································································· 93
Customer self repair ································································································································· 93
Remote support········································································································································ 93
Documentation feedback ························································································································· 93
x
Index ············································································································· 95
xi
Security overview
Network security threats are happened or potential threats to data confidentiality, data integrity, data
availability or authorized usage of some resource in a network system. Network security services
provide solutions to solve or reduce those threats to different extents.
Network security threats
•
Information disclosure—Information is leaked to an unauthorized person or entity.
•
Data integrity damage—Data integrity is damaged by unauthorized modification or malicious
destruction.
•
Denial of service—Makes information or other network resources unavailable to their intended
users.
•
Unauthorized usage—Resources are used by unauthorized persons or in unauthorized ways.
Network security services
One security service is implemented by one or more network security technologies. One technology
can implement multiple services. A safe network needs the following services:
•
Identity authentication—Identifies users and determines if a user is valid. Typical ways
include AAA-based username plus password authentication, and PKI digital certificate-based
authentication.
•
Access security—Controls behaviors in which a user accesses network resources based on
the identity authentication result to prevent unauthorized access and usage of the network
resources. Major access security protocols include 802.1X, MAC authentication, and portal
authentication, which work together with AAA to implement user identity authentication.
•
Data security—Encrypts and decrypts data during data transmission and storage. Typical
encryption mechanisms include symmetric encryption and asymmetric encryption, and their
common applications are IPsec and SSH. IPsec secures IP communications. SSH protects
data transfer based on TCP.
•
Firewall—A highly effective network security model to block unauthorized Internet access to a
protected network. Major firewall implementations are ACL based packet filter, ASPF, and ALG.
•
Attack detection and protection—Identifies attacks by inspecting network traffic behaviors or
application layer protocol packet contents. According to the inspection result, it takes measures
to deal with the attacks or would-be attacks at the data link layer, network layer, or application
layer.
Network security technologies
Identity authentication
AAA
AAA provides a uniform framework for implementing network access management. It provides the
following security functions:
•
Authentication—Identifies network users and determines whether the user is valid.
1
•
Authorization—Grants user rights and controls user access to resources and services. For
example, a user who has successfully logged in to the device can be granted read and print
permissions to the files on the device.
•
Accounting—Records all network service usage information, including the service type, start
time, and traffic. The accounting function allows for user behavior auditing.
AAA can be implemented through multiple protocols, such as RADIUS, HWTACACS, and LDAP,
among which RADIUS is most often used.
PKI
PKI uses a general security infrastructure to provide information security through public key
technologies. PKI employs the digital certificate mechanism to manage the public keys. The digital
certificate mechanism binds public keys to their owners, helping distribute public keys in large
networks securely. With digital certificates, the PKI system provides network communication,
e-commerce, and e-Government with security services.
PKI system provides digital certificate management for IPsec.
Access security
802.1X
802.1X is a port-based network access control protocol for securing wireless LANs (WLANs), and it
has also been widely used on Ethernet networks for access control. 802.1X controls network access
by authenticating the devices connected to 802.1X-enabled LAN ports.
MAC authentication
MAC authentication controls network access by authenticating source MAC addresses on a port. It
does not require client software and users do not need to enter a username and password for
network access. The device initiates a MAC authentication process when it detects an unknown
source MAC address on a MAC authentication enabled port. If the MAC address passes
authentication, the user can access authorized network resources.
Port security
Port security combines and extends 802.1X and MAC authentication to provide MAC-based network
access control. It applies to networks that require different authentication methods for different users
on a port, such as a WLAN. Port security prevents unauthorized access to a network by checking the
source MAC address of inbound traffic and prevents access to unauthorized devices by checking the
destination MAC address of outbound traffic.
Portal authentication
Portal authentication, also called "Web authentication," controls user access at the access layer and
other data entrance that needs protection. It does not require client software to authenticate users.
Users only need to enter a username and a password on the webpage for authentication.
With portal authentication, an access device redirects all unauthenticated users to a specific
webpage, and users can freely access resources on the webpage. However, to access other
resources on the Internet, a user must pass portal authentication on the portal authentication page.
Data security
Managing public keys
Public key configuration enables you to manage the local asymmetric key pairs (such as creating
and destroying a local asymmetric key pair, displaying or exporting the local host public key), and
configure the peer host public keys on the local device.
2
IPsec and IKE
IPsec is a security framework for securing IP communications. It is a Layer 3 VPN technology mainly
for data encryption and data origin authentication.
IKE provides automatic negotiation security parameters for IPsec, simplifying the configuration and
maintenance of IPsec. Security parameters for IKE negotiation include authentication and encryption
algorithms, authentication and encryption keys, IP packet encapsulation modes (tunnel mode and
transport mode), and key lifetime.
SSH
SSH is a network security protocol implementing secure remote login and file transfer over an
insecure network. Using encryption and authentication, SSH protects devices against attacks such
as IP spoofing and plaintext password interception.
Firewall and connection control
ACL based packet-filter
An ACL packet-filter implements IP packet specific filtering.
Before forwarding an IP packet, the device obtains the following header information:
•
Number of the upper layer protocol carried by the IP layer
•
Source address
•
Destination address
•
Source port number
•
Destination port number
The device compares the head information against the preset ACL rules and processes (discards or
forwards) the packet based on the comparison result.
ASPF
An ASPF implements status-based packet filtering, and provides the following functions:
•
Transport layer protocol inspection (generic TCP and UDP inspection)—ASPF checks a
TCP/UDP packet's source and destination addresses and port numbers to determine whether
to permit the packet to pass through the firewall into the internal network.
•
Application layer protocol inspection—ASPF checks application layer information for
packets, such as the protocol type and port number, and monitors the application layer protocol
status for each connection. ASPF maintains status information for each connection, and based
on status information, determines whether to permit a packet to pass through the firewall into
the internal network, thus defending the internal network against attacks.
ASPF also supports other security functions, such as port to application mapping, Java blocking,
ActiveX blocking, ICMP error message inspection and first packet inspection for TCP connection.
At the border of a network, an ASPF can work in coordination with a packet-filter firewall to provide
the network with a security policy that is more comprehensive and better meets the actual needs.
ALG
ALG processes payload information for application layer packets.
Working with NAT, ALG implements address translation in packet payloads. Working with ASPF,
ALG implements data connection detection and application layer status checking.
Session management
Session management is a common feature designed to implement session-based services such as
NAT, ASPF, and intrusion protection. Session management tracks the connection status by
inspecting the transport layer protocol (TCP or UDP) information, and regards packet exchanges at
3
transport layer as sessions, performing unified status maintenance and management of all
connections.
In actual applications, session management works together with ASPF to dynamically determine
whether a packet can pass the firewall and enter the internal network according to connection status,
thus preventing intrusion.
The session management function only implements connection status tracking. It does not block
potential attack packets.
Connection limits
To protect internal network resources (hosts or servers) and correctly allocate system resources on
the device, you can configure connection limit policies to collect statistics and limit the number of
connections, connection establishment rate, and connection bandwidth.
Attack detection and protection
ARP attack protection
Although ARP is easy to implement, it provides no security mechanism and is vulnerable to network
attacks. An attacker can exploit ARP vulnerabilities to attack network devices. Hewlett Packard
Enterprise has provided a comprehensive and effective solution against common ARP attacks, such
as user and gateway spoofing attacks and flood attacks.
ND attack defense
The IPv6 ND protocol provides rich functions, but does not provide any security mechanisms.
Attackers can easily exploit the ND protocol to attack hosts and gateways by sending forged packets.
To defend against such attacks, the device provides multiple ND attack detection technologies, such
as source MAC consistency check for ND packets and ND Detection.
IP source guard
IP source guard uses binding entries to improve port security by blocking illegal packets. For
example, it can prevent illegal hosts from using a valid IP address to access the network. It is applied
on an interface connected to the user side.
IP source guard can filter packets according to the packet source IP address, source MAC address,
and VLAN ID. An IP source guard entry can be statically configured or dynamically added through
DHCP or ND.
URPF
URPF protects a network against source address spoofing attacks, such as DoS and DDoS attacks.
Attack detection and protection
Attack detection and protection is an important network security feature. It determines whether
received packets are attack packets according to the packet contents and behaviors and, if detecting
an attack, take measures to deal with the attack, such as outputting alarm logs, dropping packets,
and blacklisting the source IP address. The attack protection function can detect network attacks
such as single-packet attacks, scanning attacks, and flood attacks.
TCP attack protection
Attackers can attack the device during the process of TCP connection establishment. To prevent
such attacks, the device provides the following features:
•
SYN Cookie
•
Protection against Naptha attacks
Web filtering
Web filtering can help devices prevent internal users from accessing unauthorized websites and
block Java applets and ActiveX objects from webpages to improve internal network security.
4
Other security technologies
The device also provides other network security technologies to implement a multifunctional and full
range of security protection for users.
User profile
A user profile provides a configuration template to save predefined configurations, such as a CAR
policy or a QoS policy. Different user profiles are applicable to different application scenarios.
The user profile supports working with PPPoE, 802.1X and portal authentications. It is capable of
restricting authenticated users' behaviors. After the authentication server verifies a user, it sends the
device the name of the user profile that is associated with the user.
Password control
Password control is a set of functions for enhancing the local password security. It controls user login
passwords, super passwords, and user login status based on predefined policies. Those policies
include minimum password length, minimum password update interval, password aging, and early
notice on pending password expiration.
RSH
RSH allows users to execute OS commands on a remote host that runs the RSH daemon. The RSH
daemon supports authentication of the privileged port on a trusted host. The device works as an
RSH client, and you can use the rsh command on the device to execute an OS command on a
remote host.
5
Configuring AAA
Overview
Authentication, Authorization, and Accounting (AAA) provides a uniform framework for implementing
network access management. It provides the following security functions:
•
Authentication—Identifies users and determines whether a user is valid.
•
Authorization—Grants user rights and controls user access to resources and services. For
example, a user who has successfully logged in to the device can be granted read and print
permissions to the files on the device.
•
Accounting—Records all network service usage information, including service type, start time,
and traffic. The accounting function allows for network security surveillance.
AAA typically uses a client/server model, as shown in Figure 1. The client runs on the network
access server (NAS), which is also called the access device. The server maintains user information
centrally. In an AAA network, the NAS is a server for users but a client for AAA servers.
Figure 1 AAA application scenario
Internet
Network
Remote user
NAS
RADIUS server
HWTACACS server
The NAS uses the authentication server to authenticate any user who tries to log in, use network
resources, or access other networks. The NAS transparently transmits authentication, authorization,
and accounting information between the user and the servers. The RADIUS and HWTACACS
protocols define how a NAS and a remote server exchange user information.
The network shown in Figure 1 comprises a RADIUS server and an HWTACACS server. You can
use different servers to implement different security functions. For example, you can use the
HWTACACS server for authentication and authorization, and the RADIUS server for accounting.
You can implement any of the three security functions provided by AAA as needed. For example, if
your company wants employees to be authenticated before they access specific resources,
configure an authentication server. If network usage information is needed, you must also configure
an accounting server.
AAA can be implemented through multiple protocols. The device supports RADIUS and HWTACACS,
of which RADIUS is most often used.
6
RADIUS
Remote Authentication Dial-In User Service (RADIUS) is a distributed information interaction
protocol that uses a client/server model. It can protect networks against unauthorized access and is
often used in network environments that require both high security and remote user access.
RADIUS uses UDP port 1812 for authentication and UDP port 1813 for accounting.
RADIUS was originally designed for dial-in user access. With the addition of new access methods,
RADIUS has been extended to support additional access methods, including Ethernet and ADSL.
RADIUS provides access authentication, authorization, and accounting services. The accounting
function collects and records network resource usage information.
Client/server model
RADIUS clients run on NASs located throughout the network. NASs pass user information to
RADIUS servers, and determine to reject or accept user access requests depending on the
responses from RADIUS servers.
The RADIUS server runs on the computer or workstation at the network center and maintains
information related to user authentication and network access. It receives connection requests,
authenticates users, and returns access control information (for example, rejecting or accepting the
user access request) to the clients.
The RADIUS server typically maintains the following databases: Users, Clients, and Dictionary.
See Figure 2.
Figure 2 RADIUS server databases
RADIUS servers
Users
Clients
Dictionary
•
Users—Stores user information, such as usernames, passwords, applied protocols, and IP
addresses.
•
Clients—Stores information about RADIUS clients, such as shared keys and IP addresses.
•
Dictionary—Stores RADIUS protocol attributes and their values.
Security and authentication mechanisms
The RADIUS client and the RADIUS server use a shared key to authenticate RADIUS packets and
encrypt user passwords exchanged between them. For security, this key must be manually
configured on the client and the server.
RADIUS servers support multiple authentication protocols, including PPP PAP and CHAP. A
RADIUS server can also act as the client of another AAA server to provide authentication proxy
services.
Basic RADIUS message exchange process
Figure 3 illustrates the interactions between the host, the RADIUS client, and the RADIUS server.
7
Figure 3 Basic RADIUS message exchange process
RADIUS operates in the following manner:
1.
The host initiates a connection request that carries the user's username and password to the
RADIUS client.
2.
Having received the username and password, the RADIUS client sends an authentication
request (Access-Request) to the RADIUS server, with the user password encrypted using the
MD5 algorithm and the shared key.
3.
The RADIUS server authenticates the username and password. If the authentication succeeds,
the server returns an Access-Accept message containing the user's authorization information.
If the authentication fails, the server returns an Access-Reject message.
4.
The RADIUS client permits or denies the user according to the returned authentication result. If
it permits the user, it sends a start-accounting request (Accounting-Request) to the RADIUS
server.
5.
The RADIUS server returns an acknowledgement (Accounting-Response) and starts
accounting.
6.
The user accesses the network resources.
7.
The host requests the RADIUS client to tear down the connection and the RADIUS client sends
a stop-accounting request (Accounting-Request) to the RADIUS server.
8.
The RADIUS server returns an acknowledgement (Accounting-Response) and stops
accounting for the user.
RADIUS packet format
RADIUS uses UDP to transmit messages. To ensure smooth message exchange between the
RADIUS server and the client, RADIUS uses a timer management mechanism, a retransmission
mechanism, and a backup server mechanism. Figure 4 shows the RADIUS packet format.
8
Figure 4 RADIUS packet format
7
0
Code
15
31
7
Length
Identifier
Authenticator
Attributes
Descriptions of the fields are as follows:
•
The Code field (1 byte long) indicates the type of the RADIUS packet.
Table 1 Main values of the Code field
Cod
e
Packet type
Description
1
Access-Request
From the client to the server. A packet of this type carries user information
for the server to authenticate the user. It must contain the User-Name
attribute and can optionally contain the attributes of NAS-IP-Address,
User-Password, and NAS-Port.
2
Access-Accept
From the server to the client. If all attribute values carried in the
Access-Request are acceptable, the authentication succeeds, and the
server sends an Access-Accept response.
3
Access-Reject
From the server to the client. If any attribute value carried in the
Access-Request is unacceptable, the authentication fails, and the server
sends an Access-Reject response.
4
Accounting-Request
From the client to the server. A packet of this type carries user information
for the server to start or stop accounting for the user. The Acct-Status-Type
attribute in the packet indicates whether to start or stop accounting.
5
Accounting-Respons
e
From the server to the client. The server sends a packet of this type to
notify the client that it has received the Accounting-Request and has
successfully recorded the accounting information.
•
The Identifier field (1 byte long) is used to match request packets and response packets and to
detect duplicate request packets. Request and response packets of the same type have the
same identifier.
•
The Length field (2 bytes long) indicates the length of the entire packet, including the Code,
Identifier, Length, Authenticator, and Attributes fields. Bytes beyond this length are considered
padding and are ignored at the receiver. If the length of a received packet is less than this length,
the packet is dropped. The value of this field is in the range 20 to 4096.
•
The Authenticator field (16 bytes long) is used to authenticate responses from the RADIUS
server and to encrypt user passwords. There are two types of authenticators: request
authenticator and response authenticator.
•
The Attributes field (variable in length) carries the specific authentication, authorization, and
accounting information that defines the configuration details of the request or response. This
field may contain multiple attributes, each with three sub-fields:
{
Type—(1 byte long) Type of the attribute. It is in the range of 1 to 255. Commonly used
RADIUS attributes are defined in RFC 2865, RFC 2866, RFC 2867, and RFC 2868. Table 2
9
shows a list of the attributes. For more information, see "Commonly used standard RADIUS
attributes."
{
Length—(1 byte long) Length of the attribute in bytes, including the Type, Length, and
Value sub-fields.
{
Value—(Up to 253 bytes) Value of the attribute. Its format and content depend on the Type
and Length sub-fields.
Table 2 Commonly used RADIUS attributes
No.
Attribute
No.
Attribute
1
User-Name
45
Acct-Authentic
2
User-Password
46
Acct-Session-Time
3
CHAP-Password
47
Acct-Input-Packets
4
NAS-IP-Address
48
Acct-Output-Packets
5
NAS-Port
49
Acct-Terminate-Cause
6
Service-Type
50
Acct-Multi-Session-Id
7
Framed-Protocol
51
Acct-Link-Count
8
Framed-IP-Address
52
Acct-Input-Gigawords
9
Framed-IP-Netmask
53
Acct-Output-Gigawords
10
Framed-Routing
54
(unassigned)
11
Filter-ID
55
Event-Timestamp
12
Framed-MTU
56-59
(unassigned)
13
Framed-Compression
60
CHAP-Challenge
14
Login-IP-Host
61
NAS-Port-Type
15
Login-Service
62
Port-Limit
16
Login-TCP-Port
63
Login-LAT-Port
17
(unassigned)
64
Tunnel-Type
18
Reply-Message
65
Tunnel-Medium-Type
19
Callback-Number
66
Tunnel-Client-Endpoint
20
Callback-ID
67
Tunnel-Server-Endpoint
21
(unassigned)
68
Acct-Tunnel-Connection
22
Framed-Route
69
Tunnel-Password
23
Framed-IPX-Network
70
ARAP-Password
24
State
71
ARAP-Features
25
Class
72
ARAP-Zone-Access
26
Vendor-Specific
73
ARAP-Security
27
Session-Timeout
74
ARAP-Security-Data
28
Idle-Timeout
75
Password-Retry
29
Termination-Action
76
Prompt
30
Called-Station-Id
77
Connect-Info
31
Calling-Station-Id
78
Configuration-Token
10
No.
Attribute
No.
Attribute
32
NAS-Identifier
79
EAP-Message
33
Proxy-State
80
Message-Authenticator
34
Login-LAT-Service
81
Tunnel-Private-Group-id
35
Login-LAT-Node
82
Tunnel-Assignment-id
36
Login-LAT-Group
83
Tunnel-Preference
37
Framed-AppleTalk-Link
84
ARAP-Challenge-Response
38
Framed-AppleTalk-Network
85
Acct-Interim-Interval
39
Framed-AppleTalk-Zone
86
Acct-Tunnel-Packets-Lost
40
Acct-Status-Type
87
NAS-Port-Id
41
Acct-Delay-Time
88
Framed-Pool
42
Acct-Input-Octets
89
(unassigned)
43
Acct-Output-Octets
90
Tunnel-Client-Auth-id
44
Acct-Session-Id
91
Tunnel-Server-Auth-id
Extended RADIUS attributes
Attribute 26 (Vendor-Specific), an attribute defined in RFC 2865, allows a vendor to define extended
attributes to implement functions that the standard RADIUS protocol does not provide.
A vendor can encapsulate multiple sub-attributes as TLVs in attribute 26 to provide extended
functions. As shown in Figure 5, a sub-attribute encapsulated in attribute 26 consists of the following
parts:
•
Vendor-ID—ID of the vendor. Its most significant byte is 0. The other three bytes contains a
code that is compliant to RFC 1700. The vendor ID of Hewlett Packard Enterprise is 25506. For
more information about the proprietary RADIUS sub-attributes of Hewlett Packard Enterprise,
see "Proprietary RADIUS sub-attributes of Hewlett Packard Enterprise."
•
Vendor-Type—Type of the sub-attribute.
•
Vendor-Length—Length of the sub-attribute.
•
Vendor-Data—Contents of the sub-attribute.
Figure 5 Format of attribute 26
HWTACACS
HW Terminal Access Controller Access Control System (HWTACACS) is an enhanced security
protocol based on TACACS (RFC 1492). Similar to RADIUS, it uses a client/server model for
information exchange between the NAS and the HWTACACS server.
11
HWTACACS typically provides AAA services for PPP, VPDN, and terminal users. In a typical
HWTACACS scenario, some terminal users need to log in to the NAS for operations. Working as the
HWTACACS client, the NAS sends users' usernames and passwords to the HWTACACS sever for
authentication. After passing authentication and getting authorized rights, a user logs in to the device
and performs operations. The HWTACACS server records the operations that each user performs.
Differences between HWTACACS and RADIUS
HWTACACS and RADIUS have many features in common, such as using a client/server model,
using shared keys for user information security, and providing flexibility and extensibility. Table 3 lists
the primary differences.
Table 3 Primary differences between HWTACACS and RADIUS
HWTACACS
RADIUS
Uses TCP, providing more reliable network
transmission.
Uses UDP, providing higher transport efficiency.
Encrypts the entire packet except for the
HWTACACS header.
Encrypts only the user password field in an
authentication packet.
Protocol packets are complicated and authorization
is independent of authentication. Authentication and
authorization can be deployed on different
HWTACACS servers.
Protocol packets are simple and the authorization
process is combined with the authentication
process.
Supports authorization of configuration commands.
Commands a user can access depend on both the
user level and AAA authorization. A user can use
only commands that are at, or lower than, the user
level and authorized by the HWTACACS server.
Does not support authorization of configuration
commands. Commands a user can access solely
depend on the level of the user. A user can use all
the commands at, or lower than, the user level.
Basic HWTACACS message exchange process
The following example describes how HWTACACS performs user authentication, authorization, and
accounting for a Telnet user.
12
Figure 6 Basic HWTACACS message exchange process for a Telnet user
HWTACACS operates in the following manner:
1.
A Telnet user sends an access request to the HWTACACS client.
2.
Upon receiving the request, the HWTACACS client sends a start-authentication packet to the
HWTACACS server.
3.
The HWTACACS server sends back an authentication response to request the username.
4.
Upon receiving the response, the HWTACACS client asks the user for the username.
5.
The user enters the username.
6.
After receiving the username from the user, the HWTACACS client sends the server a
continue-authentication packet that carries the username.
7.
The HWTACACS server sends back an authentication response, requesting the login
password.
8.
Upon receipt of the response, the HWTACACS client asks the user for the login password.
13
9.
The user enters the password.
10. After receiving the login password, the HWTACACS client sends the HWTACACS server a
continue-authentication packet that carries the login password.
11. The HWTACACS server sends back an authentication response to indicate that the user has
passed authentication.
12. The HWTACACS client sends the user authorization request packet to the HWTACACS server.
13. The HWTACACS server sends back the authorization response, indicating that the user is now
authorized.
14. Knowing that the user is now authorized, the HWTACACS client pushes its CLI to the user.
15. The HWTACACS client sends a start-accounting request to the HWTACACS server.
16. The HWTACACS server sends back an accounting response, indicating that it has received the
start-accounting request.
17. The user logs off.
18. The HWTACACS client sends a stop-accounting request to the HWTACACS server.
19. The HWTACACS server sends back a stop-accounting response, indicating that the
stop-accounting request has been received.
Domain-based user management
A NAS manages users based on ISP domains. On a NAS, each user belongs to one ISP domain. A
NAS determines the ISP domain for a user by the username entered by the user at login, as shown
in Figure 7.
Figure 7 Determining the ISP domain of a user by the username
Authentication, authorization, and accounting of a user depends on the AAA methods configured for
the domain that the user belongs to. If no specific AAA methods are configured for the domain, the
default methods are used. By default, a domain uses local authentication, local authorization, and
local accounting.
AAA allows you to manage users based on their access types:
•
LAN users—Users on a LAN who must pass 802.1X or MAC address authentication to access
the network.
•
Login users—Users who want to log in to the device, including SSH users, Telnet users, FTP
users, and terminal users.
•
DVPN users—Users who access through DVPN.
•
Portal users—Users who must pass portal authentication to access the network.
•
PPP users—Users who access through PPP.
In addition, AAA provides the following services for login users to enhance device security:
14
•
Command authorization—Enables the NAS to defer to the authorization server to determine
whether a command entered by a login user is permitted, and allows login users to execute only
authorized commands. For more information about command authorization, see Fundamentals
Configuration Guide.
•
Command accounting—Allows the accounting server to record all commands executed on
the device or all authorized commands successfully executed. For more information about
command accounting, see Fundamentals Configuration Guide.
•
Level switching authentication—Allows the authentication server to authenticate users who
perform privilege level switching. As long as passing level switching authentication, users can
switch their user privilege levels, without logging out and disconnecting current connections.
For more information about user privilege level switching, see Fundamentals Configuration
Guide.
You can configure different AAA methods for different types of users in a domain. See "Configuring
AAA methods for ISP domains."
AAA for MPLS L3VPNs
In an MPLS L3VPN scenario where clients in different VPNs are centrally authenticated, you can
deploy AAA across VPNs to enable forwarding of RADIUS and HWTACACS packets across MPLS
VPNs. With this feature, the PE at the left side of the MPLS backbone serves as a NAS and
transparently delivers the AAA packets of private users in VPN 1 and VPN 2 to the AAA servers in
VPN 3 for centralized authentication, as shown in Figure 8. Authentication packets of private users in
different VPNs do not affect each other.
Figure 8 Network diagram
This feature can help a multi-VPN-instance CE to implement portal authentication for VPNs. For
more information about multi-VPN-instance CEs, see MPLS Configuration Guide. For more
information about portal authentication, see "Configuring portal."
Protocols and standards
The following protocols and standards are related to AAA, RADIUS, and HWTACACS:
•
RFC 2865, Remote Authentication Dial In User Service (RADIUS)
•
RFC 2866, RADIUS Accounting
•
RFC 2867, RADIUS Accounting Modifications for Tunnel Protocol Support
•
RFC 2868, RADIUS Attributes for Tunnel Protocol Support
•
RFC 2869, RADIUS Extensions
•
RFC 1492, An Access Control Protocol, Sometimes Called TACACS
15
RADIUS attributes
This section provides tables of commonly used standard RADIUS attributes and proprietary RADIUS
sub-attributes of Hewlett Packard Enterprise.
Commonly used standard RADIUS attributes
No.
Attribute
Description
1
User-Name
Name of the user to be authenticated.
2
User-Password
User password for PAP authentication, only present in Access-Request
packets when PAP authentication is used.
3
CHAP-Password
Digest of the user password for CHAP authentication, only present in
Access-Request packets when CHAP authentication is used.
4
NAS-IP-Address
IP address for the server to use to identify a client. Usually, a client is
identified by the IP address of its access interface. This attribute is only
present in Access-Request packets.
5
NAS-Port
Physical port of the NAS that the user accesses.
6
Service-Type
Type of service that the user has requested or type of service to be
provided.
7
Framed-Protocol
Encapsulation protocol for framed access.
8
Framed-IP-Address
IP address assigned to the user.
11
Filter-ID
Name of the filter list.
12
Framed-MTU
MTU for the data link between the user and NAS. For example, with
802.1X EAP authentication, NAS uses this attribute to notify the server of
the MTU for EAP packets, so as to avoid oversized EAP packets.
14
Login-IP-Host
IP address of the NAS interface that the user accesses.
15
Login-Service
Type of the service that the user uses for login.
18
Reply-Message
Text to be displayed to the user, which can be used by the server to
indicate, for example, the reason of the authentication failure.
26
Vendor-Specific
Vendor specific attribute. A packet can contain one or more such
proprietary attributes, each of which can contain one or more
sub-attributes.
27
Session-Timeout
Maximum service duration for the user before termination of the session.
28
Idle-Timeout
Maximum idle time permitted for the user before termination of the session.
31
Calling-Station-Id
User identification that the NAS sends to the server. For the LAN access
service provided by an HPE device, this attribute carries the MAC address
of the user in the format HHHH-HHHH-HHHH.
32
NAS-Identifier
Identification that the NAS uses to identify itself to the RADIUS server.
16
No.
Attribute
Description
Acct-Status-Type
Type of the Accounting-Request packet. Possible values include:
•
1—Start.
•
2—Stop.
•
3—Interim-Update.
•
7—Accounting-On. (Defined in the 3rd Generation Partnership
Project.)
•
8—Accounting-Off. (Defined in the 3rd Generation Partnership
Project.)
•
9 to 14—Reserved for tunnel accounting.
•
15—Reserved for failed.
45
Acct-Authentic
Authentication method used by the user. Possible values include:
•
1—RADIUS.
•
2—Local.
•
3—Remote.
60
CHAP-Challenge
CHAP challenge generated by the NAS for MD5 calculation during CHAP
authentication.
40
61
NAS-Port-Type
Type of the physical port of the NAS that is authenticating the user.
Possible values include:
•
15—Ethernet.
•
16—Any type of ADSL.
•
17—Cable (with cable for cable TV).
•
19—WLAN-IEEE 802.11.
•
201—VLAN.
•
202—ATM.
If the port is an ATM or Ethernet one and VLANs are implemented on it, the
value of this attribute is 201.
79
EAP-Message
Used to encapsulate EAP packets to allow RADIUS to support EAP
authentication.
80
Message-Authenticato
r
Used for authentication and verification of authentication packets to
prevent spoofing Access-Requests. This attribute is present when EAP
authentication is used.
87
NAS-Port-Id
String for describing the port of the NAS that is authenticating the user.
Proprietary RADIUS sub-attributes of Hewlett Packard Enterprise
No.
Sub-attribute
Description
1
Input-Peak-Rate
Peak rate in the direction from the user to the NAS, in bps.
2
Input-Average-Rate
Average rate in the direction from the user to the NAS, in bps.
3
Input-Basic-Rate
Basic rate in the direction from the user to the NAS, in bps.
4
Output-Peak-Rate
Peak rate in the direction from the NAS to the user, in bps.
5
Output-Average-Rate
Average rate in the direction from the NAS to the user, in bps.
6
Output-Basic-Rate
Basic rate in the direction from the NAS to the user, in bps.
15
Remanent_Volume
Total remaining available traffic for the connection, in different units for
different server types.
17
No.
20
24
Sub-attribute
Description
Command
Operation for the session, used for session control. Possible values
include:
•
1—Trigger-Request.
•
2—Terminate-Request.
•
3—SetPolicy.
•
4—Result.
•
5—PortalClear.
Control_Identifier
Identification for retransmitted packets. For retransmitted packets of the
same session, this attribute must take the same value. For retransmitted
packets of different sessions, this attribute may take the same value.
The client response of a retransmitted packet must also carry this
attribute and the value of this attribute must be the same.
For Accounting-Request packets of the start, stop, and interim update
types, the Control-Identifier attribute does not take effect.
25
Result_Code
Result of the Trigger-Request or SetPolicy operation, zero for success
and any other value for failure.
26
Connect_ID
Index of the user connection.
28
Ftp_Directory
FTP user working directory. When the RADIUS client acts as the FTP
server, this attribute is used to set the FTP directory for an FTP user on
the RADIUS client.
29
Exec_Privilege
EXEC user priority.
59
NAS_Startup_Timestamp
Startup time of the NAS in seconds, which is represented by the time
elapsed after 00:00:00 on Jan. 1, 1970 (UTC).
60
Ip_Host_Addr
User IP address and MAC address carried in authentication and
accounting requests, in the format A.B.C.D hh:hh:hh:hh:hh:hh. A space
is required between the IP address and the MAC address.
61
User_Notify
Information that must be sent from the server to the client transparently.
62
User_HeartBeat
Hash value assigned after an 802.1X user passes authentication, which
is a 32-byte string. This attribute is stored in the user list on the NAS and
is used for verifying the handshake messages from the 802.1X user.
This attribute only exists in Access-Accept and Accounting-Request
packets.
201
Input-Interval-Octets
Number of bytes input within a real-time accounting interval.
202
Output-Interval-Octets
Number of bytes output within a real-time accounting interval.
203
Input-Interval-Packets
Number of packets input within an accounting interval, in the unit set on
the NAS.
204
Output-Interval-Packets
Number of packets output within an accounting interval, in the unit set
on the NAS.
205
Input-Interval-Gigawords
Amount of bytes input within an accounting interval, in units of 4G bytes.
206
Output-Interval-Gigaword
s
Amount of bytes output within an accounting interval, in units of 4G
bytes.
207
Backup-NAS-IP
Backup source IP address for sending RADIUS packets.
255
Product_ID
Product name.
18
AAA configuration considerations and task list
To configure AAA on the NAS:
1.
2.
Configure the required AAA schemes.
{
Local authentication—Configure local users and the related attributes, including the
usernames and passwords for the users to be authenticated.
{
Remote authentication—Configure the required RADIUS and HWTACACS schemes. You
must configure user attributes on the servers accordingly.
Configure AAA methods for the ISP domain.
{
Authentication method—No authentication (none), local authentication (local), or remote
authentication (scheme)
{
Authorization method—No authorization (none), local authorization (local), or remote
authorization (scheme)
{
Accounting method—No accounting (none), local accounting (local), or remote
accounting (scheme)
See Figure 9 for the configuration procedure.
Figure 9 AAA configuration procedure
Local AAA
Configure local users and related
attributes
Configure AAA methods for
different types of users or/and
the default methods for all
types of users
Authentication method
none/ local (the default)/ scheme
Create an ISP domain
and enter its view
No AAA
+
Authorization method
none/ local (the default)/ scheme
+
Configure the RADIUS or
HWTACACS schemes to be
referenced
Accounting method
none/ local (the default)/ scheme
Remote AAA
Table 4 AAA configuration task list
Task
Remarks
Configuring local users
Configuring AAA
schemes
Configuring RADIUS schemes
Configuring HWTACACS schemes
Configuring AAA
methods for ISP
domains
Required.
Complete at least
one task.
Creating an ISP domain
Required.
Configuring ISP domain attributes
Optional.
Configuring authentication methods for an ISP domain
Configuring authorization methods for an ISP domain
Configuring accounting methods for an ISP domain
Tearing down user connections
Required.
Complete at least
one task.
Optional.
19
Task
Remarks
Configuring a NAS ID-VLAN binding
Optional.
NOTE:
To use AAA methods to control access of login users, you must configure the user interfaces to use
AAA by using the authentication-mode command. For more information, see Fundamentals
Configuration Guide.
Configuring AAA schemes
Configuring local users
To implement local AAA, you must create local users and configure user attributes on the device.
The local users and attributes are stored in the local user database on the device. A local user is
uniquely identified by a username. Configurable local user attributes are as follows:
•
Service type.
Services that the user can use. Local authentication checks the service types of a local user. If
none of the service types is available, the user cannot pass authentication.
Service types include DVPN, FTP, LAN access, portal, PPP, SSH, Telnet, and terminal.
•
User state.
Indicates whether or not a local user can request network services. There are two user states:
active and blocked. A user in active state can request network services, but a user in blocked
state cannot.
•
Maximum number of users using the same local user account:
Indicates how many users can use the same local user account for local authentication.
•
Validity time and expiration time.
Indicates the validity time and expiration time of a local user account. A user must use a valid
local user account to pass local authentication. When some users need to access the network
temporarily, you can create a guest account and specify a validity time and an expiration time
for the account to control the validity of the account.
•
User group.
Each local user belongs to a local user group and bears all attributes of the group, such as the
password control attributes and authorization attributes. For more information about local user
group, see "Configuring user group attributes."
•
Password control attributes.
Password control attributes help you control the security of local users' passwords. Password
control attributes include password aging time, minimum password length, and password
composition policy.
You can configure a password control attribute in system view, user group view, or local user
view, making the attribute effective for all local users, all local users in a group, or only the local
user. A password control attribute with a smaller effective range has a higher priority. For more
information about password management and global password configuration, see "Configuring
password control." For more information about password control commands, see Security
Command Reference.
•
Binding attributes.
Binding attributes are used for controlling the scope of users. They are checked during local
authentication of a user. If the attributes of a user do not match the binding attributes configured
20
for the local user account, the user cannot pass authentication. Binding attributes include the
ISDN calling number, IP address, access port, MAC address, and native VLAN.
•
Authorization attributes.
Authorization attributes indicate the rights that a user has after passing local authentication.
Authorization attributes include the ACL, PPP callback number, idle cut function, user level,
user role, user profile, VLAN, and FTP/SFTP work directory. For more information about
authorization attributes, see "Configuring local user attributes."
Every configurable authorization attribute has its definite application environments and
purposes. When you configure authorization attributes for a local user, consider which
attributes are needed and which are not. For example, for PPP users, you do not need to
configure the work directory attribute.
You can configure an authorization attribute in user group view or local user view to make the
attribute effective for all local users in the group or for only the local user. The setting of an
authorization attribute in local user view takes precedence over that in user group view.
Local user configuration task list
Task
Remarks
Configuring local user attributes
Required.
Configuring user group attributes
Optional.
Displaying and maintaining local users and local user groups
Optional.
Configuring local user attributes
Follow these guidelines when you configure local user attributes:
•
When the password control feature is enabled globally by using the password-control enable
command, local user passwords are not displayed. and the password hash cipher command
does not take effect.
•
If the user interface authentication mode set by the authentication-mode command in user
interface view is AAA (scheme), which commands a login user can use after login depends on
the privilege level authorized to the user. If the user interface authentication mode is password
(password) or no authentication (none), which commands a login user can use after login
depends on the level configured for the user interface by using the user privilege level
command in user interface view. For an SSH user using public key authentication, which
commands are available depends on the level configured for the user interface. For more
information about user interface authentication mode and user interface command level, see
Fundamentals Configuration Guide.
•
You can configure the user profile authorization attribute in local user view, user group view, and
ISP domain view. The setting in local user view has the highest priority, and that in ISP domain
view has the lowest priority. For more information about user profiles, see "Configuring user
profiles."
•
You cannot delete a local user who is the only security log manager in the system, nor can you
change or delete the security log manager role of the user. To do so, you must specify a new
security log manager first.
To configure local user attributes:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Add a local user and
enter local user view.
local-user user-name
By default, no local user exists.
21
Step
Command
Remarks
Optional.
3.
Configure a password for
the local user.
password [[ hash ] { cipher |
simple } password ]
A local user with no password
configured directly passes
authentication after providing the valid
local username and attributes. To
enhance security, configure a
password for each local user.
This command is not supported in
FIPS mode. To configure a local user
password in FIPS mode, use the
password-control command.
By default, no service is authorized to
a local user.
4.
Assign service types for
the local user.
service-type { dvpn | ftp |
lan-access | { ssh | telnet |
terminal } * | portal | ppp }
The lan-access keyword is supported
only on SAP interface modules that
are operating in Layer 2 mode.
The ftp and telnet keywords are not
supported in FIPS mode.
Optional.
5.
Place the local user to the
active or blocked state.
state { active | block }
By default, a created local user is in
active state and can request network
services.
Optional.
6.
Set the maximum number
of concurrent users of the
local user account.
access-limit max-user-number
By default, there is no limit to the
maximum number of concurrent users
of a local user account.
The limit is effective only for local
accounting, and is not effective for
FTP users.
Optional.
•
•
7.
Configure password
control attributes for the
local user.
•
Set the password aging
time:
password-control aging
aging-time
Set the minimum password
length:
password-control length
length
Configure the password
composition policy:
password-control
composition type-number
type-number [ type-length
type-length ]
By default, the local user uses
password control attributes of the user
group to which the local user belongs,
and uses the global setting for any
password control attribute that is not
configured in the user group. The
global settings include a 90-day
password aging time, a minimum
password length of 10 characters, and
at least one password composition
type and at least one character
required for each password
composition type.
The minimum password length is 8
characters.
In FIPS mode, the value of the
type-number argument must be 4.
8.
Configure binding
attributes for the local
user.
bind-attribute { call-number
call-number [ : subcall-number ] |
ip ip-address | location port
slot-number subslot-number
port-number | mac mac-address
| vlan vlan-id } *
22
Optional.
By default, no binding attribute is
configured for a local user.
Step
Command
Remarks
Optional.
By default, no authorization attribute
is configured for a local user.
9.
Configure authorization
attributes for the local
user.
authorization-attribute { acl
acl-number | callback-number
callback-number | idle-cut
minute | level level | user-profile
profile-name | user-role { guest |
guest-manager |
security-audit } | vlan vlan-id |
work-directory directory-name }
*
For PPP users, only acl,
callback-number, idle-cut, and
user-profile are supported.
For LAN and portal users, only acl,
idle-cut, user-profile, and vlan are
supported.
For SSH and terminal users, only
level is supported.
For FTP users, only level and
work-directory are supported.
For Telnet users, only level and
user-role is supported.
For other types of local users, no
authorization attribute is supported.
10. Set the validity time of the
local user.
validity-date time
11. Set the expiration time of
the local user.
expiration-date time
12. Assign the local user to a
user group.
group group-name
Optional.
Not set by default.
Optional.
Not set by default.
Optional.
By default, a local user belongs to the
default user group system.
Configuring user group attributes
User groups simplify local user configuration and management. A user group comprises a group of
local users and has a set of local user attributes. You can configure local user attributes for a user
group to implement centralized user attributes management for the local users in the group.
Configurable user attributes include password control attributes and authorization attributes.
By default, every newly added local user belongs to the default user group system and bears all
attributes of the group. To assign a local user to a different user group, use the user-group
command in local user view.
To configure attributes for a user group:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a user group and
enter user group view.
user-group group-name
N/A
23
Step
Command
Remarks
Optional.
•
•
3.
Configure password control
attributes for the user group.
•
Set the password aging time:
password-control aging
aging-time
Set the minimum password
length:
password-control length
length
Configure the password
composition policy:
password-control
composition type-number
type-number [ type-length
type-length ]
authorization-attribute { acl
acl-number | callback-number
4.
Configure authorization
attributes for the user group.
5.
Set the guest attribute for the
user group.
callback-number | idle-cut minute
| level level | user-profile
profile-name | vlan vlan-id |
work-directory directory-name }
*
By default, the user group uses
global settings, including a 90-day
password aging time, a minimum
password length of 10 characters,
and at least one password
composition type and at least one
character required for each
password composition type.
The minimum password length is
8 characters.
In FIPS mode, the value of the
type-number argument must be 4.
For more information about
password control attribute
commands, see Security
Command Reference.
Optional.
By default, no authorization
attribute is configured for a user
group.
Optional.
group-attribute allow-guest
By default, the guest attribute is
not set for a user group.
Displaying and maintaining local users and local user groups
Task
Command
Remarks
Display local user
information (in standalone
mode).
display local-user [ idle-cut { disable | enable } |
service-type { dvpn | ftp | lan-access | portal | ppp | ssh
| telnet | terminal } | state { active | block } | user-name
user-name | vlan vlan-id ] [ slot slot-number ] [ | { begin |
exclude | include } regular-expression ]
Display local user
information (in IRF mode).
display local-user [ idle-cut { disable | enable } |
service-type { dvpn | ftp | lan-access | portal | ppp | ssh
| telnet | terminal } | state { active | block } | user-name
user-name | vlan vlan-id ] [ chassis chassis-number slot
slot-number ] [ | { begin | exclude | include }
regular-expression ]
Display the user group
configuration.
display user-group [ group-name ] [ | { begin | exclude |
include } regular-expression ]
Available in any
view.
The ftp and
telnet keywords
are not
supported in
FIPS mode.
Available in any
view.
The ftp and
telnet keywords
are not
supported in
FIPS mode.
Available in any
view.
Configuring RADIUS schemes
A RADIUS scheme specifies the RADIUS servers that the device can cooperate with and defines a
set of parameters that the device uses to exchange information with the RADIUS servers. There
24
might be authentication/authorization servers and accounting servers, or primary servers and
secondary servers. The parameters include the IP addresses of the servers, the shared keys, and
the RADIUS server type.
RADIUS scheme configuration task list
Task
Remarks
Creating a RADIUS scheme
Required.
Specifying the RADIUS authentication/authorization servers
Required.
Specifying the RADIUS accounting servers and the relevant parameters
Optional.
Specifying the shared keys for secure RADIUS communication
Optional.
Specifying a VPN for the RADIUS scheme
Optional.
Setting the username format and traffic statistics units
Optional.
Setting the supported RADIUS server type
Optional.
Setting the maximum number of RADIUS request transmission attempts
Optional.
Setting the status of RADIUS servers
Optional.
Specifying the source IP address for outgoing RADIUS packets
Optional.
Setting RADIUS timers
Optional.
Configuring RADIUS accounting-on
Optional.
Configuring the IP address of the security policy server
Optional.
Configuring interpretation of the RADIUS class attribute as CAR parameters
Optional.
Enabling the trap function for RADIUS
Optional.
Enabling the RADIUS client service
Optional.
Displaying and maintaining RADIUS
Optional.
Creating a RADIUS scheme
Before you perform other RADIUS configurations, first create a RADIUS scheme and enter RADIUS
scheme view. A RADIUS scheme can be referenced by multiple ISP domains at the same time.
To create a RADIUS scheme and enter RADIUS scheme view:
Step
Command
Remarks
6.
Enter system view.
system-view
N/A
7.
Create a RADIUS scheme
and enter RADIUS scheme
view.
radius scheme
radius-scheme-name
By default, no RADIUS scheme is
created.
Specifying the RADIUS authentication/authorization servers
In RADIUS, user authorization information is piggybacked in authentication responses sent to
RADIUS clients. It is neither allowed nor needed to specify a separate RADIUS authorization server.
You can specify one primary authentication/authorization server and up to 16 secondary
authentication/authorization servers for a RADIUS scheme. When the primary server is not available,
a secondary server is used. In a scenario where redundancy is not required, specify only the primary
server.
25
A
RADIUS
authentication/authorization
server
can
function
as
the
primary
authentication/authorization server for one scheme and a secondary authentication/authorization
server for another scheme at the same time.
You can enable the server status detection feature. With the feature, the device periodically sends an
authentication request to check whether or not the target RADIUS authentication/authorization
server is reachable. If the server can be reached, the device sets the status of the server to active. If
the server cannot be reached, the device sets the status of the server to block. This feature can
promptly notify authentication modules of latest server status information. For example, server status
detection can work with the 802.1X critical VLAN feature, so that the device can trigger 802.1X
authentication for users in the critical VLAN immediately on detection of a reachable RADIUS
authentication/authorization server.
To specify RADIUS authentication/authorization servers for a RADIUS scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme view.
radius scheme radius-scheme-name
N/A
Configure at least one
command.
•
3.
Specify RADIUS
authentication/authorization
servers.
•
Specify the primary RADIUS
authentication/authorization
server:
primary authentication
{ ip-address | ipv6 ipv6-address }
[ port-number | key [ cipher |
simple ] key | probe username
name [ interval interval ] |
vpn-instance
vpn-instance-name ] *
Specify a secondary RADIUS
authentication/authorization
server:
secondary authentication
{ ip-address | ipv6 ipv6-address }
[ port-number | key [ cipher |
simple ] key | probe username
name [ interval interval ] |
vpn-instance
vpn-instance-name ] *
By default, no
authentication/authorization
server is specified.
In FIPS mode, the shared
key must be a string of at
least 8 characters that
contain numbers, uppercase
letters, lowercase letters,
and special characters, and
is encrypted and decrypted
by using 3DES.
The IP addresses of the
primary and secondary
authentication/authorization
servers for a scheme must
be different. Otherwise, the
configuration will fail.
All servers for
authentication/authorization
and accounting, primary or
secondary, must use IP
addresses of the same IP
version.
Specifying the RADIUS accounting servers and the relevant parameters
You can specify one primary accounting server and up to 16 secondary accounting servers for a
RADIUS scheme. When the primary server is not available, a secondary server is used. When
redundancy is not required, specify only the primary server. A RADIUS accounting server can
function as the primary accounting server for one scheme and a secondary accounting server for
another scheme at the same time.
When the device receives a connection teardown request from a host or a connection teardown
command from an administrator, it sends a stop-accounting request to the accounting server. When
the maximum number of real-time accounting attempts is reached, the device disconnects users
who have no accounting responses. You can enable buffering of non-responded stop-accounting
requests to allow the device to buffer and resend a stop-accounting request until it receives a
response. If the number of stop-accounting attempts reaches the upper limit, the device discards the
buffered request.
26
If you delete an accounting server that is serving users, the device no longer sends real-time
accounting requests or stop-accounting requests for the users to that server, or buffers the
stop-accounting requests.
RADIUS does not support accounting for FTP users.
To specify RADIUS accounting servers and set relevant parameters for a scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme view.
radius scheme
radius-scheme-name
N/A
Configure at least one command.
•
3.
4.
5.
6.
Specify RADIUS accounting
servers.
•
Specify the primary RADIUS
accounting server:
primary accounting
{ ip-address | ipv6
ipv6-address } [ port-number
| key [ cipher | simple ] key |
vpn-instance
vpn-instance-name ] *
Specify a secondary
RADIUS accounting server:
secondary accounting
{ ip-address | ipv6
ipv6-address } [ port-number
| key [ cipher | simple ] key |
vpn-instance
vpn-instance-name ] *
Set the maximum number of
real-time accounting
attempts.
retry realtime-accounting
retry-times
Enable buffering of
stop-accounting requests to
which no responses are
received.
stop-accounting-buffer enable
Set the maximum number of
stop-accounting attempts.
retry stop-accounting
retry-times
No accounting server is specified
by default.
In FIPS mode, the shared key
must be a string of at least 8
characters that contain numbers,
uppercase letters, lowercase
letters, and special characters,
and is encrypted and decrypted
by using 3DES.
The IP addresses of the primary
and secondary accounting
servers must be different from
each other. Otherwise, the
configuration fails.
All servers for
authentication/authorization and
accounting, primary or secondary,
must use IP addresses of the
same IP version.
Optional.
The default setting is 5.
Optional.
Enabled by default.
Optional.
The default setting is 500.
Specifying the shared keys for secure RADIUS communication
The RADIUS client and RADIUS server use the MD5 algorithm and a shared key pair for packet
authentication and password encryption in a certain type of communication.
A shared key configured in RADIUS scheme view applies to all servers of the specified type
(accounting or authentication) in that scheme, and has a lower priority than those configured for
individual RADIUS servers.
To specify a shared key for secure RADIUS communication:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme view.
radius scheme
radius-scheme-name
N/A
27
Step
Command
Remarks
By default, no shared key is
specified.
3.
Specify a shared key for
secure RADIUS
authentication/authorization
or accounting
communication.
key { accounting |
authentication } [ cipher |
simple ] key
In FIPS mode, the shared key
must be a string of at least 8
characters that contain numbers,
uppercase letters, lowercase
letters, and special characters.
The shared key configured on the
device must be the same as that
configured on the RADIUS server.
Specifying a VPN for the RADIUS scheme
You can specify a VPN for all the AAA servers in a RADIUS scheme. However, the VPN has a lower
priority than those configured for individual RADIUS servers.
To specify a VPN for a RADIUS scheme:
Step
Command
1.
Enter system view.
system-view
2.
Enter RADIUS scheme view.
radius scheme radius-scheme-name
3.
Specify a VPN for the RADIUS scheme.
vpn-instance vpn-instance-name
Setting the username format and traffic statistics units
A username is usually in the format userid@isp-name, where isp-name represents the user's ISP
domain name. By default, the ISP domain name is included in a username; however, some earlier
RADIUS servers do not recognize usernames that contain the ISP domain names. In this case, you
can configure the device to remove the domain name from each username to be sent.
The device periodically sends accounting updates to RADIUS accounting servers to report the traffic
statistics of online users. For normal and accurate traffic statistics, make sure that the unit for data
flows and that for packets on the device are consistent with those on the RADIUS server.
To set the username format and the traffic statistics units for a RADIUS scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme view.
radius scheme
radius-scheme-name
N/A
3.
Set the format for
usernames sent to the
RADIUS servers.
user-name-format { keep-original
| with-domain | without-domain }
Specify the unit for data
flows or packets sent to the
RADIUS servers.
data-flow-format { data { byte |
giga-byte | kilo-byte |
mega-byte } | packet
{ giga-packet | kilo-packet |
mega-packet | one-packet } }*
4.
Optional.
By default, the ISP domain
name is included in a username.
Optional.
The default unit is byte for data
flows and one-packet for data
packets.
Do not apply the RADIUS scheme to more than one ISP domain if you have configured the
user-name-format without-domain command for that RADIUS scheme. Otherwise, users in
different ISP domains are considered the same user if they use the same username.
28
For level switching authentication, user-name-format keep-original and user-name-format
without-domain commands all produce the same results: they make sure that usernames sent to
the RADIUS server carry no ISP domain name.
Setting the supported RADIUS server type
The supported RADIUS server type determines the type of the RADIUS protocol that the device uses
to communicate with the RADIUS server. It can be standard or extended:
•
Standard—Uses the standard RADIUS protocol, compliant to RFC 2865 and RFC 2866 or
later.
•
Extended—Uses the proprietary RADIUS protocol of Hewlett Packard Enterprise.
When the RADIUS server runs on IMC, you must set the RADIUS server type to extended. When
the RADIUS server runs third-party RADIUS server software, either RADIUS server type applies. For
the device to function as a RADIUS server to authenticate login users, you must set the RADIUS
server type to standard.
To set the RADIUS server type:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme view.
radius scheme
radius-scheme-name
N/A
3.
Set the RADIUS server type.
server-type { extended | standard }
Optional.
The default RADIUS server
type is standard.
NOTE:
Changing the RADIUS server type will restore the unit for data flows and that for packets that are
sent to the RADIUS server to the defaults.
Setting the maximum number of RADIUS request transmission attempts
RADIUS uses UDP packets to transfer data. UDP communication is not reliable. To improve
reliability, RADIUS uses a retransmission mechanism. If a NAS sends a RADIUS request to a
RADIUS server but receives no response before the response timeout timer (defined by the timer
response-timeout command) expires, it retransmits the request. If the number of transmission
attempts exceeds the specified limit but it still receives no response, it tries to communicate with
other RADIUS servers in active state. If no other servers are in active state at the time, it considers
the authentication or accounting attempt a failure. For more information about RADIUS server states,
see "Setting the status of RADIUS servers."
The maximum number of transmission attempts of RADIUS packets multiplied by the RADIUS
server response timeout period cannot be greater than 75 seconds. For more information about the
RADIUS server response timeout timer, see "Setting RADIUS timers."
To set the maximum number of RADIUS request transmission attempts for a scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme view.
radius scheme
radius-scheme-name
N/A
3.
Set the maximum number of
RADIUS request transmission
attempts.
retry retry-times
29
Optional.
The default setting is 3.
Setting the status of RADIUS servers
By setting the status of RADIUS servers to blocked or active, you can control the AAA servers with
which the device communicates when the current servers are no longer available. In practice, you
can specify one primary RADIUS server and multiple secondary RADIUS servers, with the
secondary servers functioning as the backup of the primary servers. Typically, the device chooses
servers based on these rules:
•
When the primary server is in active state, the device communicates with the primary server.
If the primary server fails, the device changes the server's status to blocked, starts a quiet timer
for the server, and tries to communicate with a secondary server in active state (a secondary
server configured earlier has a higher priority).
If the secondary server is unreachable, the device changes the server's status to blocked, starts
a quiet timer for the server, and continues to check the next secondary server in active state.
This search process continues until the device finds an available secondary server or has
checked all secondary servers in active state.
If the quiet timer of a server expires or an authentication or accounting response is received
from the server, the status of the server changes back to active automatically, but the device
does not check the server again during the authentication or accounting process.
If no server is found reachable during one search process, the device considers the
authentication or accounting attempt a failure.
•
Once the accounting process of a user starts, the device keeps sending the user's real-time
accounting requests and stop-accounting requests to the same accounting server.
•
If you remove the accounting server, real-time accounting requests and stop-accounting
requests for the user are no longer delivered to the server.
•
If you remove an authentication or accounting server in use, the communication of the device
with the server will soon time out, and the device will look for a server in active state by checking
the primary server first and then the secondary servers in the order they are configured.
•
When the primary server and secondary servers are all in blocked state, the device
communicates with the primary server. If the primary server is available, its status changes to
active. Otherwise, its status remains to be blocked.
•
If one server is in active state and all the others are in blocked state, the device only tries to
communicate with the server in active state, even if the server is unavailable.
•
After receiving an authentication/accounting response from a server, the device changes the
status of the server identified by the source IP address of the response to active if the current
status of the server is blocked.
The device does not change the status of an unreachable authentication or accounting server if the
server quiet timer is set to 0. Instead, the device keeps the server status as active and sends
authentication or accounting packets to another server in active state, so subsequent authentication
or accounting packets can still be sent to that server. For more information about the server quiet
timer, see "Setting RADIUS timers."
By default, the device sets the status of all RADIUS servers to active. In some cases, however, you
may need to change the status of a server. For example, if a server fails, you can change the status
of the server to blocked to avoid communication attempts to the server.
To set the status of RADIUS servers in a RADIUS scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme view.
radius scheme radius-scheme-name
N/A
30
Step
Command
•
•
3.
Set the RADIUS server
status.
•
•
Remarks
Set the status of the primary RADIUS
authentication/authorization server:
state primary authentication { active
| block }
Set the status of the primary RADIUS
accounting server:
state primary accounting { active |
block }
Set the status of a secondary RADIUS
authentication/authorization server:
state secondary authentication [ ip
ipv4-address | ipv6 ipv6-address ]
{ active | block }
Set the status of a secondary RADIUS
accounting server:
state secondary accounting [ ip
ipv4-address | ipv6 ipv6-address ]
{ active | block }
Optional.
By default, all servers
in the RADIUS scheme
are in active state.
The server status set by the state command cannot be saved to the configuration file. After the
device restarts, the status of each server is restored to active.
To display the states of the servers, use the display radius scheme command.
Specifying the source IP address for outgoing RADIUS packets
The source IP address of RADIUS packets that a NAS sends must match the IP address of the NAS
configured on the RADIUS server. A RADIUS server identifies a NAS by its IP address. Upon
receiving a RADIUS packet, a RADIUS server checks whether the source IP address of the packet is
the IP address of any managed NAS. If yes, the server processes the packet. If not, the server drops
the packet.
The source address of outgoing RADIUS packets is typically the IP address of the NAS's any
interface that can communicate with the RADIUS server. In some cases, however, you must change
the source IP address. For example, if the NAS is configured with VRRP for stateful failover, the
source IP address of outgoing RADIUS packets can be the virtual IP address of the uplink VRRP
group.
You can specify a source IP address for outgoing RADIUS packets in RADIUS scheme view for a
specific RADIUS scheme, or in system view for all RADIUS schemes whose servers are in a VPN or
the public network. Before sending a RADIUS packet, the NAS selects a source IP address in the
following order:
1.
The source IP address specified for the RADIUS scheme.
2.
The source IP address specified in system view for the VPN or public network, depending on
where the RADIUS server resides.
3.
The IP address of the outbound interface specified by the route.
To specify a source IP address for all RADIUS schemes in a VPN or the public network:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Specify a source IP address
for outgoing RADIUS
packets.
radius nas-ip { ip-address |
ipv6 ipv6-address }
[ vpn-instance
vpn-instance-name ]
By default, the IP address of the
outbound interface is used as the
source IP address.
To specify a source IP address for a specific RADIUS scheme:
31
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme view.
radius scheme
radius-scheme-name
N/A
3.
Specify a source IP address
for outgoing RADIUS
packets.
nas-ip { ip-address | ipv6
ipv6-address }
By default, the IP address of the
outbound interface is used as the
source IP address.
Setting RADIUS timers
The device uses the following types of timers to control the communication with a RADIUS server:
•
Server response timeout timer (response-timeout)—Defines the RADIUS request
retransmission interval. After sending a RADIUS request (authentication/authorization or
accounting request), the device starts the server response timeout timer. If the device receives
no response from the RADIUS server before the timer expires, it resends the request.
•
Server quiet timer (quiet)—Defines the duration to keep an unreachable server in blocked
state. If one server is not reachable, the device changes the server's status to blocked, starts
this timer for the server, and tries to communicate with another server in active state. After the
server quiet timer expires, the device changes the status of the server back to active.
•
Real-time accounting timer (realtime-accounting)—Defines the interval at which the device
sends real-time accounting packets to the RADIUS accounting server for online users. To
implement real-time accounting, the device must periodically send real-time accounting
packets to the accounting server for online users.
Follow these guidelines when you set RADIUS timers:
•
For the same type of users, the maximum number of transmission attempts multiplied by the
RADIUS server response timeout period must be less than the client connection timeout time
and cannot exceed 75 seconds. Otherwise, stop-accounting messages cannot be buffered, and
the primary/secondary server switchover cannot take place. For example, the product of the
two parameters must be less than 10 seconds for voice users and less than 30 seconds for
Telnet users, because the client connection timeout period for voice users is 10 seconds and
that for Telnet users is 30 seconds.
•
When you configure the maximum number of RADIUS packet transmission attempts and the
RADIUS server response timeout timer, consider the number of secondary servers. If the
retransmission process takes too long, the client connection in the access module may time out
while the device is trying to find an available server. For more information about the maximum
number of RADIUS packet transmission attempts, see "Setting the maximum number of
RADIUS request transmission attempts."
•
When a number of secondary servers are configured, the client connections of access modules
that have a short client connection timeout period may still be timed out during initial
authentication or accounting, even if the packet transmission attempt limit and server response
timeout period are configured with small values. In this case, the next authentication or
accounting attempt can succeed because the device has set the status of the unreachable
servers to blocked so time for finding a reachable server is shortened.
•
Properly set the server quiet timer. Too short a quiet timer can result in frequent authentication
or accounting failures because the device keeps trying to communicate with an unreachable
server that is in active state.
To set RADIUS timers:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme view.
radius scheme
radius-scheme-name
N/A
32
Step
Command
3.
Set the RADIUS server
response timeout timer.
timer response-timeout
seconds
4.
Set the server quiet timer.
timer quiet minutes
5.
Set the real-time accounting
interval.
timer realtime-accounting
minutes
Remarks
Optional.
The default RADIUS server
response timeout timer is 3
seconds.
Optional.
The default server quiet timer is 5
minutes.
Optional.
The default real-time accounting
interval is 12 minutes.
Configuring RADIUS accounting-on
The accounting-on feature enables the device to send an accounting-on packet to the RADIUS
server after it reboots so the server can log out users who logged in through the device before the
reboot. Without this feature, users who were online before the reboot could not re-log in after the
reboot, because the RADIUS server would consider them already online.
If the device receives no response to the accounting-on packet, it re-sends the packet to the RADIUS
server at a particular interval for a specified number of times.
The accounting-on feature requires the cooperation of the IMC network management system.
To configure the accounting-on feature for a RADIUS scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme
view.
radius scheme
radius-scheme-name
N/A
3.
Enable accounting-on and
configure parameters.
accounting-on enable
[ interval seconds | send
send-times ] *
Disabled by default.
The default interval is 3 seconds and the
default number of send-times is 50.
Configuring the IP address of the security policy server
The core of the EAD solution is integration and cooperation. The security policy server is the
management and control center for EAD. Using a collection of software, the security policy server
provides functions such as user management, security policy management, security status
assessment, security cooperation control, and security event audit.
The NAS checks the validity of received control packets and accepts only control packets from
known servers. To use a security policy server that is independent of the AAA servers, you must
configure the IP address of the security policy server on the NAS. To implement all EAD functions,
configure both the IP address of the security policy server and the IP address of the IMC Platform on
the NAS.
To configure the IP address of the security policy server for a scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme
view.
radius scheme
radius-scheme-name
N/A
33
Step
3.
Specify a security policy
server.
Command
Remarks
No security policy server is
specified by default.
security-policy-server ip-address
You can specify up to eight security
policy servers for a RADIUS
scheme.
Configuring interpretation of the RADIUS class attribute as CAR parameters
This task is required when the RADIUS server supports assigning CAR parameters through the
class attribute and the device supports CAR parameters assignment.
According to RFC 2865, a RADIUS server assigns the RADIUS class attribute (attribute 25) to a
RADIUS client. However, the RFC only requires the RADIUS client to send the attribute to the
accounting server on an "as is" basis. It does not require the RADIUS client to interpret the attribute.
When RADIUS servers use the class attribute to deliver the assigned CAR parameters, the device
must interpret the attribute as the CAR parameters to implement user-based traffic monitoring and
controlling.
To configure the device to interpret the RADIUS class attribute as CAR parameters:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme view.
radius scheme
radius-scheme-name
N/A
3.
Interpret the class attribute as
CAR parameters.
attribute 25 car
By default, RADIUS attribute 25 is not
interpreted as CAR parameters.
Enabling the trap function for RADIUS
With the trap function, the NAS sends a trap message when either of the following events occurs:
•
The status of a RADIUS server changes. If the NAS receives no response to an accounting or
authentication request before the specified maximum number of RADIUS request transmission
attempts is exceeded, it considers the server unreachable, sets the status of the server to block
and sends a trap message. If the NAS receives a response from a RADIUS server that it
considers unreachable, the NAS considers that the RADIUS server is reachable again, sets the
status of the server to active, and sends a trap message.
•
The ratio of the number of failed transmission attempts to the total number of authentication
request transmission attempts reaches the threshold. This threshold ranges from 1% to 100%
and defaults to 30%. This threshold can only be configured through the MIB.
The failure ratio is typically small. If a trap message is triggered because the failure ratio is higher
than the threshold, troubleshoot the configuration on and the communication between the NAS and
the RADIUS server.
To enable the trap function for RADIUS:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the trap function for
RADIUS.
radius trap
{ accounting-server-down |
authentication-error-threshold |
authentication-server-down }
Disabled by default.
34
Enabling the RADIUS client service
To receive and send RADIUS packets, enable the RADIUS client service on the device. If RADIUS is
not required, disable the RADIUS client service to avoid attacks that exploit RADIUS packets.
To enable the RADIUS client service:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the RADIUS client
service.
radius client enable
Optional.
Enabled by default.
Displaying and maintaining RADIUS
Task
Command
Remarks
Display the configuration of RADIUS
schemes (in standalone mode).
display radius scheme
[ radius-scheme-name ] [ slot slot-number ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any
view.
Display the configuration of RADIUS
schemes (in IRF mode).
display radius scheme
[ radius-scheme-name ] [ chassis
chassis-number slot slot-number ] [ | { begin |
exclude | include } regular-expression ]
Available in any
view.
Display the RADIUS packet statistics
(in standalone mode).
display radius statistics [ slot slot-number ]
[ | { begin | exclude | include }
regular-expression ]
Available in any
view.
Display the RADIUS packet statistics
(in IRF mode).
display radius statistics [ chassis
chassis-number slot slot-number ] [ | { begin |
exclude | include } regular-expression ]
Available in any
view.
Display information about buffered
stop-accounting requests for which no
responses have been received (in
standalone mode).
display stop-accounting-buffer
{ radius-scheme radius-scheme-name |
session-id session-id | time-range start-time
stop-time | user-name user-name } [ slot
slot-number ] [ | { begin | exclude | include }
regular-expression ]
Available in any
view.
Display information about buffered
stop-accounting requests for which no
responses have been received (in IRF
mode).
display stop-accounting-buffer
{ radius-scheme radius-scheme-name |
session-id session-id | time-range start-time
stop-time | user-name user-name } [ chassis
chassis-number slot slot-number ] [ | { begin |
exclude | include } regular-expression ]
Available in any
view.
Clear RADIUS statistics (in
standalone mode).
reset radius statistics [ slot slot-number ]
Available in user
view.
Clear RADIUS statistics (in IRF
mode).
reset radius statistics [ chassis
chassis-number slot slot-number ]
Available in user
view.
Clear the buffered stop-accounting
requests for which no responses have
been received (in standalone mode).
reset stop-accounting-buffer
{ radius-scheme radius-scheme-name |
session-id session-id | time-range start-time
stop-time | user-name user-name } [ slot
slot-number ]
Available in user
view.
35
Task
Command
Remarks
Clear the buffered stop-accounting
requests for which no responses have
been received (in IRF mode).
reset stop-accounting-buffer
{ radius-scheme radius-scheme-name |
session-id session-id | time-range start-time
stop-time | user-name user-name } [ chassis
chassis-number slot slot-number ]
Available in user
view.
Configuring HWTACACS schemes
You cannot remove the HWTACACS schemes in use or change the IP addresses of the HWTACACS
servers in use.
HWTACACS configuration task list
Task
Remarks
Creating an HWTACACS scheme
Required.
Specifying the HWTACACS authentication servers
Required.
Specifying the HWTACACS authorization servers
Optional.
Specifying the HWTACACS accounting servers and the relevant parameters
Optional.
Specifying the shared keys for secure HWTACACS communication
Required.
Specifying a VPN for the HWTACACS scheme
Optional.
Setting the username format and traffic statistics units
Optional.
Specifying the source IP address for outgoing HWTACACS packets
Optional.
Setting HWTACACS timers
Optional.
Displaying and maintaining HWTACACS
Optional.
Creating an HWTACACS scheme
The HWTACACS protocol is configured on a per scheme basis. Before you perform other
HWTACACS configurations, create an HWTACACS scheme and enter HWTACACS scheme view.
You can configure up to 16 HWTACACS schemes.
To create an HWTACACS scheme and enter HWTACACS scheme view:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an HWTACACS scheme and
enter HWTACACS scheme view.
hwtacacs scheme
hwtacacs-scheme-name
Not defined by default.
You can delete an HWTACACS scheme only when it is not referenced.
Specifying the HWTACACS authentication servers
You can specify one primary authentication server and one secondary authentication server for an
HWTACACS scheme. When the primary server is not available, the secondary server is used. In a
scenario where redundancy is not required, specify only the primary server.
An HWTACACS server can function as the primary authentication server of one scheme and as the
secondary authentication server of another scheme at the same time. You cannot specify the same
IP address as both the primary and the secondary authentication servers in a scheme.
To specify HWTACACS authentication servers for an HWTACACS scheme:
36
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter HWTACACS scheme
view.
hwtacacs scheme
hwtacacs-scheme-name
N/A
•
3.
Specify HWTACACS
authentication servers.
•
Specify the primary
HWTACACS authentication
server:
primary authentication
ip-address [ port-number |
vpn-instance
vpn-instance-name ] *
Specify the secondary
HWTACACS authentication
server:
secondary authentication
ip-address [ port-number |
vpn-instance
vpn-instance-name ] *
Configure at least one
command.
No authentication server is
specified by default.
You can remove an authentication server only when no active TCP connection for sending
authentication packets is using it.
Specifying the HWTACACS authorization servers
You can specify one primary authorization server and one secondary authorization server for an
HWTACACS scheme. When the primary server is not available, the secondary server is used. In a
scenario where redundancy is not required, specify only the primary server.
An HWTACACS server can function as the primary authorization server of one scheme and as the
secondary authorization server of another scheme at the same time. You cannot specify the same IP
address as both the primary and the secondary authorization servers in a scheme.
To specify HWTACACS authorization servers for an HWTACACS scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter HWTACACS scheme
view.
hwtacacs scheme
hwtacacs-scheme-name
N/A
•
3.
Specify HWTACACS
authorization servers.
•
Specify the primary HWTACACS
authorization server:
primary authorization
ip-address [ port-number |
vpn-instance
vpn-instance-name ] *
Specify the secondary
HWTACACS authorization
server:
secondary authorization
ip-address [ port-number |
vpn-instance
vpn-instance-name ] *
Configure at least one
command.
No authorization server is
specified by default.
You can remove an authorization server only when no active TCP connection for sending
authorization packets is using it.
37
Specifying the HWTACACS accounting servers and the relevant parameters
You can specify one primary accounting server and one secondary accounting server for an
HWTACACS scheme. When the primary server is not available, the secondary server is used. In a
scenario where redundancy is not required, specify only the primary server.
When the device receives a connection teardown request from a host or a connection teardown
command from an administrator, it sends a stop-accounting request to the accounting server. You
can enable buffering of non-responded stop-accounting requests to allow the device to buffer and
resend a stop-accounting request until it receives a response or the number of stop-accounting
attempts reaches the configured limit. In the latter case, the device discards the packet.
An HWTACACS server can function as the primary accounting server of one scheme and as the
secondary accounting server of another scheme at the same time. You cannot specify the same IP
address as both the primary and the secondary accounting servers in a scheme.
HWTACACS does not support accounting for FTP users.
To specify HWTACACS accounting servers and set relevant parameters for an HWTACACS
scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter HWTACACS scheme
view.
hwtacacs scheme
hwtacacs-scheme-name
N/A
•
3.
4.
5.
Specify HWTACACS
accounting servers.
•
Specify the primary
HWTACACS accounting
server:
primary accounting
ip-address [ port-number |
vpn-instance
vpn-instance-name ] *
Specify the secondary
HWTACACS accounting
server:
secondary accounting
ip-address [ port-number |
vpn-instance
vpn-instance-name ] *
Enable buffering of
stop-accounting requests
to which no responses are
received.
stop-accounting-buffer enable
Set the maximum number
of stop-accounting
attempts.
retry stop-accounting retry-times
Configure at least one
command.
No accounting server is
specified by default.
Optional.
Enabled by default.
Optional.
The default setting is 100.
You can remove an accounting server only when no active TCP connection for sending accounting
packets is using it.
Specifying the shared keys for secure HWTACACS communication
The HWTACACS client and HWTACACS server use the MD5 algorithm and a shared key pair for
password encryption.
To specify a shared key for secure HWTACACS communication:
Step
Command
Remarks
1.
system-view
N/A
Enter system view.
38
Step
Command
Remarks
2.
hwtacacs scheme
hwtacacs-scheme-name
N/A
Enter HWTACACS scheme
view.
By default, no shared key is
specified.
3.
Specify a shared key for
secure HWTACACS
authentication,
authorization, or accounting
communication.
key { accounting |
authentication | authorization }
[ cipher | simple ] key
In FIPS mode, the shared key
must be a string of at least 8
characters that contain numbers,
uppercase letters, lowercase
letters, and special characters.
The shared key configured on the
device must be the same as that
configured on the HWTACACS
server.
Specifying a VPN for the HWTACACS scheme
You can specify a VPN for all the AAA servers in an HWTACACS scheme. However, the VPN has a
lower priority than those configured for individual HWTACACS servers.
To specify a VPN for an HWTACACS scheme:
Step
Command
1.
Enter system view.
system-view
2.
Enter HWTACACS scheme view.
hwtacacs scheme hwtacacs-scheme-name
3.
Specify a VPN for the HWTACACS scheme.
vpn-instance vpn-instance-name
Setting the username format and traffic statistics units
A username is usually in the format userid@isp-name, where isp-name represents the user's ISP
domain name. By default, the ISP domain name is included in a username; however, some
HWTACACS servers do not recognize usernames that contain the ISP domain names. In this case,
you can configure the device to remove the domain name from each username to be sent.
The device periodically sends accounting updates to HWTACACS accounting servers to report the
traffic statistics of online users. For normal and accurate traffic statistics, make sure that the unit for
data flows and that for packets on the device are consistent with those configured on the
HWTACACS servers.
To set the username format and the traffic statistics units for an HWTACACS scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter HWTACACS scheme
view.
hwtacacs scheme
hwtacacs-scheme-name
N/A
3.
Set the format of usernames
sent to the HWTACACS
servers.
user-name-format { keep-original
| with-domain | without-domain }
Specify the unit for data
flows or packets sent to the
HWTACACS servers.
data-flow-format { data { byte |
giga-byte | kilo-byte |
mega-byte } | packet
{ giga-packet | kilo-packet |
mega-packet | one-packet } }*
4.
39
Optional.
By default, the ISP domain name
is included in a username.
Optional.
The default unit is byte for data
flows and one-packet for data
packets.
If an HWTACACS server does not support a username that carries the domain name, configure the
device to remove the domain name before sending the username to the server.
For level switching authentication, user-name-format keep-original and user-name-format
without-domain commands all produce the same results: they make sure that usernames sent to
the HWTACACS server carry no ISP domain name.
Specifying the source IP address for outgoing HWTACACS packets
The source IP address of HWTACACS packets that a NAS sends must match the IP address of the
NAS configured on the HWTACACS server. An HWTACACS server identifies a NAS by IP address.
Upon receiving an HWTACACS packet, an HWTACACS server checks whether the source IP
address of the packet is the IP address of any managed NAS. If yes, the server processes the packet.
If not, the server drops the packet.
The source address of outgoing HWTACACS packets is typically the IP address of the NAS's any
interface that can communicate with the HWTACACS server. In some cases, however, you must
change the source IP address. For example, if the NAS is configured with VRRP for stateful failover,
the source IP address of HWTACACS packets can be the virtual IP address of the uplink VRRP
group.
You can specify the source IP address for outgoing HWTACACS packets in HWTACACS scheme
view for a specific HWTACACS scheme, or in system view for all HWTACACS schemes whose
servers are in a VPN or the public network.
Before sending an HWTACACS packet, the NAS selects a source IP address in the following order:
1.
The source IP address specified for the HWTACACS scheme.
2.
The source IP address specified in system view for the VPN or public network, depending on
where the HWTACACS server resides.
3.
The IP address of the outbound interface specified by the route.
To specify a source IP address for all HWTACACS schemes of a VPN or the public network:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Specify a source IP address
for outgoing HWTACACS
packets.
hwtacacs nas-ip ip-address
[ vpn-instance
vpn-instance-name ]
By default, the IP address of the
outbound interface is used as the
source IP address.
To specify a source IP address for a specific HWTACACS scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter HWTACACS scheme
view.
hwtacacs scheme
hwtacacs-scheme-name
N/A
3.
Specify a source IP address
for outgoing HWTACACS
packets.
nas-ip ip-address
By default, the IP address of the
outbound interface is used as the
source IP address.
Setting HWTACACS timers
The device uses the following timers to control the communication with an HWTACACS server:
•
Server response timeout timer (response-timeout)—Defines the HWTACACS request
retransmission interval. After sending an HWTACACS request (authentication, authorization, or
accounting request), the device starts the server response timeout timer. If the device receives
no response from the server before the timer expires, it resends the request.
40
•
Primary server quiet timer (quiet)—Defines the duration to keep an unreachable primary
server in blocked state. If a primary server is not reachable, the device changes the server's
status to blocked, starts this timer for the server, and tries to communicate with the secondary
server if the secondary server is configured and in active state. After the primary server quiet
timer expires, the device changes the status of the primary server back to active.
•
Real-time accounting timer (realtime-accounting)—Defines the interval at which the device
sends real-time accounting updates to the HWTACACS accounting server for online users. To
implement real-time accounting, the device must send periodically real-time accounting
packets to the accounting server for online users.
Consider the performance of the NAS and the HWTACACS server when you set the real-time
accounting interval. A shorter interval requires higher performance.
To set HWTACACS timers:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter HWTACACS scheme
view.
hwtacacs scheme
hwtacacs-scheme-name
N/A
3.
Set the HWTACACS server
response timeout timer.
timer response-timeout
seconds
4.
Set the quiet timer for the
primary server.
timer quiet minutes
5.
Set the real-time accounting
interval.
timer realtime-accounting
minutes
Optional.
The default HWTACACS server
response timeout timer is 5
seconds.
Optional.
The default quiet timer for the
primary server is 5 minutes.
Optional.
The default real-time accounting
interval is 12 minutes.
Displaying and maintaining HWTACACS
Task
Command
Remarks
Display the configuration or statistics
of HWTACACS schemes (in
standalone mode).
display hwtacacs [ hwtacacs-scheme-name
[ statistics ] ] [ slot slot-number ] [ | { begin |
exclude | include } regular-expression ]
Available in
any view.
Display the configuration or statistics
of HWTACACS schemes (in IRF
mode).
display hwtacacs [ hwtacacs-scheme-name
[ statistics ] ] [ chassis chassis-number slot
slot-number ] [ | { begin | exclude | include }
regular-expression ]
Available in
any view.
Display information about buffered
stop-accounting requests for which no
responses have been received (in
standalone mode).
display stop-accounting-buffer
hwtacacs-scheme hwtacacs-scheme-name
[ slot slot-number ] [ | { begin | exclude |
include } regular-expression ]
Available in
any view.
Display information about buffered
stop-accounting requests for which no
responses have been received (in IRF
mode).
display stop-accounting-buffer
hwtacacs-scheme hwtacacs-scheme-name
[ chassis chassis-number slot slot-number ] [ |
{ begin | exclude | include } regular-expression ]
Available in
any view.
Clear HWTACACS statistics (in
standalone mode).
reset hwtacacs statistics { accounting | all |
authentication | authorization } [ slot
slot-number ]
Available in
user view.
41
Task
Command
Remarks
Clear HWTACACS statistics (in IRF
mode).
reset hwtacacs statistics { accounting | all |
authentication | authorization } [ chassis
chassis-number slot slot-number ]
Available in
user view.
Clear buffered stop-accounting
requests that get no responses (in
standalone mode).
reset stop-accounting-buffer
hwtacacs-scheme hwtacacs-scheme-name
[ slot slot-number ]
Available in
user view.
Clear buffered stop-accounting
requests that get no responses (in IRF
mode).
reset stop-accounting-buffer
hwtacacs-scheme hwtacacs-scheme-name
[ chassis chassis-number slot slot-number ]
Available in
user view.
Configuring AAA methods for ISP domains
By default, the device uses local (default) AAA methods for users in an ISP domain. To use other
AAA methods for them, configure the device to reference existing AAA schemes for the ISP domain.
For information about configuring AAA schemes, see "Configuring RADIUS schemes" and
"Configuring HWTACACS schemes."
To use local authentication for users in an ISP domain, first configure local user accounts on the
device (see "Configuring local user attributes").
Creating an ISP domain
In a networking scenario with multiple ISPs, the device can connect users of different ISPs. Different
ISP users can have different user attributes (such as username and password structures), different
service types, and different rights. To manage these ISP users, you need to create ISP domains and
then configure AAA methods and domain attributes for each ISP domain.
The device can accommodate up to 16 ISP domains, including the system predefined ISP domain
system. You can specify one ISP domain as the default domain.
On the device, each user belongs to an ISP domain. If a user provides no ISP domain name at login,
the device considers the user belongs to the default ISP domain.
The device chooses an authentication domain for each user in the following order:
•
The authentication domain specified for the access module
•
The ISP domain in the username
•
The default ISP domain of the device
•
The ISP domain specified for users with unknown domain names
If all the domains are unavailable, user authentication will fail.
NOTE:
Support for the authentication domain configuration depends on the access module. You can
specify an authentication domain for 802.1X, portal, or MAC address authentication.
To create an ISP domain:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an ISP domain and
enter ISP domain view.
domain isp-name
N/A
3.
Return to system view.
quit
N/A
42
Step
Command
4.
Specify the default ISP
domain.
domain default enable
isp-name
5.
Specify an ISP domain for
users with unknown domain
names.
domain if-unknown
isp-name
Remarks
Optional.
By default, the default ISP domain is the
system predefined ISP domain system.
Optional.
By default, no ISP domain is specified
for users with unknown domain names.
To delete the ISP domain that is functioning as the default ISP domain, you must change it to a
non-default ISP domain by using the undo domain default enable command.
Configuring ISP domain attributes
In an ISP domain, you can configure the following attributes:
•
Domain status—By placing the ISP domain to the active or blocked state, you allow or deny
network service requests from users in the domain.
•
Maximum number of online users—The device controls the number of online users in a
domain to ensure the system performance and service reliability.
•
Idle cut—Enables the device to check the traffic of each online user in the domain at the idle
timeout interval, and to log out any user in the domain whose traffic during the idle timeout
period is less than the specified minimum traffic.
•
Self-service server location—Allows users to access the self-service server to manage their
own accounts and passwords.
•
IP address pool for allocating addresses to PPP users—The device assigns IP addresses
from the pool to PPP users in the domain.
•
Default authorization user profile—If a user passes authentication but is authorized with no
user profile, the device authorizes the default user profile of the ISP domain to the user and
restricts the user's behavior based on the profile. For more information about user profiles, see
"Configuring user profiles."
An ISP domain attribute applies to all users in the domain.
A self-service RADIUS server running on IMC is required for the self-service server location function
to work.
To configure ISP domain attributes:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter ISP domain view.
domain isp-name
N/A
Optional.
3.
Place the ISP domain to the
active or blocked state.
state { active | block }
4.
Specify the maximum
number of online users in
the ISP domain.
access-limit enable
max-user-number
By default, an ISP domain is in
active state, and users in the
domain can request network
services.
Optional.
No limit is specified by default.
Optional.
5.
Configure the idle cut
function.
idle-cut enable minute [ flow ]
Disabled by default.
This command is effective only for
LAN, portal, and PPP users.
43
Step
Command
Remarks
Enable the self-service
server location function and
specify the URL of the
self-service server.
self-service-url enable
url-string
Optional.
Define an IP address pool
for allocating addresses to
PPP users.
ip pool pool-number
low-ip-address
[ high-ip-address ]
Optional.
8.
Specify the default
authorization user profile.
authorization-attribute
user-profile profile-name
9.
Set the device to include
the idle cut time in the user
online time to be uploaded
to the server.
6.
7.
Disabled by default.
By default, no IP address pool is
configured for PPP users.
Optional.
By default, an ISP domain has no
default authorization user profile.
Optional.
session-time include-idle-time
By default, the user online time
uploaded to the server excludes the
idle cut time.
Configuring authentication methods for an ISP domain
In AAA, authentication, authorization, and accounting are separate processes. Authentication refers
to the interactive authentication process of username/password/user information during an access
or service request. The authentication process neither sends authorization information to a
supplicant nor triggers any accounting.
AAA supports the following authentication methods:
•
No authentication (none)—No authentication is performed. This method trusts all users and is
not for general use.
•
Local authentication (local)—Authentication is performed by the NAS, which is configured
with the user information, including the usernames, passwords, and attributes. Local
authentication allows high speed and low cost, but the amount of information that can be stored
is limited by the size of the storage space.
•
Remote authentication (scheme)—The NAS cooperates with a RADIUS or HWTACACS
server to authenticate users. Remote authentication provides centralized information
management, high capacity, high reliability, and support for centralized authentication service
for multiple NASs. You can configure local or no authentication as the backup method, which
will be used when the remote server is not available. The no authentication method can only be
configured for LAN users as the backup method of remote authentication.
You can configure AAA authentication to work alone without authorization and accounting.
By default, an ISP domain uses the local authentication method.
Configuration prerequisites
Before configuring authentication methods, complete the following tasks:
•
For RADIUS or HWTACACS authentication, configure the RADIUS or HWTACACS scheme to
be referenced first. Local and none authentication methods do not require a scheme.
•
Determine the access type or service type to be configured. With AAA, you can configure an
authentication method for each access type and service type to limit the authentication
protocols that users can use for access.
•
Determine whether to configure the default authentication method for all access types or
service types.
Configuration guidelines
When configuring authentication methods, follow these guidelines:
44
•
If you configure an authentication method that references a RADIUS scheme and an
authorization method that does not reference a RADIUS scheme, AAA accepts only the
authentication result from the RADIUS server. The Access-Accept message from the RADIUS
server also carries the authorization information, but the device ignores the information.
•
You can configure a default authentication method for an ISP domain. The default method will
be used for all users who support the authentication method and have no specific
authentication method configured.
•
You can configure local authentication (local) or no authentication (none) as the backup for
remote authentication that is used when the remote authentication server is unavailable.
•
Local authentication (local) and no authentication (none) cannot have a backup method.
•
If the method for level switching authentication references an HWTACACS scheme, by default
the device uses the login username of the user for level switching authentication. If the method
for level switching authentication references a RADIUS scheme, the system uses the username
configured for the corresponding privilege level on the RADIUS server for level switching
authentication, rather than the login username. A username configured on the RADIUS server
is in the format $enablevel$, where level specifies the privilege level that the user wants to enter.
For example, if user user1 of domain aaa wants to switch the privilege level to 3, the system
uses $enab3@aaa$ for authentication when the domain name is required and uses
$enab3$ for authentication when the domain name is not required.
Configuration procedure
To configure authentication methods for an ISP domain:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter ISP domain view.
domain isp-name
N/A
3.
Specify the default
authentication method
for all types of users.
authentication default
{ hwtacacs-scheme
hwtacacs-scheme-name [ local ] | local |
none | radius-scheme
radius-scheme-name [ local ] }
Optional.
4.
Specify the
authentication method
for DVPN users.
authentication dvpn { local | none |
radius-scheme radius-scheme-name
[ local ] }
Optional.
The default authentication
method is local for all types
of users.
The default authentication
method is used by default.
Optional.
5.
6.
7.
8.
The default authentication
method is used by default.
Specify the
authentication method
for LAN users.
authentication lan-access { local | none |
radius-scheme radius-scheme-name
[ local | none ] }
Specify the
authentication method
for login users.
authentication login { hwtacacs-scheme
hwtacacs-scheme-name [ local ] | local |
none | radius-scheme
radius-scheme-name [ local ] }
Optional.
Specify the
authentication method
for portal users.
authentication portal { local | none |
radius-scheme radius-scheme-name
[ local ] }
Optional.
Specify the
authentication method
for PPP users.
authentication ppp { hwtacacs-scheme
hwtacacs-scheme-name [ local ] | local |
none | radius-scheme
radius-scheme-name [ local ] }
Optional.
45
This command is supported
only on SAP interface
modules that are operating in
Layer 2 mode.
The default authentication
method is used by default.
The default authentication
method is used by default.
The default authentication
method is used by default.
Step
9.
Specify the
authentication method
for privilege level
switching.
Command
Remarks
authentication super { hwtacacs-scheme
hwtacacs-scheme-name | radius-scheme
radius-scheme-name }
Optional.
The default authentication
method is used by default.
Configuring authorization methods for an ISP domain
In AAA, authorization is a separate process at the same level as authentication and accounting. Its
responsibility is to send authorization requests to the specified authorization servers and to send
authorization information to users after successful authorization. Authorization method configuration
is optional in AAA configuration.
AAA supports the following authorization methods:
•
No authorization (none)—The NAS performs no authorization exchange. After passing
authentication, non-login users can access the network, FTP users can access the root
directory of the NAS, and other login users have Level 0 (visiting) access.
•
Local authorization (local)—The NAS performs authorization according to the user attributes
configured for users.
•
Remote authorization (scheme)—The NAS cooperates with a RADIUS or HWTACACS
server to authorize users. RADIUS authorization is bound with RADIUS authentication.
RADIUS authorization can work only after RADIUS authentication is successful, and the
authorization information is carried in the Access-Accept message. HWTACACS authorization
is separate from HWTACACS authentication, and the authorization information is carried in the
authorization response after successful authentication. You can configure local authorization or
no authorization as the backup method. The backup method will be used when the remote
server is not available.
Configuration prerequisites
Before configuring authorization methods, complete the following tasks:
1.
For HWTACACS authorization, configure the HWTACACS scheme to be referenced first. For
RADIUS authorization, the RADIUS authorization scheme must be the same as the RADIUS
authentication scheme. Otherwise, it does not take effect.
2.
Determine the access type or service type to be configured. With AAA, you can configure an
authorization scheme for each access type and service type to limit the authorization protocols
that can be used for access.
3.
Determine whether to configure an authorization method for all access types or service types.
Configuration guidelines
When configuring authorization methods, follow these guidelines:
•
To configure RADIUS authorization, you must also configure RADIUS authentication, and
reference the same RADIUS scheme for RADIUS authentication and authorization. If the
RADIUS authorization configuration is invalid or RADIUS authorization fails, the RADIUS
authentication also fails. If RADIUS authorization fails, the server sends an error message to
the NAS, indicating that the server itself is not responding.
•
You can configure a default authorization method for an ISP domain. This method will be used
for all users who support the authentication method and have no specific authorization method
configured.
•
You can configure local authorization (local) or no authorization (none) as the backup for
remote authorization that is used when the remote authorization server is unavailable.
•
Local authorization (local) and no authorization (none) cannot have a backup method.
46
Configuration procedure
To configure authorization methods for an ISP domain:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter ISP domain view.
domain isp-name
N/A
3.
Specify the default
authorization method for
all types of users.
authorization default
{ hwtacacs-scheme
hwtacacs-scheme-name [ local ] | local |
none | radius-scheme
radius-scheme-name [ local ] }
Optional.
4.
Specify the command
authorization method.
authorization command
{ hwtacacs-scheme
hwtacacs-scheme-name [ local | none ] |
local | none }
Optional.
5.
Specify the authorization
method for DVPN users.
authorization dvpn { local | none |
radius-scheme radius-scheme-name
[ local ] }
Optional.
The default authorization
method is local for all types
of users.
The default authorization
method is used by default.
The default authorization
method is used by default.
Optional.
The default authorization
method is used by default.
Specify the authorization
method for LAN users.
authorization lan-access { local | none |
radius-scheme radius-scheme-name
[ local | none ] }
7.
Specify the authorization
method for login users.
authorization login { hwtacacs-scheme
hwtacacs-scheme-name [ local ] | local |
none | radius-scheme
radius-scheme-name [ local ] }
Optional.
8.
Specify the authorization
method for portal users.
authorization portal { local | none |
radius-scheme radius-scheme-name
[ local ] }
Optional.
9.
Specify the authorization
method for PPP users.
authorization ppp { hwtacacs-scheme
hwtacacs-scheme-name [ local ] | local |
none | radius-scheme
radius-scheme-name [ local ] }
Optional.
6.
This command is supported
only on SAP interface
modules that are operating in
Layer 2 mode.
The default authorization
method is used by default.
The default authorization
method is used by default.
The default authorization
method is used by default.
Configuring accounting methods for an ISP domain
In AAA, accounting is a separate process at the same level as authentication and authorization. This
process sends accounting start/update/end requests to the specified accounting server. Accounting
is optional.
AAA supports the following accounting methods:
•
No accounting (none)—The NAS does not perform accounting for the users.
•
Local accounting (local)—Local accounting is implemented on the NAS. It counts and
controls the number of concurrent users who use the same local user account. The maximum
number of concurrent users using the same local user account is set by the access-limit
command in local user view.
•
Remote accounting (scheme)—The NAS works with a RADIUS server or HWTACACS server
for accounting. You can configure local or no accounting as the backup method, which will be
used when the remote server is not available.
47
By default, an ISP domain uses the local accounting method.
Configuration prerequisites
Before configuring accounting methods, complete the following tasks:
1.
For RADIUS or HWTACACS accounting, configure the RADIUS or HWTACACS scheme to be
referenced first. The local and none accounting methods do not require a scheme.
2.
Determine the access type or service type to be configured. With AAA, you can configure an
accounting method for each access type and service type to limit the accounting protocols that
can be used for access.
3.
Determine whether to configure an accounting method for all access types or service types.
Configuration guidelines
When configuring accounting methods, follow these guidelines:
•
You can configure a default accounting method for an ISP domain. This method will be used for
all users who support the accounting method and have no specific accounting method
configured.
•
You can configure local accounting (local) or no accounting (none) as the backup for remote
accounting that is used when the remote accounting server is unavailable.
•
Local accounting (local) and no accounting (none) cannot have a backup method.
•
Accounting is not supported for FTP services.
•
If you enable the accounting optional feature, the limit on the number of local user connections
does not take effective.
Configuration procedure
To configure accounting methods for an ISP domain:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter ISP domain view.
domain isp-name
N/A
Optional.
Disabled by default.
With the accounting optional
feature, a device allows users
to use network resources
when no accounting server is
available or communication
with all accounting servers
fails.
3.
Enable the accounting
optional feature.
accounting optional
4.
Specify the default
accounting method for all
types of users.
accounting default
{ hwtacacs-scheme
hwtacacs-scheme-name [ local ] |
local | none | radius-scheme
radius-scheme-name [ local ] }
5.
Specify the command
accounting method.
accounting command
hwtacacs-scheme
hwtacacs-scheme-name
Optional.
6.
Specify the accounting
method for DVPN users.
accounting dvpn { local | none |
radius-scheme
radius-scheme-name [ local ] }
Optional.
48
Optional.
The default accounting
method is local for all types of
users.
The default accounting
method is used by default.
The default accounting
method is used by default.
Step
Command
Remarks
Optional.
7.
accounting lan-access { local |
none | radius-scheme
radius-scheme-name [ local |
none ] }
Specify the accounting
method for LAN users.
The default accounting
method is used by default.
This command is supported
only on SAP interface
modules that are operating in
Layer 2 mode.
Accounting statistics is
collected per port for 802.1X.
8.
Specify the accounting
method for login users.
accounting login
{ hwtacacs-scheme
hwtacacs-scheme-name [ local ] |
local | none | radius-scheme
radius-scheme-name [ local ] }
9.
Specify the accounting
method for portal users.
accounting portal { local | none |
radius-scheme
radius-scheme-name [ local ] }
accounting ppp
{ hwtacacs-scheme
hwtacacs-scheme-name [ local ] |
local | none | radius-scheme
radius-scheme-name [ local ] }
10. Specify the accounting
method for PPP users.
Optional.
The default accounting
method is used by default.
Optional.
The default accounting
method is used by default.
Optional.
The default accounting
method is used by default.
Tearing down user connections
Step
Command
Remarks
1.
system-view
N/A
Enter system view.
•
2.
Tear down AAA user
connections.
•
In standalone mode:
cut connection { access-type { dot1x |
mac-authentication | portal } | all | domain
isp-name | interface interface-type
interface-number | ip ip-address | mac
mac-address | ucibindex ucib-index |
user-name user-name } [ slot slot-number ]
In IRF mode:
cut connection { access-type { dot1x |
mac-authentication | portal } | all | domain
isp-name | interface interface-type
interface-number | ip ip-address | mac
mac-address | ucibindex ucib-index |
user-name user-name } [ chassis
chassis-number slot slot-number ]
The command
applies only to LAN,
portal, and PPP
user connections.
Configuring a NAS ID-VLAN binding
The access locations of users can be identified by their access VLANs. In application scenarios
where identifying the access locations of users is a must, configure NAS ID-VLAN bindings on the
device. Then, when a user gets online, the device obtains the NAS ID by the access VLAN of the
user and sends the NAS ID to the RADIUS server through the NAS-identifier attribute.
To configure a NAS ID-VLAN binding:
49
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a NAS ID profile and
enter NAS ID profile view.
aaa nas-id profile profile-name
You can apply a NAS ID profile to
an interface enabled with portal.
See "Configuring portal."
3.
Configure a NAS ID-VLAN
binding.
nas-id nas-identifier bind vlan
vlan-id
By default, no NAS ID-VLAN
binding exists.
Displaying and maintaining AAA
Task
Command
Remarks
Display the configuration of
ISP domains.
display domain [ isp-name ] [ | { begin | exclude |
include } regular-expression ]
Available in
any view.
Display information about
user connections (in
standalone mode).
display connection [ access-type { dot1x |
mac-authentication | portal } | domain isp-name |
interface interface-type interface-number | ip ip-address |
mac mac-address | ucibindex ucib-index | user-name
user-name ] [ slot slot-number ] [ | { begin | exclude |
include } regular-expression ]
Available in
any view.
Display information about
user connections (in IRF
mode).
display connection [ access-type { dot1x |
mac-authentication | portal } | domain isp-name |
interface interface-type interface-number | ip ip-address |
mac mac-address | ucibindex ucib-index | user-name
user-name ] [ chassis chassis-number slot slot-number ] [ |
{ begin | exclude | include } regular-expression ]
Available in
any view.
AAA configuration examples
RADIUS authentication/authorization for Telnet/SSH users
The configuration of RADIUS authentication and authorization for SSH users is similar to that for
Telnet users. This example describes the configuration for Telnet users.
Network requirements
As shown in Figure 10, configure the router to use the RADIUS server for Telnet user authentication
and authorization and add an account with the username hello@bbb on the RADIUS server, so the
Telnet user can log in to the router and is authorized with the privilege level 3 after login.
Set the shared key for secure RADIUS communication to expert, and set the ports for
authentication/authorization to 1812, respectively. Configure the router to include the domain name
in the usernames sent to the RADIUS server.
50
Figure 10 Network diagram
Configuring the RADIUS server
This section assumes that the RADIUS server runs on IMC PLAT 5.1 SP1 (E0202P05) and IMC
UAM 5.1 (E0301).
1.
Add the router to the IMC Platform as an access device:
a. Log in to IMC, click the Service tab, and select User Access Manager > Access Device
Management > Access Device from the navigation tree.
b. Click Add to configure an access device as follows:
Set the shared key for secure authentication and accounting communication to expert.
Set the ports for authentication to 1812, respectively.
Select the service type Device Management Service.
Select the access device type HP(General).
Select the access device from the device list or manually add the access device (with the IP
address 10.1.1.2).
c. Click OK.
The IP address of the access device specified here must be the same as the source IP address
of the RADIUS packets sent from the device, which is chosen in the following order:
{
IP address specified with the nas-ip command on the device.
{
IP address specified with the radius nas-ip command on the device.
{
IP address of the outbound interface (the default).
51
Figure 11 Adding the router as an access device
2.
Add a user account for device management:
a. Click the User tab, and then select Access User View > Device Mgmt User from the
navigation tree.
b. Click Add to configure a device management account as follows:
Enter the account name hello@bbb and specify the password.
Select the service type Telnet.
Set the EXEC privilege level to 3. This argument identifies the privilege level of the Telnet
user after login and defaults to 0.
Specify 10.1.1.0 to 10.1.1.255 as the IP address range of the hosts to be managed. The IP
address range must contain the IP address of the access device.
c. Click OK.
52
Figure 12 Adding an account for device management
Configuring the router
# Assign an IP address to interface GigabitEthernet 3/0/1, the Telnet user access interface.
<Router> system-view
[Router] interface gigabitethernet 3/0/1
[Router-GigabitEthernet3/0/1] ip address 192.168.1.70 255.255.255.0
[Router-GigabitEthernet3/0/1] quit
# Configure the IP address of interface GigabitEthernet 3/0/2, through which the router
communicates with the server.
[Router] interface gigabitethernet 3/0/2
[Router-GigabitEthernet3/0/2] ip address 10.1.1.2 255.255.255.0
[Router-GigabitEthernet3/0/2] quit
# Enable the Telnet server on the router.
[Router] telnet server enable
# Configure the router to use AAA for Telnet users.
[Router] user-interface vty 0 4
[Router-ui-vty0-4] authentication-mode scheme
[Router-ui-vty0-4] quit
# Create RADIUS scheme rad.
[Router] radius scheme rad
# Specify the primary authentication server.
[Router-radius-rad] primary authentication 10.1.1.1 1812
# Set the shared key for secure authentication communication to expert.
53
[Router-radius-rad] key authentication expert
# Specify the service type for the RADIUS server, which must be extended when the server runs on
IMC.
[Router-radius-rad] server-type extended
# Include the domain names in usernames sent to the RADIUS server.
[Router-radius-rad] user-name-format with-domain
[Router-radius-rad] quit
# Configure the AAA methods for domain bbb. Because RADIUS authorization information is sent to
the RADIUS client in the authentication response messages, be sure to reference the same scheme
for user authentication and authorization.
[Router] domain bbb
[Router-isp-bbb] authentication login radius-scheme rad
[Router-isp-bbb] authorization login radius-scheme rad
[Router-isp-bbb] quit
Verifying the configuration
After the configuration is complete, the user can Telnet to the router, use the configured account to
enter the user interface of the router, and access all the commands of level 0 to level 3.
# Use the display connection command to view the connection information on the router.
[Router] display connection
Index=1
,Username=hello@bbb
IP=192.168.1.58
IPv6=N/A
Total 1 connection(s) matched.
Local authentication/authorization for Telnet/FTP users
The configuration of local authentication and authorization for FTP users is similar to that for Telnet
users. This example describes the configuration of Telnet users.
Network requirements
As shown in Figure 13, configure the router to perform local authentication and authorization for
Telnet users.
Figure 13 Network diagram
Configuration procedure
# Assign an IP address to interface GigabitEthernet 3/0/1, the Telnet user access interface.
<Router> system-view
[Router] interface gigabitethernet 3/0/1
[Router-GigabitEthernet3/0/1] ip address 192.168.1.70 255.255.255.0
[Router-GigabitEthernet3/0/1] quit
# Enable the Telnet server on the device.
[Router] telnet server enable
# Configure the router to use AAA for Telnet users.
54
[Router] user-interface vty 0 4
[Router-ui-vty0-4] authentication-mode scheme
[Router-ui-vty0-4] quit
# Create local user named telnet.
[Router] local-user telnet
[Router-luser-telnet] service-type telnet
[Router-luser-telnet] password simple aabbcc
[Router-luser-telnet] quit
# Configure the AAA methods for the ISP domain as local authentication and authorization.
[Router] domain system
[Router-isp-system] authentication login local
[Router-isp-system] authorization login local
[Router-isp-system] quit
Verifying the configuration.
A user can Telnet to the user interface of the router by using username telnet@system and
correct password.
# Use the display connection command to view the connection information on Router.
[Router] display connection
Index=1
,Username=telnet@system
IP=192.168.1.58
IPv6=N/A
Total 1 connection(s) matched.
AAA for PPP users by an HWTACACS server
Network requirements
As shown in Figure 14, configure the router to use the HWTACACS server to assign IP addresses
and provide authentication, authorization, and accounting services for PPP users.
Set the shared keys for secure HWTACACS communication to expert. Configure the router to send
usernames without domain names to the HWTACACS server.
Figure 14 Network diagram
Configuration procedure
1.
Configure the HWTACACS server.
On the HWTACACS server, set the shared keys for secure communication with the router to
expert, add an account for the PPP user, and specify the password. (Details not shown.)
55
2.
Configure the router:
# Create HWTACACS scheme hwtac.
<Router> system-view
[Router] hwtacacs scheme hwtac
# Specify the primary authentication server.
[Router-hwtacacs-hwtac] primary authentication 10.1.1.1 49
# Specify the primary authorization server.
[Router-hwtacacs-hwtac] primary authorization 10.1.1.1 49
# Specify the primary accounting server.
[Router-hwtacacs-hwtac] primary accounting 10.1.1.1 49
# Set the shared keys for secure HWTACACS communication to expert.
[Router-hwtacacs-hwtac] key authentication simple expert
[Router-hwtacacs-hwtac] key authorization simple expert
[Router-hwtacacs-hwtac] key accounting simple expert
# Remove domain names from the usernames sent to the HWTACACS server.
[Router-hwtacacs-hwtac] user-name-format without-domain
[Router-hwtacacs-hwtac] quit
# Configure AAA methods for the domain.
[Router] domain bbb
[Router-isp-bbb] authentication ppp hwtacacs-scheme hwtac
[Router-isp-bbb] authorization ppp hwtacacs-scheme hwtac
[Router-isp-bbb] accounting ppp hwtacacs-scheme hwtac
[Router-isp-bbb] ip pool 1 200.1.1.1 200.1.1.99
[Router-isp-bbb] quit
# Configure the serial interface.
[Router] interface serial 2/1/1
[Router-Serial2/1/1] link-protocol ppp
[Router-Serial2/1/1] ppp authentication-mode pap domain bbb
[Router-Serial2/1/1] ip address 2.2.2.1 255.255.255.0/1
[Router-Serial2/1/1] remote address pool 1
[Router-Serial2/1/1] quit
# Configure the Ethernet interface.
[Router] interface gigabitethernet 3/0/1
[Router-GigabitEthernet3/0/1] ip address 10.1.1.2 255.255.255.0
Verifying the configuration.
Initiate a PPP connection from the PPP client, and enter the correct username and password.
You pass authentication and the PPP client can use the IP address assigned by the router to
access the network. You can use the display connection command on the router to view
information about the connection.
Level switching authentication for Telnet users by a RADIUS
server
Network requirements
As shown in Figure 15, configure the router to:
•
Use local authentication for the Telnet user and assign the privilege level of 0 to the user when
the user passes authentication.
56
•
Use the RADIUS server for level switching authentication of the Telnet user. If the RADIUS
server is not available, use local authentication.
Figure 15 Network diagram
Configuration considerations
1.
2.
3.
Configure the router to use AAA, particularly, local authentication for Telnet users:
{
Create ISP domain bbb and configure it to use local authentication for Telnet users.
{
Create a local user account, configure the password, and assign the privilege level for the
user to enjoy after login.
On the router, configure the authentication method for user privilege level switching:
{
Specify the router to use RADIUS authentication and, if RADIUS authentication is not
available, use local authentication for users switching from a lower level to a higher level.
{
Configure RADIUS scheme rad and assign an IP address to the RADIUS server. Set the
shared keys for secure RADIUS communication and specify that usernames sent to the
RADIUS server carry no domain name. Configure the domain to use RADIUS scheme rad
for user privilege level switching authentication.
{
Configure the password for local user privilege level switching authentication.
On the RADIUS server, add the username and password for user privilege level switching
authentication.
Configuration procedure
1.
Configure the router:
# Configure the IP address of GigabitEthernet 3/0/1, through which the Telnet user accesses
the router.
<Router> system-view
[Router] interface gigabitethernet 3/0/1
[Router-GigabitEthernet3/0/1] ip address 192.168.1.70 255.255.255.0
[Router-GigabitEthernet3/0/1] quit
# Configure the IP address of GigabitEthernet 3/0/2, through which the router communicates
with the server.
[Router] interface gigabitethernet 3/0/2
[Router-GigabitEthernet3/0/2] ip address 10.1.1.2 255.255.255.0
[Router-GigabitEthernet3/0/2] quit
# Enable the router to provide Telnet service.
[Router] telnet server enable
# Configure the router to use AAA for Telnet users.
[Router] user-interface vty 0 4
[Router-ui-vty0-4] authentication-mode scheme
57
[Router-ui-vty0-4] quit
# Use RADIUS authentication for user privilege level switching authentication and, if RADIUS
authentication is not available, use local authentication.
[Router] super authentication-mode scheme local
# Create RADIUS scheme rad.
[Router] radius scheme rad
# Specify the IP address of the primary authentication server as 10.1.1.1, and the port for
authentication as 1812.
[Router-radius-rad] primary authentication 10.1.1.1 1812
# Set the shared key for secure authentication communication to expert.
[Router-radius-rad] key authentication expert
# Specify the service type of the RADIUS server as standard.
[Router-radius-rad] server-type standard
# Remove domain names from the usernames sent to the RADIUS server.
[Router-radius-rad] user-name-format without-domain
[Router-radius-rad] quit
# Create ISP domain bbb.
[Router] domain bbb
# Configure the AAA methods for domain bbb as local authentication.
[Router-isp-bbb] authentication login local
# Configure the domain to use the RADIUS scheme rad for user privilege level switching
authentication.
[Router-isp-bbb] authentication super radius-scheme rad
[Router-isp-bbb] quit
# Create a local Telnet user named test.
[Router] local-user test
[Router-luser-test] service-type telnet
[Router-luser-test] password simple aabbcc
# Configure the user level of the Telnet user to 0 after user login.
[Router-luser-test] authorization-attribute level 0
[Router-luser-test] quit
# Configure the password for local level switching authentication to 654321.
[Router] super password simple 654321
[Router] quit
2.
Configure the RADIUS server.
The RADIUS server in this example runs ACSv4.0.
Add the usernames and passwords for user privilege level switching authentication.
Table 5 Adding username and passwords for user privilege level switching authentication
Username
Password
Switching to level
$enab1$
pass1
1
$enab2$
pass2
2
$enab3$
pass3
3
A username configured on the RADIUS server is in the format $enablevel$, where level
specifies the privilege level to which the user wants to switch.
58
Figure 16 Configuring a username for privilege level switching (take $enab1$ for example)
Figure 17 List of the usernames for privilege level switching
Verifying the configuration.
After the configuration is complete, the user can Telnet to the router and use username
test@bbb and password aabbcc to enter the user interface of the router, and access all level 0
commands.
<Router> telnet 192.168.1.70
Trying 192.168.1.70 ...
Press CTRL+K to abort
Connected to 192.168.1.70 ...
******************************************************************************
* Copyright (c) 2010-2015 Hewlett Packard Enterprise Development LP
*
* Without the owner's prior written consent,
*
59
* no decompiling or reverse-engineering shall be allowed.
*
******************************************************************************
Login authentication
Username:test@bbb
Password:
<Router> ?
User view commands:
cluster
Run cluster command
display
Display current system information
ping
Ping function
quit
Exit from current command view
ssh2
Establish a secure shell client connection
super
Set the current user priority level
telnet
Establish one TELNET connection
tracert
Trace route function
When switching to user privilege level 3, the Telnet user only needs to enter password pass3
as prompted.
<Router> super 3
Password:
User privilege level is 3, and only those commands can be used
whose level is equal or less than this.
Privilege note: 0-VISIT, 1-MONITOR, 2-SYSTEM, 3-MANAGE
If the RADIUS authentication is not available, the Telnet user needs to enter password 654321
as prompted for local authentication.
<Router> super 3
Password: Å Enter the password for RADIUS privilege level switching authentication.
Error: Invalid configuration or no response from the authentication server.
Info: Change authentication mode to local.
Password: Å Enter the password for local privilege level switching authentication.
User privilege level is 3, and only those commands can be used
whose level is equal or less than this.
Privilege note: 0-VISIT, 1-MONITOR, 2-SYSTEM, 3-MANAGE
AAA for portal users by a RADIUS server
Network requirements
As shown in Figure 18, the host automatically obtains a public network IP address through DHCP.
Configure the router to:
•
Use the RADIUS server for authentication/authorization of portal users.
•
Provide direct portal authentication so that the host can access only the portal server before
passing portal authentication and can access the Internet after passing portal authentication.
•
Include the domain name in a username sent to the RADIUS server.
Set the shared keys for secure RADIUS communication to expert. Set the ports for
authentication/authorization to 1812.
60
Figure 18 Network diagram
RADIUS server / Portal server
10.1.1.1/24
GE3/0/1
192.168.1.70/24
Portal user
GE3/0/2
10.1.1.2/24
Internet
Router
192.168.1.58/24
Gateway : 192.168.1.70/24
Configuration prerequisites
Configure IP addresses for the devices as shown in Figure 18 and make sure that devices can reach
each other. (Details not shown.)
Configuring the RADIUS server
This section assumes that the RADIUS server runs on IMC PLAT 5.1 SP1 (E0202P05) and IMC
UAM 5.1 (E0301).
1.
Add the router to the IMC Platform as an access device:
a. Log in to IMC, click the Service tab, and then select User Access Manager > Access
Device Management > Access Device from the navigation tree.
b. Click Add to configure an access device as follows:
Set the shared key for secure authentication communication to expert.
Set the ports for authentication to 1812, respectively.
Select the service type LAN Access Service.
Select the access device type HP(General).
Select the access device from the device list or manually add the device with the IP address
10.1.1.2.
c. Leave the default settings for other parameters and click OK.
The IP address of the access device specified here must be the same as the source IP address
of the RADIUS packets sent from the router, which is chosen in the following order on the
router:
{
IP address specified with the nas-ip command.
{
IP address specified with the radius nas-ip command.
{
IP address of the outbound interface (the default).
61
Figure 19 Adding the router as an access device
2.
Add a service:
a. Click the Service tab, and then select User Access Manager > Service Configuration
from the navigation tree.
b. Click Add to configure a service as follows:
Enter Portal auth as the service name.
Enter dm1 as the service suffix to represent the authentication domain for the portal user.
With the service suffix configured, you must configure the access device to send usernames
that carry domain names to the RADIUS server.
Configure other parameters as needed.
c. Click OK.
Figure 20 Adding a service
3.
Add an access user account:
a. Click the User tab, and then select Access User View > All Access Users from the
navigation tree.
b. Click Add to configure a user as follows:
Select the user or add a user named hello.
Enter the account name portal and specify the password.
Select the access service Portal auth.
Configure other parameters as needed.
c. Click OK.
62
Figure 21 Adding an access user account
Configuring the portal server
This section assumes that the RADIUS server runs on IMC PLAT 5.1 SP1 (E0202P05) and IMC
UAM 5.1 (E0301).
1.
Configure the portal server:
a. Log in to IMC, click the Service tab, and then select User Access Manager > Portal
Service > Server from the navigation tree.
b. Enter the URL address of the portal authentication main page, in the format
http://ip:port/portal, where ip and port are those configured during IMC UAM installation.
Usually, the default port 8080 is used.
c. Leave the default settings for other parameters and click OK.
Figure 22 Portal server configuration
2.
Configure an IP address group:
a. Select User Access Manager > Portal Service > IP Group from the navigation tree.
b. Click Add to configure an IP address group as follows:
Enter the name Portal_user.
63
Set the start IP address to 192.168.1.1 and the end IP address to 192.168.1.255. Make sure
the IP address group contains the IP address of the host.
Select the action Normal.
c. Click OK.
Figure 23 Adding an IP address group
3.
Configure the router as a portal device:
a. Select User Access Manager > Portal Service > Device from the navigation tree.
b. Click Add to configure a portal device as follows:
Enter the device name NAS.
Enter the IP address of the access interface on the router, which is 192.168.1.70.
Enter the key, which is portal, the same as that configured on the router.
Specify whether to enable IP address reallocation. This example uses direct portal
authentication by selecting No from the Reallocate IP list.
c. Leave the default settings for other parameters and click OK.
Figure 24 Adding a portal device
4.
Associate the portal device with the IP address group:
a. In the portal device list, click the icon in the Port Group column for NAS.
b. Click Add to configure a port group for the portal device as follows:
Enter the port group name.
64
Select an IP address group you just configured from the IP Group list.
c. Leave the default settings for other parameters and click OK.
Figure 25 Device list
Figure 26 Associating the portal device with IP address group
5.
Select User Access Manager > Service Parameters > Validate from the navigation tree to
validate the configurations.
Configuring the router
# Create a RADIUS scheme named rs1 and enter its view.
<Router> system-view
[Router] radius scheme rs1
# Set the server type for the RADIUS scheme. When using IMC, set the server type to
extended.
[Router-radius-rs1] server-type extended
# Specify the primary authentication server, service port number, and shared key for secure
authentication/authorization communication.
[Router-radius-rs1] primary authentication 10.1.1.1
[Router-radius-rs1] key authentication expert
# Include the domain names in usernames sent to the RADIUS server.
[Router-radius-rs1] user-name-format with-domain
[Router-radius-rs1] quit
Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[Router] domain dm1
65
# Configure the ISP domain to use RADIUS scheme rs1.
[Router-isp-dm1] authentication portal radius-scheme rs1
[Router-isp-dm1] authorization portal radius-scheme rs1
[Router-isp-dm1] quit
# Configure dm1 as the default ISP domain for all users. Then, if a user enters a username
without any ISP domain at login, the authentication/authorization methods of the default domain
will be used for the user.
[Router] domain default enable dm1
Configure portal authentication:
# Configure the portal server.
[Router] portal server newpt ip 10.1.1.1 key portal port 50100 url
http://10.1.1.1:8080/portal
# Enable portal authentication on the interface connecting the host.
[Router] interface gigabitethernet 3/0/1
[Router-GigabitEthernet3/0/1] portal server newpt method direct
[Router-GigabitEthernet3/0/1] quit
Verifying the configuration
The user can initiate portal authentication by using the iNode client or by accessing a Web page. All
the initiated Web requests will be redirected to the portal authentication page at
http://10.1.1.1:8080/portal. Before passing portal authentication, the user can access only the
authentication page. After passing portal authentication, the user can access the Internet.
# After the user passes portal authentication, view the portal user information on the router.
[Router] display portal user interface gigabitethernet 3/0/1
Index:19
State:ONLINE
SubState:NONE
ACL:NONE
Work-mode:stand-alone
MAC
IP
Vlan
Interface
--------------------------------------------------------------------0015-e9a6-7cfe
192.168.1.58
0
GigabitEthernet3/0/1
On interface GigabitEthernet3/0/1:total 1 user(s) matched, 1 listed.
# View the connection information on the router.
[Router] display connection
Index=20
,Username=portal@dm1
MAC=00-15-E9-A6-7C-FE
IP=192.168.1.58
IPv6=N/A
Total 1 connection(s) matched.
Troubleshooting AAA
Troubleshooting RADIUS
Symptom 1
User authentication/authorization always fails.
66
Analysis
Possible reasons include:
•
A communication failure exists between the NAS and the RADIUS server.
•
The username is not in the format userid@isp-name or the ISP domain is not correctly
configured on the NAS.
•
The user is not configured on the RADIUS server.
•
The password entered by the user is incorrect.
•
The RADIUS server and the NAS are configured with different shared keys.
Solution
Check that:
•
The NAS and the RADIUS server can ping each other.
•
The username is in the userid@isp-name format and the ISP domain is correctly configured on
the NAS.
•
The user is configured on the RADIUS server.
•
The correct password is entered.
•
The same shared key is configured on both the RADIUS server and the NAS.
Symptom 2
RADIUS packets cannot reach the RADIUS server.
Analysis
Possible reasons include:
•
A communication failure exists between the NAS and the RADIUS server.
•
The NAS is not configured with the IP address of the RADIUS server.
•
The authentication/authorization and accounting UDP ports configured on the NAS are
incorrect.
•
The RADIUS server's authentication/authorization and accounting port numbers are being
used by other applications.
Solution
Check that:
•
The link between the NAS and the RADIUS server work well at both the physical and data link
layers.
•
The IP address of the RADIUS server is correctly configured on the NAS.
•
The authentication/authorization and accounting UDP ports configured on the NAS are the
same as those of the RADIUS server.
•
The RADIUS server's authentication/authorization and accounting port numbers are available.
Symptom 3
A user is authenticated and authorized, but accounting for the user is not normal.
Analysis
The accounting server configuration on the NAS is not correct. Possible reasons include:
•
The accounting port number configured on the NAS is incorrect.
•
The accounting server IP address configured on the NAS is incorrect. For example, the NAS is
configured to use a single server to provide authentication, authorization, and accounting
services, but in fact the services are provided by different servers.
67
Solution
Check that:
•
The accounting port number is correctly configured.
•
The accounting server IP address is correctly configured on the NAS.
Troubleshooting HWTACACS
Similar to RADIUS troubleshooting. See "Troubleshooting RADIUS."
68
802.1X overview
802.1X is a port-based network access control protocol initially proposed by the IEEE 802 LAN/WAN
committee for securing wireless LANs (WLANs), and it has also been widely used on Ethernet
networks for access control.
802.1X controls network access by authenticating the devices connected to 802.1X-enabled LAN
ports.
802.1X architecture
802.1X operates in the client/server model. It comprises three entities: the client (the supplicant), the
network access device (the authenticator), and the authentication server.
Figure 27 802.1X architecture
•
The client—A user terminal seeking access to the LAN. It must have 802.1X software to
authenticate to the network access device.
•
The network access device—Authenticates the client to control access to the LAN. In a
typical 802.1X environment, the network access device uses an authentication server to
perform authentication.
•
The authentication server—Provides authentication services for the network access device.
The authentication server authenticates 802.1X clients by using the data sent from the network
access device, and returns the authentication results for the network access device to make
access decisions. The authentication server is typically a Remote Authentication Dial-in User
Service (RADIUS) server. In a small LAN, you can also use the network access device as the
authentication server.
Controlled/uncontrolled port and port
authorization status
802.1X defines two logical ports for the network access port: controlled port and uncontrolled port.
Any packet arriving at the network access port is visible to both logical ports.
•
Controlled port—Allows incoming and outgoing traffic to pass through when it is in the
authorized state, and denies incoming and outgoing traffic when it is in the unauthorized state,
as shown in Figure 28. The controlled port is set in the authorized state if the client has passed
authentication, and in the unauthorized state, if the client has failed authentication.
•
Uncontrolled port—Always open to receive and transmit EAPOL frames.
69
Figure 28 Authorization state of a controlled port
In unauthorized state, a controlled port controls traffic in one of the following ways:
•
Performs bidirectional traffic control to deny traffic to and from the client.
•
Performs unidirectional traffic control to deny traffic from the client.
The HPE devices support only unidirectional traffic control.
802.1X-related protocols
802.1X uses the Extensible Authentication Protocol (EAP) to transport authentication information for
the client, the network access device, and the authentication server. EAP is an authentication
framework that uses the client/server model. It supports a variety of authentication methods,
including MD5-Challenge, EAP-Transport Layer Security (EAP-TLS), and Protected EAP (PEAP).
802.1X defines EAP over LAN (EAPOL) for passing EAP packets between the client and the network
access device over a wired or wireless LAN. Between the network access device and the
authentication server, 802.1X delivers authentication information in one of the following methods:
•
Encapsulates EAP packets in RADIUS by using EAP over RADIUS (EAPOR), as described in
"EAP relay."
•
Extracts authentication information from the EAP packets and encapsulates the information in
standard RADIUS packets, as described in "EAP termination."
Packet formats
EAP packet format
Figure 29 shows the EAP packet format.
Figure 29 EAP packet format
70
•
Code—Type of the EAP packet. Options include Request (1), Response (2), Success (3), or
Failure (4).
•
Identifier—Used for matching Responses with Requests.
•
Length—Length (in bytes) of the EAP packet. The length is the sum of the Code, Identifier,
Length, and Data fields.
•
Data—Content of the EAP packet. This field appears only in a Request or Response EAP
packet. The Data field comprises the request type (or the response type) and the type data.
Type 1 (Identify) and type 4 (MD5-challenge) are two examples for the type field.
EAPOL packet format
Figure 30 shows the EAPOL packet format.
Figure 30 EAPOL packet format
0
15
7
PAE Ethernet type
Protocol version
2
Type
Length
4
6
Packet body
N
•
PAE Ethernet type—Protocol type. It takes the value 0x888E for EAPOL.
•
Protocol version—The EAPOL protocol version used by the EAPOL packet sender.
•
Type—Type of the EAPOL packet. Table 6 lists the types of EAPOL packets supported by
Hewlett Packard Enterprise implementation of 802.1X.
Table 6 Types of EAPOL packets
Value
Type
Description
0x00
EAP-Packet
The client and the network access device uses EAP-Packets to
transport authentication information.
0x01
EAPOL-Start
The client sends an EAPOL-Start message to initiate 802.1X
authentication to the network access device.
0x02
EAPOL-Logoff
The client sends an EAPOL-Logoff message to tell the network
access device that it is logging off.
•
Length—Data length in bytes, or length of the Packet body. If packet type is EAPOL-Start or
EAPOL-Logoff, this field is set to 0, and no Packet body field follows.
•
Packet body—Content of the packet. When the EAPOL packet type is EAP-Packet, the Packet
body field contains an EAP packet.
EAP over RADIUS
RADIUS adds two attributes, EAP-Message and Message-Authenticator, for supporting EAP
authentication. For the RADIUS packet format, see "Configuring AAA."
EAP-Message
RADIUS encapsulates EAP packets in the EAP-Message attribute, as shown in Figure 31. The Type
field takes 79, and the Value field can be up to 253 bytes. If an EAP packet is longer than 253 bytes,
RADIUS encapsulates it in multiple EAP-Message attributes.
71
Figure 31 EAP-Message attribute format
Message-Authenticator
RADIUS includes the Message-Authenticator attribute in all packets that have an EAP-Message
attribute to check their integrity. The packet receiver drops the packet if the calculated packet
integrity checksum is different from the Message-Authenticator attribute value. The
Message-Authenticator prevents EAP authentication packets from being tampered with during EAP
authentication.
Figure 32 Message-Authenticator attribute format
Initiating 802.1X authentication
Both the 802.1X client and the access device can initiate 802.1X authentication.
802.1X client as the initiator
The client sends an EAPOL-Start packet to the access device to initiate 802.1X authentication. The
destination MAC address of the packet is the IEEE 802.1X specified multicast address
01-80-C2-00-00-03 or the broadcast MAC address. If any intermediate device between the client
and the authentication server does not support the multicast address, use an 802.1X client, the
iNode 802.1X client for example, that can send broadcast EAPOL-Start packets.
Access device as the initiator
The access device initiates authentication, if a client cannot send EAPOL-Start packets (for example,
an 802.1X client available with Windows XP).
The access device supports the following modes:
•
Multicast trigger mode—The access device multicasts Identity EAP-Request packets
periodically (every 30 seconds by default) to initiate 802.1X authentication.
•
Unicast trigger mode—Upon receiving a frame with the source MAC address not in the MAC
address table, the access device sends an Identity EAP-Request packet out of the receiving
port to the unknown MAC address. It retransmits the packet if no response has been received
within a certain time interval.
802.1X authentication procedures
802.1X provides two authentication methods: EAP relay and EAP termination. You choose either
mode depending on the support of the RADIUS server for EAP packets and EAP authentication
methods.
•
EAP relay mode
72
EAP relay is defined in IEEE 802.1X. In this mode, the network device uses EAPoR packets to
send authentication information to the RADIUS server, as shown in Figure 33.
Figure 33 EAP relay
In EAP relay mode, the client must use the same authentication method as the RADIUS server.
On the network access device, you only need to use the dot1x authentication-method eap
command to enable EAP relay.
•
EAP termination mode
In EAP termination mode, the network access device terminates the EAP packets received
from the client, encapsulates the client authentication information in standard RADIUS packets,
and uses (Password Authentication Protocol) PAP or (Password Authentication Protocol)
CHAP to authenticate to the RADIUS server, as shown in Figure 34.
Figure 34 EAP termination
A comparison of EAP relay and EAP termination
Packet exchange
method
Benefits
•
EAP relay
•
Limitations
Supports various EAP
authentication methods.
The configuration and
processing is simple on the
network access device.
The RADIUS server must support
the EAP-Message and
Message-Authenticator attributes,
and the EAP authentication
method used by the client.
•
EAP termination
Works with any RADIUS server that
supports PAP or CHAP
authentication.
•
Supports only MD5-Challenge
EAP authentication and the
"username + password" EAP
authentication initiated by an
iNode 802.1X client.
The processing is complex on
the network access device.
EAP relay
Figure 35 shows the basic 802.1X authentication procedure in EAP relay mode, assuming that
EAP-MD5 is used.
73
Figure 35 802.1X authentication procedure in EAP relay mode
Client
Device
Authentication server
EAPOR
EAPOL
(1) EAPOL-Start
(2) EAP-Request/Identity
(3) EAP-Response/Identity
(4) RADIUS Access-Request
(EAP-Response/Identity)
(5) RADIUS Access-Challenge
(EAP-Request/MD5 challenge)
(6) EAP-Request/MD5 challenge
(7) EAP-Response/MD5 challenge
(8) RADIUS Access-Request
(EAP-Response/MD5 challenge)
(9) RADIUS Access-Accept
(EAP-Success)
(10) EAP-Success
Port authorized
(11) EAP-Request/Identity
(12) EAP-Response/Identity
...
(13) EAPOL-Logoff
Port unauthorized
(14) EAP-Failure
1.
When a user launches the 802.1X client software and enters a registered username and
password, the 802.1X client software sends an EAPOL-Start packet to the network access
device.
2.
The network access device responds with an Identity EAP-Request packet to ask for the client
username.
3.
In response to the Identity EAP-Request packet, the client sends the username in an Identity
EAP-Response packet to the network access device.
4.
The network access device relays the Identity EAP-Response packet in a RADIUS
Access-Request packet to the authentication server.
5.
The authentication server uses the identity information in the RADIUS Access-Request to
search its user database. If a matching entry is found, the server uses a randomly generated
challenge (EAP-Request/MD5 challenge) to encrypt the password in the entry, and sends the
challenge in a RADIUS Access-Challenge packet to the network access device.
6.
The network access device relays the EAP-Request/MD5 Challenge packet in a RADIUS
Access-Request packet to the client.
7.
The client uses the received challenge to encrypt the password, and sends the encrypted
password in an EAP-Response/MD5 Challenge packet to the network access device.
8.
The network access device relays the EAP-Response/MD5 Challenge packet in a RADIUS
Access-Request packet to the authentication server.
9.
The authentication server compares the received encrypted password with the one it generated
at step 5. If the two are identical, the authentication server considers the client valid and sends
a RADIUS Access-Accept packet to the network access device.
74
10. Upon receiving the RADIUS Access-Accept packet, the network access device sends an
EAP-Success packet to the client, and sets the controlled port in the authorized state so the
client can access the network.
11. After the client comes online, the network access device periodically sends handshake
requests to check whether the client is still online. By default, if two consecutive handshake
attempts fail, the device logs off the client.
12. Upon receiving a handshake request, the client returns a response. If the client fails to return a
response after a certain number of consecutive handshake attempts (two by default), the
network access device logs off the client. This handshake mechanism enables timely release of
the network resources used by 802.1X users that have abnormally gone offline.
13. The client can also send an EAPOL-Logoff packet to ask the network access device for a logoff.
14. In response to the EAPOL-Logoff packet, the network access device changes the status of the
controlled port from authorized to unauthorized and sends an EAP-Failure packet to the client.
EAP termination
Figure 36 shows the basic 802.1X authentication procedure in EAP termination mode, assuming that
CHAP authentication is used.
Figure 36 802.1X authentication procedure in EAP termination mode
In EAP termination mode, the network access device rather than the authentication server generates
an MD5 challenge for password encryption (see Step 4). The network access device then sends the
75
MD5 challenge together with the username and encrypted password in a standard RADIUS packet
to the RADIUS server.
76
Configuring 802.1X
This chapter describes how to configure 802.1X on an HPE device. You can also configure the port
security feature to perform 802.1X. Port security combines and extends 802.1X and MAC
authentication. It applies to a network that requires different authentication methods for different
users on a port. Port security is beyond the scope of this chapter. For more information about port
security, see "Configuring port security."
NOTE:
802.1X is supported only on a SAP module that is operating in bridge mode.
Hewlett Packard Enterprise implementation of
802.1X
Access control methods
Hewlett Packard Enterprise implements port-based access control as defined in the 802.1X protocol,
and extends the protocol to support MAC-based access control.
•
Port-based access control—Once an 802.1X user passes authentication on a port, any
subsequent user can access the network through the port without authentication. When the
authenticated user logs off, all other users are logged off.
•
MAC-based access control—Each user is separately authenticated on a port. When a user
logs off, no other online users are affected.
Using 802.1X authentication with other features
VLAN assignment
You can configure the authentication server to assign a VLAN for an 802.1X user that has passed
authentication. The way that the network access device handles VLANs on an 802.1X-enabled port
differs by 802.1X access control mode.
Access control
Port-based
VLAN manipulation
Assigns the VLAN to the port as the port VLAN (PVID). The authenticated 802.1X
user and all subsequent 802.1X users can access the VLAN without authentication.
When the user logs off, the previous PVID restores, and all other online users are
logged off.
•
MAC-based
•
If the port is a hybrid port with MAC-based VLAN enabled, maps the MAC
address of each user to the VLAN assigned by the authentication server. The
PVID of the port does not change. When a user logs off, the MAC-to-VLAN
mapping for the user is removed.
If the port is an access, trunk, or MAC-based VLAN disabled hybrid port,
assigns the first authenticated user's VLAN to the port as the PVID. If a different
VLAN is assigned to a subsequent user, the user cannot pass the
authentication. To avoid the authentication failure of subsequent users, be sure
to assign the same VLAN to all 802.1X users on these ports.
With 802.1X authentication, a hybrid port is always assigned to a VLAN as an untagged member.
After the assignment, do not re-configure the port as a tagged member in the VLAN.
77
On a periodic online user re-authentication enabled port, if a user has been online before you enable
the MAC-based VLAN function, the access device does not create a MAC-to-VLAN mapping for the
user unless the user passes re-authentication and the VLAN for the user has changed.
For more information about VLAN configuration and MAC-based VLAN, see Layer 2—LAN
Switching Configuration Guide.
Guest VLAN
You can configure a guest VLAN on a port to accommodate users that have not performed 802.1X
authentication, so they can access a limited set of network resources, such as a software server, to
download anti-virus software and system patches. Once a user in the guest VLAN passes 802.1X
authentication, it is removed from the guest VLAN and can access authorized network resources.
Guest VLAN is supported on ports that perform port-based access control. The following describes
way that the network access device handles VLANs on a port that performs port-based access
control.
Authentication status
VLAN manipulation
No 802.1X user has
performed authentication
within 90 seconds after
802.1X is enabled
Assigns the 802.1X guest VLAN to the port as the PVID. All 802.1X users
on this port can access only resources in the guest VLAN.
A user in the 802.1X guest
VLAN fails 802.1X
authentication
If no 802.1X guest VLAN is configured, the access device does not perform
any VLAN operation.
If an 802.1X Auth-Fail VLAN (see "Auth-Fail VLAN") is available, assigns
the Auth-Fail VLAN to the port as the PVID. All users on this port can access
only resources in the Auth-Fail VLAN.
If no Auth-Fail VLAN is configured, the PVID on the port is still the 802.1X
guest VLAN. All users on the port are in the guest VLAN.
•
A user in the 802.1X guest
VLAN passes 802.1X
authentication
•
Assigns the VLAN specified for the user to the port as the PVID, and
removes the port from the 802.1X guest VLAN. After the user logs off,
the user configured PVID restores.
If the authentication server assigns no VLAN, the user-configured
PVID applies. The user and all subsequent 802.1X users are assigned
to the user-configured port VLAN. After the user logs off, the port
VLAN remains unchanged.
The network device assigns a hybrid port to an 802.1X guest VLAN as an untagged member.
For more information about VLAN configuration, see Layer 2—LAN Switching Configuration Guide.
Auth-Fail VLAN
You can configure an Auth-Fail VLAN to accommodate users that have failed 802.1X authentication
because of the failure to comply with the organization security strategy, such as using a wrong
password. Users in the Auth-Fail VLAN can access a limited set of network resources, such as a
software server, to download anti-virus software and system patches.
The Auth-Fail VLAN does not accommodate 802.1X users that have failed authentication for
authentication timeouts or network connection problems. The way that the network access device
handles VLANs on the port differs by 802.1X access control mode.
•
On a port that performs port-based access control
Authentication status
VLAN manipulation
A user fails 802.1X
authentication
Assigns the Auth-Fail VLAN to the port as the PVID. All 802.1X users on
this port can access only resources in the Auth-Fail VLAN.
A user in the Auth-Fail VLAN
fails 802.1X re-authentication
The Auth-Fail VLAN is still the PVID on the port, and all 802.1X users on
this port are in this VLAN.
78
Authentication status
VLAN manipulation
•
A user passes 802.1X
authentication
•
•
Assigns the VLAN specified for the user to the port as the PVID, and
removes the port from the Auth-Fail VLAN. After the user logs off, the
user-configured PVID restores.
If the authentication server assigns no VLAN, the initial PVID applies.
The user and all subsequent 802.1X users are assigned to the
user-configured PVID. After the user logs off, the PVID remains
unchanged.
On a port that performs MAC-based access control
Authentication status
VLAN manipulation
A user fails 802.1X
authentication
Re-maps the MAC address of the user to the Auth-Fail VLAN. The user can
access only resources in the Auth-Fail VLAN.
A user in the Auth-Fail VLAN
fails 802.1X re-authentication
The user is still in the Auth-Fail VLAN.
A user in the Auth-Fail VLAN
passes 802.1X
authentication
Re-maps the MAC address of the user to the server-assigned VLAN.
If the authentication server assigns no VLAN, re-maps the MAC address of
the user to the initial PVID on the port.
To perform the 802.1X Auth-Fail VLAN function on a port that performs MAC-based access control,
you must ensure that the port is a hybrid port, and enable MAC-based VLAN on the port.
The network device assigns a hybrid port to an 802.1X Auth-Fail VLAN as an untagged member.
For more information about VLAN configuration and MAC-based VLAN, see Layer 2 — LAN
Switching Configuration Guide.
Critical VLAN
Configure an 802.1X critical VLAN on a port to accommodate 802.1X users that fail authentication
because none of the RADIUS authentication servers in their ISP domain is reachable (active). Users
in the critical VLAN can access a limit set of network resources depending on your configuration.
The critical VLAN feature takes effect when the 802.1X authentication is performed only through
RADIUS servers. If an 802.1X user fails local authentication after RADIUS authentication, the user is
not assigned to the critical VLAN. For more information about RADIUS configuration, see
"Configuring AAA."
The way that the network access device handles VLANs on an 802.1X-enabled port differs by
802.1X access control mode.
•
On a port that performs port-based access control
Authentication status
VLAN manipulation
A user that has not been assigned to any
VLAN fails 802.1X authentication because
all the RADIUS servers are unreachable.
Assigns the critical VLAN to the port as the PVID. The 802.1X
user and all subsequent 802.1X users on this port can access
only resources in the critical VLAN.
A user in the 802.1X critical VLAN fails
authentication because all the RADIUS
servers are unreachable.
The critical VLAN is still the PVID of the port, and all 802.1X
users on this port are in this VLAN.
A user in the 802.1X critical VLAN fails
authentication for any other reason than
server unreachable.
If an Auth-Fail VLAN has been configured, the PVID of the
port changes to Auth-Fail VLAN ID, and all 802.1X users on
this port are moved to the Auth-Fail VLAN.
79
Authentication status
VLAN manipulation
•
•
Assigns the VLAN specified for the user to the port as the
PVID, and removes the port from the critical VLAN. After
the user logs off, the default or user-configured PVID
restores.
If the authentication server assigns no VLAN, the default
or user-configured PVID applies. The user and all
subsequent 802.1X users are assigned to this port
VLAN. After the user logs off, this PVID remains
unchanged.
A user in the critical VLAN passes 802.1X
authentication.
•
A user in the 802.1X guest VLAN or the
Auth-Fail VLAN fails authentication
because all the RADIUS servers is
reachable.
The PVID of the port remains unchanged. All 802.1X users on
this port can access only resources in the guest VLAN or the
Auth-Fail VLAN.
On a port that performs MAC-based access control
Authentication status
VLAN manipulation
A user that has not been assigned to any VLAN
fails 802.1X authentication because all the
RADIUS servers are unreachable.
Maps the MAC address of the user to the critical VLAN.
The user can access only resources in the critical VLAN.
A user in the 802.1X critical VLAN fails
authentication because all the RADIUS servers
are unreachable.
The user is still in the critical VLAN.
A user in the critical VLAN fails 802.1X
authentication for any other reason than server
unreachable.
If an Auth-Fail VLAN has been configured, re-maps the
MAC address of the user to the Auth-Fail VLAN ID.
Re-maps the MAC address of the user to the
server-assigned VLAN.
A user in the critical VLAN passes 802.1X
authentication.
If the authentication server assigns no VLAN, re-maps the
MAC address of the user to the default or user-configured
PVID on the port.
A user in the 802.1X guest VLAN or the
Auth-Fail VLAN fails authentication because all
the RADIUS server are unreachable.
The user remains in the 802.1X VLAN or the Auth-Fail
VLAN.
A user in the MAC authentication guest VLAN
fails 802.1X authentication because all the
802.1X authentication server are unreachable.
The user is removed from the MAC authentication VLAN
and mapped to the 802.1X critical VLAN.
To perform the 802.1X critical VLAN function on a port that performs MAC-based access control, you
must make sure that the port is a hybrid port, and enable MAC-based VLAN on the port.
The network device assigns a hybrid port to an 802.1X critical VLAN as an untagged member.
80
For more information about VLAN configuration and MAC-based VLAN, see Layer 2—LAN
Switching Configuration Guide.
Any of the following RADIUS authentication server changes in the ISP domain for 802.1X users on a
port can cause the users to be removed from the critical VLAN:
•
An authentication server is reconfigured, added, or removed.
•
The status of any RADIUS authentication server automatically changes to active or is
administratively set to active.
•
The RADIUS server probing function detects that a RADIUS authentication server is reachable
and sets its state to active.
You can use the dot1x critical recovery-action reinitialize command to configure the port to
trigger 802.1X re-authentication when the port or an 802.1X user on the port is removed from the
critical VLAN.
•
If MAC-based access control is used, the port sends a unicast Identity EAP/Request to the
802.1X user to trigger authentication.
•
If port-based access control is used, the port sends a multicast Identity EAP/Request to the
802.1X users to trigger authentication.
ACL assignment
You can specify an ACL for an 802.1X user to control its access to network resources. After the user
passes 802.1X authentication, the authentication server, either the local access device or a RADIUS
server, assigns the ACL to the port to filter the traffic from this user. In either case, you must configure
the ACL on the access device. You can change ACL rules while the user is online.
Configuration prerequisites
•
Configure an ISP domain and AAA scheme (local or RADIUS authentication) for 802.1X users.
•
If RADIUS authentication is used, create user accounts on the RADIUS server.
•
If local authentication is used, create local user accounts on the access device and set the
service type to lan-access.
802.1X configuration task list
Task
Remarks
Enabling 802.1X
Required.
Enabling EAP relay or EAP termination
Optional.
Setting the port authorization state
Optional.
Specifying an access control method
Optional.
Setting the maximum number of concurrent 802.1X users on a port
Optional.
Setting the maximum number of authentication request attempts
Optional.
Setting the 802.1X authentication timeout timers
Optional.
Configuring the online user handshake function
Optional.
Enabling the proxy detection function
Optional.
Configuring the authentication trigger function
Optional.
Specifying a mandatory authentication domain on a port
Optional.
81
Task
Remarks
Configuring the quiet timer
Optional.
Enabling the periodic online user re-authentication function
Optional.
Configuring an 802.1X guest VLAN
Optional.
Configuring an Auth-Fail VLAN
Optional.
Configuring an 802.1X critical VLAN
Optional.
Specifying supported domain name delimiters
Optional.
Enabling 802.1X
Follow these guidelines when you enable 802.1X:
•
If the PVID of a port is a voice VLAN, the 802.1X function cannot take effect on the port. For
more information about voice VLANs, see Layer 2—LAN Switching Configuration Guide.
•
802.1X is mutually exclusive with link aggregation and service loopback group configuration on
a port.
•
On an 802.1X and MAC authentication enabled port, the EAP packet from an unknown MAC
address immediately triggers 802.1X authentication, and any other type of packet from an
unknown MAC address triggers MAC authentication 30 seconds after its arrival.
To enable 802.1X:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable 802.1X globally.
dot1x
By default, 802.1X is disabled
globally.
•
3.
Enable 802.1X on a port
in system view or
Ethernet interface view.
•
In system view:
dot1x interface interface-list
In Ethernet interface view:
a. interface interface-type
interface-number
By default, 802.1X is disabled
on a port.
b. dot1x
Enabling EAP relay or EAP termination
When configuring EAP relay or EAP termination, consider the following factors:
•
The support of the RADIUS server for EAP packets
•
The authentication methods supported by the 802.1X client and the RADIUS server
If the client is using only MD5-Challenge EAP authentication or the "username + password" EAP
authentication initiated by an iNode 802.1X client, you can use both EAP termination and EAP relay.
To use EAP-TL, PEAP, or any other EAP authentication methods, you must use EAP relay. When
you make your decision, see "A comparison of EAP relay and EAP termination" for help.
For more information about EAP relay and EAP termination, see "802.1X authentication
procedures."
To configure EAP relay or EAP termination:
82
Step
1.
2.
Enter system
view.
Configure EAP
relay or EAP
termination.
Command
Remarks
system-view
N/A
dot1x
authentication-method
{ chap | eap | pap }
By default, the network access device performs
EAP termination and uses CHAP to communicate
with the RADIUS server.
Specify the eap keyword to enable EAP
termination.
Specify the chap or pap keyword to enable
CHAP-enabled or PAP-enabled EAP relay.
NOTE:
If EAP relay mode is used, the user-name-format command configured in RADIUS scheme view
does not take effect. The access device sends the authentication data from the client to the server
without any modification.
Setting the port authorization state
The port authorization state determines whether the client is granted access to the network. You can
control the authorization state of a port by using the dot1x port-control command and the following
keywords:
•
authorized-force—Places the port in the authorized state, enabling users on the port to access
the network without authentication.
•
unauthorized-force—Places the port in the unauthorized state, denying any access requests
from users on the port.
•
auto—Places the port initially in the unauthorized state to allow only EAPOL packets to pass,
and after a user passes authentication, sets the port in the authorized state to allow access to
the network. You can use this option in most scenarios.
You can set authorization state for one port in interface view, or for multiple ports in system view. If
different authorization state is set for a port in system view and interface view, the one set later takes
effect.
To set the authorization state of a port:
Step
1.
Enter system
view.
Command
Remarks
system-view
N/A
•
2.
Set the port
authorization
state in system
view or Ethernet
interface view.
•
In system view:
dot1x port-control { authorized-force | auto |
unauthorized-force } [ interface interface-list ]
In Ethernet interface view:
By default, auto applies.
a. interface interface-type interface-number
b. dot1x port-control { authorized-force | auto
| unauthorized-force }
Specifying an access control method
You can specify an access control method for one port in interface view, or for multiple ports in
system view. If different access control methods are specified for a port in system view and interface
view, the one specified later takes effect.
83
To specify the access control method:
Step
1.
Enter system
view.
Command
Remarks
system-view
N/A
•
2.
Specify an access
control method in
system view or
Ethernet interface
view.
•
In system view:
dot1x port-method { macbased |
portbased } [ interface
interface-list ]
In Ethernet interface view:
a. interface interface-type
interface-number
By default, MAC-based access
control applies.
b. dot1x port-method { macbased
| portbased }
Setting the maximum number of concurrent
802.1X users on a port
You can set the maximum number of concurrent 802.1X users for ports individually in interface view
or in bulk in system view. If different settings are configured for a port in both views, the setting
configured later takes effect.
To set the maximum number of concurrent 802.1X users on a port:
Step
Command
Remarks
1.
system-view
N/A
Enter system view.
•
2.
Set the maximum number of
concurrent 802.1X users on
a port in system view or
Ethernet interface view.
•
In system view:
dot1x max-user user-number
[ interface interface-list ]
In Ethernet interface view:
a. interface interface-type
interface-number
The default setting is
1024.
b. dot1x max-user user-number
[ interface interface-list ]
Setting the maximum number of authentication
request attempts
The network access device retransmits an authentication request if it receives no response to the
request it has sent to the client within a period of time (specified by using the dot1x timer tx-period
tx-period-value command or the dot1x timer supp-timeout supp-timeout-value command). The
network access device stops retransmitting the request, if it has made the maximum number of
request transmission attempts but still received no response.
To set the maximum number of authentication request attempts:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Set the maximum number of attempts
for sending an authentication request.
dot1x retry max-retry-value
The default setting is
2.
84
Setting the 802.1X authentication timeout timers
The network device uses the following 802.1X authentication timeout timers:
•
Client timeout timer—Starts when the access device sends an EAP-Request/MD5 Challenge
packet to a client. If no response is received when this timer expires, the access device
retransmits the request to the client.
•
Server timeout timer—Starts when the access device sends a RADIUS Access-Request
packet to the authentication server. If no response is received when this timer expires, the
access device retransmits the request to the server.
You can set the client timeout timer to a high value in a low-performance network, and adjust the
server timeout timer to adapt to the performance of different authentication servers. In most cases,
the default settings are sufficient.
To set the 802.1X authentication timeout timers:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Set the client timeout
timer.
dot1x timer supp-timeout
supp-timeout-value
The default is 30 seconds.
3.
Set the server
timeout timer.
dot1x timer server-timeout
server-timeout-value
The default is 100 seconds.
Configuring the online user handshake function
The online user handshake function checks the connectivity status of online 802.1X users. The
network access device sends handshake messages to online users at the interval specified by the
dot1x timer handshake-period command. If no response is received from an online user after the
maximum number of handshake attempts (set by the dot1x retry command) has been made, the
network access device sets the user in the offline state.
If iNode clients are deployed, you can also enable the online handshake security function to check
for 802.1X users that use illegal client software to bypass security inspection such as proxy detection
and dual network interface cards (NICs) detection. This function checks the authentication
information in client handshake messages. If a user fails the authentication, the network access
device logs the user off.
Configuration guidelines
Follow these guidelines when you configure the online user handshake function:
•
To use the online handshake security function, make sure the online user handshake function is
enabled. Hewlett Packard Enterprise recommends that you use the iNode client software and
IMC server to ensure the normal operation of the online user handshake security function.
•
If the network has 802.1X clients that cannot exchange handshake packets with the network
access device, disable the online user handshake function to prevent their connections from
being inappropriately torn down.
•
You must disable proxy detection before disabling the online user handshake function.
85
Configuration procedure
To configure the online user handshake function:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Set the handshake timer.
dot1x timer handshake-period
handshake-period-value
Optional.
3.
Enter Ethernet interface
view.
interface interface-type
interface-number
4.
Enable the online
handshake function.
dot1x handshake
5.
Enable the online
handshake security function.
dot1x handshake secure
The default is 15 seconds.
N/A
Optional.
By default, the function is
enabled.
Optional.
By default, the function is
disabled.
Enabling the proxy detection function
The proxy detection function prevents users from using an authenticated 802.1X client as a network
access proxy to bypass monitoring and accounting. When a user is detected accessing the network
through a proxy, the network access device can send traps to the network management system or
log the user off by sending an offline message.
Before you enable the proxy detection function, complete the following tasks:
•
Enable the online user handshake function (see "Configuring the online user handshake
function").
•
Deploy iNode client software in your network.
To configure the proxy detection function:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the proxy detection
function globally.
dot1x supp-proxy-check { logoff | trap }
By default, the
function is disabled.
•
3.
Enable the proxy detection
function on one or more
ports in system view or
Ethernet interface view.
•
In system view:
dot1x supp-proxy-check { logoff |
trap } interface interface-list
In Ethernet interface view:
a. interface interface-type
interface-number
By default, the
function is disabled.
b. dot1x supp-proxy-check { logoff |
trap }
NOTE:
If you configure the proxy detection function for a port in both system view and interface view, the
setting configured the last takes effect.
86
Configuring the authentication trigger function
The authentication trigger function enables the network access device to initiate 802.1X
authentication when 802.1X clients cannot initiate authentication.
This function provides the following types of authentication trigger:
•
Multicast trigger—Periodically multicasts Identity EAP-Request packets out of a port to detect
802.1X clients and trigger authentication.
•
Unicast trigger—Enables the network device to initiate 802.1X authentication when it receives
a data frame from an unknown source MAC address. The device sends a unicast Identity
EAP/Request packet to the unknown source MAC address, and retransmits the packet if it has
received no response within a period of time. This process continues until the maximum
number of request attempts set with the dot1x retry command (see "Setting the maximum
number of authentication request attempts") is reached.
The identity request timeout timer sets both the identity request interval for the multicast trigger and
the identity request timeout interval for the unicast trigger.
Configuration guidelines
Follow these guidelines when you configure the authentication trigger function:
•
Enable the multicast trigger on a port when the clients attached to the port cannot send
EAPOL-Start packets to initiate 802.1X authentication.
•
Enable the unicast trigger on a port if only a few 802.1X clients are attached to the port and
these clients cannot initiate authentication.
•
To avoid duplicate authentication packets, do not enable both triggers on a port.
Configuration procedure
To configure the authentication trigger function on a port:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Set the username
request timeout
timer.
dot1x timer tx-period
tx-period-value
Optional.
3.
Enter Ethernet
interface view.
interface interface-type
interface-number
4.
Enable an
authentication
trigger.
dot1x { multicast-trigger
| unicast-trigger }
The default setting is 30 seconds.
N/A
Required if you want to enable the unicast
trigger.
By default, the multicast trigger is enabled, and
the unicast trigger is disabled.
Specifying a mandatory authentication domain on
a port
You can place all 802.1X users in a mandatory authentication domain for authentication,
authorization, and accounting on a port. No user can use an account in any other domain to access
the network through the port. The implementation of a mandatory authentication domain enhances
the flexibility of 802.1X access control deployment.
87
To specify a mandatory authentication domain for a port:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter Ethernet interface
view.
interface interface-type
interface-number
N/A
3.
Specify a mandatory 802.1X
authentication domain on the
port.
dot1x mandatory-domain
domain-name
By default, no mandatory 802.1X
authentication domain is
specified.
Configuring the quiet timer
The quiet timer enables the network access device to wait a period of time before it can process any
authentication request from a client that has failed an 802.1X authentication.
You can set the quiet timer to a high value in a vulnerable network or a low value for quicker
authentication response.
To configure the quiet timer:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the quiet timer.
dot1x quiet-period
By default, the timer is disabled.
3.
Set the quiet timer.
dot1x timer quiet-period
quiet-period-value
Optional.
The default setting is 60 seconds.
Enabling the periodic online user
re-authentication function
Periodic online user re-authentication tracks the connection status of online users and updates the
authorization attributes assigned by the server, such as the ACL, VLAN, and user profile-based QoS.
The re-authentication interval is user configurable.
To enable the periodic online user re-authentication function:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Set the periodic
re-authentication timer.
dot1x timer reauth-period
reauth-period-value
3.
Enter Ethernet interface
view.
interface interface-type
interface-number
N/A
4.
Enable periodic online user
re-authentication.
dot1x re-authenticate
By default, the function is
disabled.
Optional.
The default setting is 3600
seconds.
The periodic online user re-authentication timer can also be set by the authentication server in the
session-timeout attribute. The server-assigned timer overrides the timer setting on the access device,
and enables periodic online user re-authentication, even if the function is not configured. Support for
88
the server assignment of re-authentication timer and the re-authentication timer configuration on the
server vary with servers.
The VLAN assignment status must be consistent before and after re-authentication. If the
authentication server has assigned a VLAN before re-authentication, it must also assign a VLAN at
re-authentication. If the authentication server has assigned no VLAN before re-authentication, it
must not assign one at re-authentication. Violation of either rule can cause the user to be logged off.
The VLANs assigned to an online user before and after re-authentication can be the same or
different.
If no critical VLAN is configured, RADIUS server unreachable can cause an online user being
re-authenticated to be logged off. If a critical VLAN is configured, the user remains online and in the
original VLAN.
Configuring an 802.1X guest VLAN
Follow these guidelines when you configure an 802.1X guest VLAN:
•
You can configure only one 802.1X guest VLAN on a port. The 802.1X guest VLANs on different
ports can be different.
•
Assign different IDs to the voice VLAN, the port VLAN, and the 802.1X guest VLAN on a port, so
the port can correctly process incoming VLAN tagged traffic.
•
You cannot specify a VLAN as both a super VLAN and an 802.1X guest VLAN. For more
information about super VLAN, see Layer 2—LAN Switching Configuration Guide.
Before configuring an 802.1X guest VLAN, complete the following tasks:
•
Create the VLAN to be specified as the 802.1X guest VLAN.
•
Enable 802.1X multicast trigger on the 802.1X-enabled port performs port-based access
control.
To configure an 802.1X guest VLAN:
Step
Command
Remarks
1.
system-view
N/A
Enter system view.
•
2.
Configure an 802.1X
guest VLAN for one or
more ports in system
view or Ethernet
interface view.
•
In system view:
dot1x guest-vlan guest-vlan-id
[ interface interface-list ]
In Ethernet interface view:
a. interface interface-type
interface-number
By default, no 802.1X guest
VLAN is configured on any
port.
b. dot1x guest-vlan guest-vlan-id
Configuring an Auth-Fail VLAN
Follow these guidelines when configuring an 802.1X Auth-Fail VLAN:
•
Assign different IDs to the port VLAN and the 802.1X Auth-Fail VLAN on a port, so the port can
correctly process VLAN tagged incoming traffic.
•
You can configure only one 802.1X Auth-Fail VLAN on a port. The 802.1X Auth-Fail VLANs on
different ports can be different.
•
Use Table 7 when configuring multiple security features on a port.
89
Table 7 Relationships of the 802.1X Auth-Fail VLAN with other features
Feature
Relationship description
Reference
Super VLAN
You cannot specify a VLAN as both a super
VLAN and an 802.1X Auth-Fail VLAN.
See Layer 2—LAN Switching
Configuration Guide.
Port intrusion protection
on a port that performs
MAC-based access
control
The 802.1X Auth-Fail VLAN function has
higher priority than the block MAC action
but lower priority than the shut down port
action of the port intrusion protection
feature.
See "Configuring port security."
Before configuring an 802.1X Auth-Fail VLAN, complete the following tasks:
•
Create the VLAN to be specified as the 802.1X Auth-Fail VLAN.
•
If the 802.1X-enabled port performs port-based access control, enable 802.1X multicast trigger.
•
If the 802.1X-enabled port performs MAC-based access control, configure the port as a hybrid
port, enable MAC-based VLAN on the port, and assign the port to the Auth-Fail VLAN as an
untagged member. For more information about the MAC-based VLAN function, see Layer
2—LAN Switching Configuration Guide.
To configure an Auth-Fail VLAN:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter Ethernet interface
view.
interface interface-type
interface-number
N/A
3.
Configure the Auth-Fail
VLAN on the port.
dot1x auth-fail vlan
authfail-vlan-id
By default, no Auth-Fail VLAN is configured.
Configuring an 802.1X critical VLAN
Follow these guidelines when configuring an 802.1X critical VLAN:
•
Assign different IDs to the voice VLAN, the port VLAN, and the 802.1X critical VLAN on a port,
so the port can correctly process VLAN tagged incoming traffic.
•
You can configure only one 802.1X critical VLAN on a port. The 802.1X critical VLANs on
different ports can be different.
•
You cannot specify a VLAN as both a super VLAN and an 802.1X critical VLAN. For information
about super VLANs, see Layer 2—LAN Switching Configuration Guide.
Before configuring an 802.1X critical VLAN, complete the following tasks:
•
Create the VLAN to be specified as a critical VLAN.
•
If the 802.1X-enabled port performs port-based access control, enable 802.1X multicast trigger
(dot1x multicast-trigger).
•
If the 802.1X-enabled port performs MAC-based access control, configure the port as a hybrid
port, enable MAC-based VLAN on the port, and assign the port to the Auth-Fail VLAN as an
untagged member. For more information about the MAC-based VLAN function, see Layer
2—LAN Switching Configuration Guide.
To configure an 802.1X critical VLAN:
Step
Command
Remarks
1.
system-view
N/A
Enter system view.
90
Step
Command
Remarks
2.
Enter Layer 2 Ethernet
interface view.
interface interface-type
interface-number
N/A
3.
Configure an 802.1X critical
VLAN on the port.
dot1x critical vlan vlan-id
By default, no critical VLAN is
configured.
4.
Configure the port to trigger
802.1X authentication on
detection of a reachable
authentication server for
users in the critical VLAN.
Optional.
dot1x critical recovery-action
reinitialize
By default, when a reachable
RADIUS server is detected, the
system removes the port or
802.1X users from the critical
VLAN without triggering
authentication.
Specifying supported domain name delimiters
By default, the access device supports the at sign (@) as the delimiter. You can also configure the
access device to accommodate 802.1X users that use other domain name delimiters.
The configurable delimiters include the at sign (@), back slash (\), and forward slash (/).
If an 802.1X username string contains multiple configured delimiters, the leftmost delimiter is the
domain name delimiter. For example, if you configure @, /, and \ as delimiters, the domain name
delimiter for the username string 123/22\@abc is the forward slash (/).
If a username string contains none of the delimiters, the access device authenticates the user in the
mandatory or default ISP domain. The access selects a domain delimiter from the delimiter set in this
order: @, /, and \.
To specify a set of domain name delimiters:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Specify a set of domain
name delimiters for 802.1X
users.
dot1x domain-delimiter string
By default, only the at sign (@)
delimiter is supported.
NOTE:
If you configure the access device to include the domain name in the username sent to the RADIUS
server, make sure the domain delimiter in the username can be recognized by the RADIUS server.
For username format configuration, see the user-name-format command in Security Command
Reference.
Displaying and maintaining 802.1X
Task
Command
Remarks
Display 802.1X session
information, statistics, or
configuration information of
specified or all ports.
display dot1x [ sessions | statistics ]
[ interface interface-list ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
91
Task
Command
Remarks
Clear 802.1X statistics.
reset dot1x statistics [ interface interface-list ]
Available in user view.
802.1X authentication configuration example
Network requirements
As shown in Figure 37, the Router performs 802.1X authentication for users that connect to port
GigabitEthernet 3/0/1. Implement MAC-based access control on the port, so the logoff of one user
does not affect other online 802.1X users.
Use RADIUS servers to perform authentication, authorization, and accounting for the 802.1X users.
If RADIUS authentication fails, perform local authentication on the Router. If RADIUS accounting
fails, the Router logs the user off.
Configure the host at 10.1.1.1/24 as the primary authentication and accounting servers, and the host
at 10.1.1.2/24 as the secondary authentication and accounting servers. Assign all users to the ISP
domain aabbcc.net, which accommodates up to 30 users.
Configure the shared key as name for packets between the Router and the authentication server,
and the shared key as money for packets between the Router and the accounting server.
Figure 37 Network diagram
Configuration procedure
1.
Configure the 802.1X client. If iNode is used, do not select the Carry version info option in the
client configuration. (Details not shown.)
2.
Configure the RADIUS servers and add user accounts for the 802.1X users. (Details not
shown.)
For information about the RADIUS commands used on the Router in this example, see Security
Command Reference.
3.
Assign an IP address for each interface on the Router. (Details not shown.)
4.
Configure user accounts for the 802.1X users on the Router:
# Add a local user with the username localuser, and password localpass in plaintext. (Make
sure the username and password are the same as those configured on the RADIUS server.)
<Router> system-view
[Router] local-user localuser
[Router-luser-localuser] service-type lan-access
92
[Router-luser-localuser] password simple localpass
# Configure the idle cut function to log off any online user that has been idled for 20 minutes.
[Router-luser-localuser] authorization-attribute idle-cut 20
[Router-luser-localuser] quit
5.
Configure a RADIUS scheme:
# Create the RADIUS scheme radius1 and enter its view.
[Router] radius scheme radius1
# Specify the IP addresses of the primary authentication and accounting RADIUS servers.
[Router-radius-radius1] primary authentication 10.1.1.1
[Router-radius-radius1] primary accounting 10.1.1.1
# Configure the IP addresses of the secondary authentication and accounting RADIUS servers.
[Router-radius-radius1] secondary authentication 10.1.1.2
[Router-radius-radius1] secondary accounting 10.1.1.2
# Specify the shared key between the Router and the authentication server.
[Router-radius-radius1] key authentication name
# Specify the shared key between the Router and the accounting server.
[Router-radius-radius1] key accounting money
# Exclude the ISP domain name from the username sent to the RADIUS servers.
[Router-radius-radius1] user-name-format without-domain
[Router-radius-radius1] quit
NOTE:
The Router must use the same username format as the RADIUS server. If the RADIUS server
includes the ISP domain name in the username, so must the Router.
6.
Configure the ISP domain:
# Create the ISP domain aabbcc.net and enter its view.
[Router] domain aabbcc.net
# Apply the RADIUS scheme radius1 to the ISP domain, and specify local authentication as the
secondary authentication method.
[Router-isp-aabbcc.net] authentication lan-access radius-scheme radius1 local
[Router-isp-aabbcc.net] authorization lan-access radius-scheme radius1 local
[Router-isp-aabbcc.net] accounting lan-access radius-scheme radius1 local
# Set the maximum number of concurrent users in the domain to 30.
[Router-isp-aabbcc.net] access-limit enable 30
# Configure the idle cut function to log off any online domain user that has been idle for 20
minutes.
[Router-isp-aabbcc.net] idle-cut enable 20
[Router-isp-aabbcc.net] quit
# Specify aabbcc.net as the default ISP domain. If a user does not provide any ISP domain
name, it is assigned to the default ISP domain.
[Router] domain default enable aabbcc.net
7.
Configure 802.1X:
# Enable 802.1X globally.
[Router] dot1x
# Enable 802.1X on port GigabitEthernet 3/0/1.
[Router] interface gigabitethernet 3/0/1
[Router-GigabitEthernet3/0/1] dot1x
93
[Router-GigabitEthernet3/0/1] quit
# Enable MAC-based access control on the port. (Optional. MAC-based access control is the
default setting.)
[Router] dot1x port-method macbased interface gigabitethernet 3/0/1
Verifying the configuration
Use the display dot1x interface gigabitethernet 3/0/1 command to verify the 802.1X configuration.
After an 802.1X user passes RADIUS authentication, you can use the display connection
command to view the user connection information. If the user fails RADIUS authentication, local
authentication is performed.
802.1X guest VLAN and VLAN assignment
configuration example
Network requirements
As shown in Figure 38, the host connected to port GigabitEthernet 3/0/2 of the Router must pass
802.1X authentication to access the Internet. GigabitEthernet 3/0/2 is in VLAN 1. The port
implements port-based access control.
The authentication server runs RADIUS and is in VLAN 2. The update server in VLAN 10 is for client
software download and upgrade.
If no user performs 802.1X authentication on GigabitEthernet 3/0/2 within a period of time, the
Router adds GigabitEthernet 3/0/2 to its guest VLAN, VLAN 10. The host and the update server are
both in VLAN 10 and the host can access the update server and download the 802.1X client
software.
After the host passes 802.1X authentication, the network Router assigns the host to VLAN 5 where
GigabitEthernet 3/0/3 is. The host can access the Internet.
94
Figure 38 Network diagram
Configuration procedure
The following configuration procedure covers most AAA/RADIUS configuration commands on the
Router. The configuration on the 802.1X client and RADIUS server are not shown. For more
information about AAA/RADIUS configuration commands, see Security Command Reference.
1.
Make sure the 802.1X client can update its IP address after the access port is assigned to the
guest VLAN or a server-assigned VLAN. (Details not shown.)
2.
Configure the RADIUS server to provide authentication, authorization, and accounting services.
Configure user accounts and server-assigned VLAN, VLAN 5 in this example. (Details not
shown.)
3.
Create VLANs, and assign ports to the VLANs:
<Router> system-view
[Router] vlan 1
[Router-vlan1] port gigabitethernet 3/0/2
[Router-vlan1] quit
[Router] vlan 10
[Router-vlan10] port gigabitethernet 3/0/1
[Router-vlan10] quit
[Router] vlan 2
[Router-vlan2] port gigabitethernet 3/0/4
[Router-vlan2] quit
[Router] vlan 5
[Router-vlan5] port gigabitethernet 3/0/3
[Router-vlan5] quit
4.
Configure a RADIUS scheme:
95
# Configure RADIUS scheme 2000 and enter its view.
<Router> system-view
[Router] radius scheme 2000
# Specify primary and secondary authentication and accounting servers. Set the shared key to
abc for authentication and accounting packets.
[Router-radius-2000] primary authentication 10.11.1.1 1812
[Router-radius-2000] primary accounting 10.11.1.1 1813
[Router-radius-2000] key authentication abc
[Router-radius-2000] key accounting abc
# Exclude the ISP domain name from the username sent to the RADIUS server.
[Router-radius-2000] user-name-format without-domain
[Router-radius-2000] quit
5.
Configure an ISP domain:
# Create ISP domain bbb and enter its view.
[Router] domain bbb
# Apply RADIUS scheme 2000 to the ISP domain for authentication, authorization, and
accounting.
[Router-isp-bbb] authentication lan-access radius-scheme 2000
[Router-isp-bbb] authorization lan-access radius-scheme 2000
[Router-isp-bbb] accounting lan-access radius-scheme 2000
[Router-isp-bbb] quit
6.
Configure 802.1X:
# Enable 802.1X globally.
[Router] dot1x
# Enable 802.1X for port GigabitEthernet 3/0/2.
[Router] interface gigabitethernet 3/0/2
[Router-GigabitEthernet3/0/2] dot1x
# Implement port-based access control on the port.
[Router-GigabitEthernet3/0/2] dot1x port-method portbased
# Set the port authorization mode to auto. This step is optional. By default, the port is in auto
mode.
[Router-GigabitEthernet3/0/2] dot1x port-control auto
[Router-GigabitEthernet3/0/2] quit
# Set VLAN 10 as the 802.1X guest VLAN for port GigabitEthernet 3/0/2.
[Router] dot1x guest-vlan 10 interface gigabitethernet 3/0/2
Verifying the configuration
Use the display dot1x interface gigabitethernet 3/0/2 command to verify the 802.1X guest VLAN
configuration on GigabitEthernet 3/0/2. If no user passes authentication on the port within a specific
period of time, use the display vlan 10 command to verify whether GigabitEthernet 3/0/2 is assigned
to VLAN 10.
After a user passes authentication, you can use the display interface gigabitethernet 3/0/2
command to verity that port GigabitEthernet 3/0/2 has been added to VLAN 5.
96
802.1X with ACL assignment configuration
example
Network requirements
As shown in Figure 39, the host at 192.168.1.10 connects to port GigabitEthernet 3/0/1 of Router.
Perform 802.1X authentication on the port. Use the RADIUS server at 10.1.1.1 as the authentication
and authorization server and the RADIUS server at 10.1.1.2 as the accounting server. Assign an
ACL to GigabitEthernet 3/0/1 to deny the access of 802.1X users to the FTP server at 10.0.0.1/24 on
weekdays during business hours from 8:00 to 18:00.
Figure 39 Network diagram
Configuration procedure
The following configuration procedure provides the major AAA and RADIUS configuration on the
Router. The configuration procedures on the 802.1X client and RADIUS server are beyond the scope
of this configuration example. For information about AAA and RADIUS configuration commands, see
Security Command Reference.
1.
Configure 802.1X client. Make sure the client is able to update its IP address after the access
port is assigned to the 802.1X guest VLAN or a server-assigned VLAN. (Details not shown.)
2.
Configure the RADIUS servers, user accounts, and authorization ACL, ACL 3000 in this
example. (Details not shown.)
3.
Configure the Router:
# Assign IP addresses to interfaces. (Details not shown.)
# Configure the RADIUS scheme.
<Router> system-view
[Router] radius scheme 2000
[Router-radius-2000] primary authentication 10.1.1.1 1812
[Router-radius-2000] primary accounting 10.1.1.2 1813
[Router-radius-2000] key authentication abc
[Router-radius-2000] key accounting abc
[Router-radius-2000] user-name-format without-domain
[Router-radius-2000] quit
# Create an ISP domain and specify the RADIUS scheme 2000 as the default AAA schemes for
the domain.
[Router] domain 2000
97
[Router-isp-2000] authentication default radius-scheme 2000
[Router-isp-2000] authorization default radius-scheme 2000
[Router-isp-2000] accounting default radius-scheme 2000
[Router-isp-2000] quit
# Configure a time range ftp for the weekdays from 8:00 to 18:00.
[Router] time-range ftp 8:00 to 18:00 working-day
# Configure ACL 3000 to deny packets destined for the FTP server at 10.0.0.1 on the weekdays
during business hours.
[Router] acl number 3000
[Router-acl-adv-3000] rule 0 deny ip destination 10.0.0.1 0 time-range ftp
[Router-acl-adv-3000] quit
# Enable 802.1X globally.
[Router] dot1x
# Enable 802.1X on port GigabitEthernet 3/0/1.
[Router] interface gigabitethernet 3/0/1
[Router-GigabitEthernet3/0/1] dot1x
Verifying the configuration
# Use the user account to pass authentication, and then ping the FTP server on any weekday during
business hours.
C:\>ping 10.0.0.1
Pinging 10.0.0.1 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 10.0.0.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
The output shows that ACL 3000 has taken effect on the user, and the user cannot access the FTP
server.
98
Configuring EAD fast deployment
Overview
Endpoint Admission Defense (EAD) is an integrated endpoint access control solution. EAD enables
the security client, security policy server, Router, and third-party server to work together to improve
the threat defensive capability of a network. If a terminal device seeks to access an EAD network, it
must have an EAD client, which performs 802.1X authentication.
EAD fast deployment enables the Router to redirect a user seeking to access the network to
download and install EAD client. This function eliminates the tedious job of the administrator to
deploy EAD clients.
NOTE:
EAD fast deployment is supported only on a SAP module that is operating in bridge mode.
EAD fast deployment is implemented by the following functions:
•
Free IP
•
URL redirection
Free IP
A free IP is a freely accessible network segment, which has a limited set of network resources such
as software and DHCP servers. An unauthenticated user can access only this segment to perform
operations to ensure security strategy compliance. For example, the user can download EAD client
from a software server or obtain a dynamic IP address from a DHCP server.
URL redirection
If an unauthenticated 802.1X user is using a web browser to access the network, the EAD fast
deployment function redirects the user to a specific URL, for example, the EAD client software
download page.
The server that provides the URL must be on the free IP accessible to unauthenticated users.
Configuration prerequisites
•
Enable 802.1X globally.
•
Enable 802.1X on the port, and set the port authorization mode to auto.
Configuring a free IP
When a free IP is configured, the EAD fast deployment is enabled. To allow a user to obtain a
dynamic IP address before passing 802.1X authentication, make sure the DHCP server is on the
free IP segment.
When global MAC authentication or port security is enabled, the free IP does not take effect.
If you use free IP, guest VLAN, and Auth-Fail VLAN features together, make sure that the free IP
segments are in both guest VLAN and Auth-Fail VLAN. Users can access only the free IP segments.
99
To configure a free IP:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Configure a free IP.
dot1x free-ip ip-address
{ mask-address | mask-length }
By default, no free IP is
configured.
Configuring the redirect URL
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Configure the redirect
URL.
dot1x url url-string
By default, no redirect URL is configured.
The redirect URL must be on the free IP
subnet.
Setting the EAD rule timer
EAD fast deployment automatically creates an ACL-based EAD rule to open access to the redirect
URL for each redirected user seeking to access the network. EAD rules are implemented by using
ACL resources. The EAD rule timer sets the lifetime of each ACL rule. When the timer expires or the
user passes authentication, the rule is removed. If users fail to download EAD client or fail to pass
authentication before the timer expires, they must reconnect to the network to access the free IP.
To prevent ACL rule resources from being used up, you can shorten the timer when the amount of
EAD users is large.
To set the EAD rule timer:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Set the EAD rule timer.
dot1x timer ead-timeout
ead-timeout-value
The default timer is 30 minutes.
Displaying and maintaining EAD fast deployment
Task
Command
Remarks
Display 802.1X session
information, statistics, or
configuration information.
display dot1x [ sessions | statistics ]
[ interface interface-list ] [ | { begin |
exclude | include }
regular-expression ]
Available in any view.
100
EAD fast deployment configuration example
Network requirements
As shown in Figure 40, the hosts on the intranet 192.168.1.0/24 are attached to port GigabitEthernet
3/0/1 of Router, and they use DHCP to obtain IP addresses.
Deploy EAD solution for the intranet so that all hosts must pass 802.1X authentication to access the
network.
To allow all intranet users to install and update 802.1X client program from a web server, configure
the following:
•
Allow unauthenticated users to access the segment of 192.168.2.0/24, and to obtain IP address
on the segment of 192.168.1.0/24 through DHCP.
•
Redirect unauthenticated users to a preconfigured web page when the users use a web
browser to access any external network except 192.168.2.0/24. The web page allows users to
download the 802.1X client program.
•
Allow authenticated 802.1X users to access the network.
Figure 40 Network diagram
In addition to the configuration on the Router, complete the following tasks:
•
Configure the DHCP server so that the host can obtain an IP address on the segment of
192.168.1.0/24.
•
Configure the web server so that users can log in to the web page to download 802.1X clients.
•
Configure the authentication server to provide authentication, authorization, and accounting
services.
Configuration procedure
1.
Configure an IP address for each interface. (Details not shown.)
2.
Configure DHCP relay:
# Enable DHCP.
101
<Router> system-view
[Router] dhcp enable
# Configure a DHCP server for a DHCP server group.
[Router] dhcp relay server-group 1 ip 192.168.2.2
# Enable the relay agent on VLAN interface 2.
[Router] interface vlan-interface 2
[Router-Vlan-interface2] dhcp select relay
# Correlate VLAN interface 2 to the DHCP server group.
[Router-Vlan-interface2] dhcp relay server-select 1
[Router-Vlan-interface2] quit
3.
Configure a RADIUS scheme and an ISP domain.
For more information about configuration procedure, see "802.1X authentication configuration
example."
4.
Configure 802.1X:
# Configure the free IP.
[Router] dot1x free-ip 192.168.2.0 24
# Configure the redirect URL for client software download.
[Router] dot1x url http://192.168.2.3
# Enable 802.1X globally.
[Router] dot1x
# Enable 802.1X on the port.
[Router] interface gigabitethernet 3/0/1
[Router-GigabitEthernet3/0/1] dot1x
Verifying the configuration
Use the display dot1x command to display the 802.1X configuration. After the host obtains an IP
address from a DHCP server, use the ping command from the host to ping an IP address on the
network segment specified by free IP.
C:\>ping 192.168.2.3
Pinging 192.168.2.3 with 32 bytes of data:
Reply from 192.168.2.3: bytes=32 time<1ms TTL=128
Reply from 192.168.2.3: bytes=32 time<1ms TTL=128
Reply from 192.168.2.3: bytes=32 time<1ms TTL=128
Reply from 192.168.2.3: bytes=32 time<1ms TTL=128
Ping statistics for 192.168.2.3:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
The output shows that you can access that segment before passing 802.1X authentication. If you
use a web browser to access any external website beyond the free IP segments, you are redirected
to the web server, which provides the 802.1X client software download service. Enter the external
website address in dotted decimal notation, for example, 3.3.3.3 or http://3.3.3.3, in the address bar.
102
Troubleshooting EAD fast deployment
Web browser users cannot be correctly redirected
Symptom
Unauthenticated users are not redirected to the specified redirect URL after they enter external
website addresses in their web browsers.
Analysis
Redirection will not happen for one of the following reasons:
•
The address is in the string format. The operating system of the host regards the string as a
website name and tries to resolve it. If the resolution fails, the operating system sends an ARP
request, but the target address is not in the dotted decimal notation. The redirection function
does redirect this kind of ARP request.
•
The address is within a free IP segment. No redirection will take place, even if no host is present
with the address.
•
The redirect URL is not in a free IP segment, no server is using the redirect URL, or the server
with the URL does not provide web services.
Solution
1.
Enter a dotted decimal IP address that is not in any free IP segment.
2.
Ensure that the network Router and the server are correctly configured.
103
Configuring MAC authentication
MAC authentication is available only for SAP modules that are operating in bridge mode.
Overview
MAC authentication controls network access by authenticating source MAC addresses on a port. It
does not require client software and users do not need to enter a username and password for
network access. The device initiates a MAC authentication process when it detects an unknown
source MAC address on a MAC authentication enabled port. If the MAC address passes
authentication, the user can access authorized network resources. If the authentication fails, the
device marks the MAC address as a silent MAC address, drops the packet, and starts a quiet timer.
The device drops all subsequent packets from the MAC address within the quiet time. The quiet
mechanism avoids repeated authentication during a short time.
NOTE:
If the MAC address that has failed authentication is a static MAC address or a MAC address that
has passed any security authentication, the device does not mark it as a silent address.
User account policies
MAC authentication supports the following user account policies:
•
One MAC-based user account for each user. The access device uses the source MAC
addresses in packets as the usernames and passwords of users for MAC authentication. This
policy is suitable for an insecure environment.
•
One shared user account for all users. You specify one username and password, which are not
necessarily a MAC address, for all MAC authentication users on the access device. This policy
is suitable for a secure environment.
Authentication methods
You can perform MAC authentication on the access device (local authentication) or through a
RADIUS server.
Suppose a source MAC unknown packet arrives at a MAC authentication enabled port.
Local authentication:
•
If MAC-based accounts are used, the access device uses the source MAC address of the
packet as the username and password to search its local account database for a match.
•
If a shared account is used, the access device uses the shared account username and
password to search its local account database for a match.
RADIUS authentication:
•
If MAC-based accounts are used, the access device sends the source MAC address as the
username and password to the RADIUS server for authentication.
•
If a shared account is used, the access device sends the shared account username and
password to the RADIUS server for authentication.
For more information about configuring local authentication and RADIUS authentication, see
"Configuring AAA."
104
MAC authentication timers
MAC authentication uses the following timers:
•
Offline detect timer—Sets the interval that the device waits for traffic from a user before it
regards the user idle. If a user connection has been idle for two consecutive intervals, the
device logs the user out and stops accounting for the user.
•
Quiet timer—Sets the interval that the device must wait before it can perform MAC
authentication for a user that has failed MAC authentication. All packets from the MAC address
are dropped during the quiet time. This quiet mechanism prevents repeated authentication from
affecting system performance.
•
Server timeout timer—Sets the interval that the access device waits for a response from a
RADIUS server before it regards the RADIUS server unavailable. If the timer expires during
MAC authentication, the user cannot access the network.
Using MAC authentication with other features
VLAN assignment
You can specify a VLAN in the user account for a MAC authentication user to control its access to
network resources. After the user passes MAC authentication, the authentication server, either the
local access device or a RADIUS server, assigns the VLAN to the port as the default VLAN. After the
user logs off, the initial default VLAN, or the default VLAN configured before any VLAN is assigned
by the authentication server, restores. If the authentication server assigns no VLAN, the initial default
VLAN applies.
A hybrid port is always assigned to a server-assigned VLAN as an untagged member. After the
assignment, do not re-configure the port as a tagged member in the VLAN.
If MAC-based VLAN is enabled on a hybrid port, the device maps the server-assigned VLAN to the
MAC address of the user. The default VLAN of the hybrid port does not change.
ACL assignment
You can specify an ACL in the user account for a MAC authentication user to control its access to
network resources. After the user passes MAC authentication, the authentication server, either the
local access device or a RADIUS server, assigns the ACL to the access port to filter the traffic from
this user. You must configure the ACL on the access device for the ACL assignment function. You
can change ACL rules while the user is online.
Configuration task list
Task
Remarks
Basic configuration for MAC authentication:
•
Configuring MAC authentication globally
•
Configuring MAC authentication on a port
Required.
Specifying a MAC authentication domain
Optional.
105
Basic configuration for MAC authentication
Before you perform basic configuration for MAC authentication, complete the following tasks:
•
Create and configure an authentication domain, also called "an ISP domain."
•
For local authentication, create local user accounts, and specify the lan-access service for the
accounts.
•
For RADIUS authentication, check that the device and the RADIUS server can reach each other,
and create user accounts on the RADIUS server.
If you are using MAC-based accounts, make sure the username and password for each account is
the same as the MAC address of the MAC authentication users.
Configuring MAC authentication globally
MAC authentication can take effect on a port only when it is enabled globally and on the port.
To configure MAC authentication globally:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable MAC
authentication
globally.
mac-authentication
Disabled by default.
Configure MAC
authentication
timers.
mac-authentication timer
{ offline-detect
offline-detect-value | quiet
quiet-value | server-timeout
server-timeout-value }
Optional.
3.
4.
Configure the
properties of MAC
authentication
user accounts.
mac-authentication
user-name-format { fixed
[ account name ] [ password
{ cipher | simple } password ] |
mac-address [ { with-hyphen |
without-hyphen } [ lowercase |
uppercase ] ] }
By default, the offline detect timer is 300
seconds, the quiet timer is 60 seconds,
and the server timeout timer is 100
seconds.
Optional.
By default, the username and password for
a MAC authentication user account must
be a MAC address (without hyphens) in
lower case.
NOTE:
When global MAC authentication is enabled, the EAD fast deployment function cannot take effect.
For more information, see "Configuring 802.1X."
Configuring MAC authentication on a port
You cannot add a MAC authentication-enabled port to a link aggregation group, or enable MAC
authentication on a port already in a link aggregation group.
To configure MAC authentication on a port:
Step
Command
Remarks
1.
system-view
N/A
Enter system view.
106
Step
Command
•
2.
Enable MAC authentication in
system view or interface view.
•
In system view:
mac-authentication
interface interface-list
In interface view:
a. interface interface-type
interface-number
Remarks
Disabled by default.
Enable MAC authentication for
ports in bulk in system view or
an individual port in interface
view.
b. mac-authentication
3.
Set the maximum number of
concurrent MAC authentication
users allowed on a port.
mac-authentication max-user
user-number
Optional.
By default, the maximum
number is 1024.
NOTE:
When both (and only both) 802.1X authentication and MAC authentication are enabled on a port,
the device waits for 30 seconds before performing MAC authentication for a non-802.1X user that
first accesses the network from the port.
Specifying a MAC authentication domain
By default, MAC authentication users are in the system default authentication domain. To implement
different access policies for users, you can specify authentication domains for MAC authentication
users in the following ways:
•
Specify a global authentication domain in system view. This domain setting applies to all ports.
•
Specify an authentication domain for an individual port in interface view.
MAC authentication chooses an authentication domain for users on a port in the following order: the
port-specific domain, the global domain, and the default domain. For more information about
authentication domains, see "Configuring AAA."
To specify an authentication domain for MAC authentication users:
Step
Command
Remarks
1.
system-view
N/A
Enter system view.
•
2.
Specify an authentication
domain for MAC
authentication users in
system view or interface
view.
•
In system view:
mac-authentication domain
domain-name
In interface view:
a. interface interface-type
interface-number
By default, the system default
authentication domain is used for
MAC authentication users.
b. mac-authentication
domain domain-name
Displaying and maintaining MAC authentication
Task
Command
Remarks
Display MAC authentication
information.
display mac-authentication
[ interface interface-list ] [ | { begin |
exclude | include }
regular-expression ]
Available in any view.
107
Task
Command
Remarks
Clear MAC authentication
statistics.
reset mac-authentication
statistics [ interface interface-list ]
Available in user view.
MAC authentication configuration examples
Local MAC authentication configuration example
Network requirements
In the network in Figure 41, perform local MAC authentication on port GigabitEthernet 3/0/1 to
control Internet access.
•
All users belong to domain aabbcc.net.
•
Local users use their MAC addresses as the usernames and passwords for MAC authentication.
The MAC addresses are hyphen separated and in lower case.
•
The router detects whether a user has gone offline every 180 seconds. When a user fails
authentication, the router does not authenticate the user within 180 seconds.
Figure 41 Network diagram
Configuration procedure
# Add a local user account, set both the username and password to 00-e0-fc-12-34-56, the MAC
address of the user host, and enable LAN access service for the account.
<Router> system-view
[Router] local-user 00-e0-fc-12-34-56
[Router-luser-00-e0-fc-12-34-56] password simple 00-e0-fc-12-34-56
[Router-luser-00-e0-fc-12-34-56] service-type lan-access
[Router-luser-00-e0-fc-12-34-56] quit
# Configure ISP domain aabbcc.net to perform local authentication for LAN access users.
[Router] domain aabbcc.net
[Router-isp-aabbcc.net] authentication lan-access local
[Router-isp-aabbcc.net] quit
# Enable MAC authentication globally.
[Router] mac-authentication
# Enable MAC authentication on port GigabitEthernet 3/0/1.
[Router] mac-authentication interface gigabitethernet 3/0/1
# Specify the ISP domain for MAC authentication.
[Router] mac-authentication domain aabbcc.net
# Set the MAC authentication timers.
[Router] mac-authentication timer offline-detect 180
[Router] mac-authentication timer quiet 180
108
# Configure MAC authentication to use MAC-based accounts. The MAC address usernames and
passwords are hyphenated and in lowercase.
[Router] mac-authentication user-name-format mac-address with-hyphen lowercase
Verifying the configuration
# Display MAC authentication settings and statistics.
<Router> display mac-authentication
MAC address authentication is enabled.
User name format is MAC address in lowercase, like xx-xx-xx-xx-xx-xx
Fixed username:mac
Fixed password:not configured
Offline detect period is 180s
Quiet period is 180s.
Server response timeout value is 100s
The max allowed user number is 2048 per slot
Current user number amounts to 1
Current domain is aabbcc.net
Silent Mac User info:
MAC Addr
From Port
Port Index
Gigabitethernet3/0/1 is link-up
MAC address authentication is enabled
Authenticate success: 1, failed: 0
Max number of on-line users is 1024
Current online user number is 1
MAC Addr
Authenticate state
00e0-fc12-3456
MAC_AUTHENTICATOR_SUCCESS
Auth Index
52
# After the user passes authentication, use the display connection command to display the online
user information.
<Router> display connection
Slot:
3
Index=52
, Username=00-15-e9-43-82-73@aabbcc.net
IP=N/A
IPv6=N/A
MAC=00e0-fc12-3456
Total 1 connection(s) matched on slot 3.
Total 1 connection(s) matched.
RADIUS-based MAC authentication configuration example
Network requirements
As shown in Figure 42, a host connects to port GigabitEthernet 3/0/1 on the router. The router uses
RADIUS servers for authentication, authorization, and accounting.
Perform MAC authentication on port GigabitEthernet 3/0/1 to control Internet access. Make sure the
following requirements are met:
•
The router detects whether a user has gone offline every 180 seconds. If a user fails
authentication, the router does not authenticate the user within 180 seconds.
•
All MAC authentication users belong to ISP domain 2000 and share the user account aaa with
password 123456.
109
Figure 42 Network diagram
RADIUS servers
Auth:10.1.1.1
Acct:10.1.1.2
GE3/0/1
Host
IP network
Router
Configuration procedure
1.
Make sure the RADIUS server and the router can reach each other.
2.
Create a shared account for MAC authentication users on the RADIUS server, and set the
username aaa and password 123456 for the account. (Details not shown.)
3.
Configure the router:
# Configure a RADIUS scheme.
<Router> system-view
[Router] radius scheme 2000
[Router-radius-2000] primary authentication 10.1.1.1 1812
[Router-radius-2000] primary accounting 10.1.1.2 1813
[Router-radius-2000] key authentication abc
[Router-radius-2000] key accounting abc
[Router-radius-2000] user-name-format without-domain
[Router-radius-2000] quit
# Apply the RADIUS scheme to ISP domain 2000 for authentication, authorization, and
accounting.
[Router] domain 2000
[Router-isp-2000] authentication default radius-scheme 2000
[Router-isp-2000] authorization default radius-scheme 2000
[Router-isp-2000] accounting default radius-scheme 2000
[Router-isp-2000] quit
# Enable MAC authentication globally.
[Router] mac-authentication
# Enable MAC authentication on port GigabitEthernet 3/0/1.
[Router] mac-authentication interface gigabitethernet 3/0/1
# Specify the ISP domain for MAC authentication.
[Router] mac-authentication domain 2000
# Set the MAC authentication timers.
[Router] mac-authentication timer offline-detect 180
[Router] mac-authentication timer quiet 180
# Specify username aaa and password 123456 in plain text for the account shared by MAC
authentication users.
[Router] mac-authentication user-name-format fixed account aaa password simple 123456
Verifying the configuration
# Display MAC authentication settings and statistics.
110
<Router> display mac-authentication
MAC address authentication is enabled.
User name format is fixed account
Fixed username:aaa
Fixed password:******
Offline detect period is 180s
Quiet period is 180s.
Server response timeout value is 100s
The max allowed user number is 2048 per slot
Current user number amounts to 1
Current domain is 2000
Silent Mac User info:
MAC ADDR
From Port
Port Index
Gigabitethernet3/0/1 is link-up
MAC address authentication is enabled
Authenticate success: 1, failed: 0
Max number of on-line users is 1024
Current online user number is 1
MAC ADDR
Authenticate state
00e0-fc12-3456
MAC_AUTHENTICATOR_SUCCESS
Auth Index
52
# After a user passes MAC authentication, use the display connection command to display online
user information.
<Router> display connection
Slot:
3
Index=52
, Username=aaa@2000
IP=N/A
IPv6=N/A
MAC=00e0-fc12-3456
Total 1 connection(s) matched on slot 3.
Total 1 connection(s) matched.
ACL assignment configuration example
Network requirements
As shown in Figure 43, a host connects to port GigabitEthernet 3/0/1 of the router, and the router
uses RADIUS servers to perform authentication, authorization, and accounting.
Perform MAC authentication on port GigabitEthernet 3/0/1 to control Internet access. Make sure an
authenticated user can access the Internet but not the FTP server at 10.0.0.1.
Use MAC-based user accounts for MAC authentication users. The MAC addresses are hyphen
separated and in lower case.
111
Figure 43 Network diagram
RADIUS servers
Auth:10.1.1.1
Acct:10.1.1.2
GE3/0/1
Host
Internet
Router
FTP server
IP: 192.168.1.10/24
MAC: 00-e0-fc-12-34-56
10.0.0.1/24
Configuration procedure
1.
Make sure the RADIUS server and the router can reach each other.
2.
Configure the ACL assignment on the router:
Configure ACL 3000 to deny packets destined for 10.0.0.1.
<Sysname> system-view
[Sysname] acl number 3000
[Sysname-acl-adv-3000] rule 0 deny ip destination 10.0.0.1 0
[Sysname-acl-adv-3000] quit
3.
Configure RADIUS-based MAC authentication on the router:
# Configure a RADIUS scheme.
[Sysname] radius scheme 2000
[Sysname-radius-2000] primary authentication 10.1.1.1 1812
[Sysname-radius-2000] primary accounting 10.1.1.2 1813
[Sysname-radius-2000] key authentication simple abc
[Sysname-radius-2000] key accounting simple abc
[Sysname-radius-2000] user-name-format without-domain
[Sysname-radius-2000] quit
# Apply the RADIUS scheme to an ISP domain for authentication, authorization, and
accounting.
[Sysname] domain 2000
[Sysname-isp-2000] authentication default radius-scheme 2000
[Sysname-isp-2000] authorization default radius-scheme 2000
[Sysname-isp-2000] accounting default radius-scheme 2000
[Sysname-isp-2000] quit
# Enable MAC authentication globally.
[Sysname] mac-authentication
# Specify the ISP domain for MAC authentication.
[Sysname] mac-authentication domain 2000
# Configure the device to use MAC-based user accounts, and the MAC addresses are hyphen
separated and in lowercase.
[Sysname] mac-authentication user-name-format mac-address with-hyphen lowercase
# Enable MAC authentication for port GigabitEthernet 3/0/1.
[Sysname] interface gigabitethernet 3/0/1
[Sysname-GigabitEthernet3/0/1] mac-authentication
112
4.
Configure the RADIUS servers:
Add a user account with 00-e0-fc-12-34-56 as both the username and password on the
RADIUS server, and specify ACL 3000 as the authorization ACL for the user account. (Details
not shown.)
Verifying the configuration
# After the host passes authentication, use the display connection command on the router to
display online user information.
[Sysname-GigabitEthernet3/0/1] display connection
Slot:
3
Index=52
, Username=00-e0-fc-12-34-56@2000
IP=N/A
IPv6=N/A
MAC=00e0-fc12-3456
Total 1 connection(s) matched on slot 3.
Total 1 connection(s) matched.
# Ping the FTP server from the host. The output shows that the ACL 3000 has been assigned to port
GigabitEthernet 3/0/1 to deny access to the FTP server.
C:\>ping 10.0.0.1
Pinging 10.0.0.1 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 10.0.0.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
113
Configuring portal authentication
Portal on VLAN interfaces does not support accounting. Portal on other types of interfaces supports
accounting.
Overview
Portal authentication helps control access to the Internet. Portal authentication is also called "Web
authentication." A website implementing portal authentication is called a portal website.
With portal authentication, an access device redirects all users to the portal authentication page. All
users can access the free services provided on the portal website. However, to access the Internet,
a user must pass portal authentication.
A user can access a known portal website and enter a username and password for authentication.
This authentication mode is called active authentication. There is another authentication mode,
forced authentication, in which the access device forces a user who is trying to access the Internet
through HTTP to log on to a portal website for authentication.
The portal feature provides the flexibility for ISPs to manage services. A portal website can, for
example, present advertisements and deliver community and personalized services. In this way,
broadband network providers, equipment vendors, and content service providers form an industrial
ecological system.
Extended portal functions
By forcing patching and anti-virus policies, extended portal functions help users to defend against
viruses. Portal authentication supports the following extended functions:
•
Security check—Works after identity authentication succeeds to check whether the required
anti-virus software, virus definition file, and operating system patches are installed, and whether
there is any unauthorized software installed on the user host.
•
Resource access restriction—Allows users passing identity authentication to access only
network resources in the quarantined area, such as the anti-virus server and the patch server.
Only users passing both identity authentication and security check can access restricted
network resources.
Portal system components
A typical portal system comprises these basic components: authentication client, access device,
portal server, authentication/accounting server, and security policy server.
114
Figure 44 Portal system components
Authentication client
Authentication client
Security policy server
Portal server
Access device
Authentication/accounting
server
Authentication client
Authentication client
An authentication client is an entity seeking access to network resources. It is typically an end-user
terminal such as a PC. A client can use a browser or portal client software for portal authentication.
Client security check is implemented through communications between the client and the security
policy server.
To implement security check, the client must be the iNode client.
Access device
Access devices control user access. An access device can be a switch or router that provides the
following functions:
•
Redirecting all HTTP requests from unauthenticated users to the portal server.
•
Interacting with the portal server, the security policy server, and the authentication/accounting
server for identity authentication, security check, and accounting.
•
Allowing users who have passed identity authentication and security check to access granted
Internet resources.
Portal server
A portal server listens to authentication requests from authentication clients and exchanges client
authentication information with the access device. It provides free portal services and pushes Web
authentication pages to users.
A portal server can be an entity independent of the access device or an entity embedded in the
access device. In this document, the term "portal server" refers to an independent portal server, and
the term "local portal server" refers to an embedded portal server.
NOTE:
The router does not support local portal server.
Authentication/accounting server
An authentication/accounting server implements user authentication and accounting through
interaction with the access device.
Only a RADIUS server can serve as the remote authentication/accounting server in a portal system.
115
Security policy server
A security policy server interacts with authentication clients and access devices for security check
and resource authorization.
The components of a portal system interact as follows:
1.
When an unauthenticated user enters a website address in the browser's address bar to access
the Internet, an HTTP request is created and sent to the access device. The access device then
redirects the HTTP request to the portal server's Web authentication homepage. For extended
portal functions, authentication clients must run the portal client software.
2.
On the authentication homepage/authentication dialog box, the user enters and submits the
authentication information, which the portal server then transfers to the access device.
3.
Upon receipt of the authentication information, the access device communicates with the
authentication/accounting server for authentication and accounting.
4.
After successful authentication, the access device checks whether there is a corresponding
security policy for the user. If not, it allows the user to access the Internet. Otherwise, the client
communicates with the access device and the security policy server for security check. If the
client passes security check, the security policy server authorizes the user to access the
Internet resources.
NOTE:
Portal authentication supports NAT traversal whether it is initiated by a Web client or an iNode
client. When the portal authentication client is on a private network but the portal server is on a
public network, NAT on the access device does not affect portal authentication. However, in such a
case, Hewlett Packard Enterprise recommends using an interface's public IP address as the source
address of outgoing portal packets.
Portal authentication modes
You can enable Layer 3 authentication on an access device's Layer 3 interfaces that connect
authentication clients. Portal authentication performed on a Layer 3 interface can be direct
authentication, re-DHCP authentication, or cross-subnet authentication. In direct authentication and
re-DHCP authentication, no Layer 3 forwarding devices exist between the authentication client and
the access device. In cross-subnet authentication, Layer 3 forwarding devices may exist between
the authentication client and the access device.
•
Direct authentication
Before authentication, a user manually configures a public IP address or directly obtains a
public IP address through DHCP, and can access only the portal server and predefined free
websites. After passing authentication, the user can access the network resources. The
process of direct authentication is simpler than that of re-DHCP authentication.
•
Re-DHCP authentication
Before authentication, a user gets a private IP address through DHCP and can access only the
portal server and predefined free websites. After passing authentication, the user is allocated a
public IP address and can access the network resources. No public IP address is allocated to
those who fail authentication. This solves the IP address planning and allocation problem. For
example, a service provider can allocate public IP addresses to broadband users only when
they access networks beyond the residential community network.
The local portal server does not support re-DHCP portal authentication.
•
Cross-subnet authentication
Cross-subnet authentication is similar to direct authentication, but it allows Layer 3 forwarding
devices to be present between the authentication client and the access device.
In direct authentication, re-DHCP authentication, and cross-subnet authentication, the client's
IP address is used for client identification. After a client passes authentication, the access
116
device generates an ACL for the client based on the client's IP address to permit packets from
the client to go through the access port. Because no Layer 3 devices are present between the
authentication clients and the access device in direct authentication and re-DHCP
authentication, the access device can directly learn the clients' MAC addresses, and can
control the forwarding of packets from clients in a more granular way by also using the learned
MAC addresses.
Portal support for EAP
Only Layer 3 portal authentication that uses a remote portal server supports EAP authentication.
Authentication by using the username and password is less secure. Digital certificate authentication
is usually used to ensure higher security.
The Extensible Authentication Protocol (EAP) supports several digital certificate-based
authentication methods, for example, EAP-TLS. Working together with EAP, portal authentication
can implement digital certificate-based user authentication.
Figure 45 Portal support for EAP working flow diagram
As shown in Figure 45, the authentication client and the portal server exchange EAP authentication
packets. The portal server and the access device exchange portal authentication packets that carry
the EAP-Message attributes. The access device and the RADIUS server exchange RADIUS packets
that carry the EAP-Message attributes. The RADIUS server that supports the EAP server function
processes the EAP packets encapsulated in the EAP-Message attributes, and provides the EAP
authentication result. During the whole EAP authentication process, the access device does not
process the packets that carry the EAP-Message attributes but only transports them between the
portal server and the RADIUS server. Therefore, no additional configuration is needed on the access
device.
NOTE:
To use portal authentication that supports EAP, the portal server and client must be the IMC portal
server and the iNode portal client.
Layer 3 portal authentication process
Direct authentication and cross-subnet authentication share the same authentication process.
Re-DHCP authentication has a different process because of the presence of two address allocation
procedures.
117
Direct authentication/cross-subnet authentication process (with CHAP/PAP authentication)
Figure 46 Direct authentication/cross-subnet authentication process
The direct authentication/cross-subnet authentication process is as follows:
1.
An authentication client initiates authentication by sending an HTTP request. When the HTTP
packet arrives at the access device, the access device allows it to pass if it is destined for the
portal server or a predefined free website, or redirects it to the portal server if it is destined for
other websites. The portal server pushes a Web authentication page to the user and the user
enters the username and password.
2.
The portal server and the access device exchange CHAP messages. This step is skipped for
PAP authentication.
3.
The portal server assembles the username and password into an authentication request
message and sends it to the access device. Meanwhile, the portal server starts a timer to wait
for an authentication acknowledgment message.
4.
The access device and the RADIUS server exchange RADIUS packets to authenticate the
user.
5.
The access device sends an authentication reply to the portal server.
6.
The portal server sends an authentication success message to the authentication client to
notify it of logon success.
7.
The portal server sends an authentication reply acknowledgment message to the access
device.
With extended portal functions, the process includes additional steps:
8.
The security policy server exchanges security check information with the authentication client
to check whether the authentication client meets the security requirements.
9.
Based on the security check result, the security policy server authorizes the user to access
certain resources, and sends the authorization information to the access device. The access
device then controls access of the user based on the authorization information.
118
Re-DHCP authentication process (with CHAP/PAP authentication)
Figure 47 Re-DHCP authentication process
Authentication
client
Portal server
Access device
Authentication/
accounting server
Security
policy server
1) Initiate a connection
2) CHAP authentication
3) Authentication request
4) RADIUS
authentication
Timer
5) Authentication reply
6) Authentication
succeeds
7) The user obtains
a new IP address
8) Discover user IP change
9) Detect user IP change
10) Notify login
success
11) IP change
acknowledgment
12) Security check
13) Authorization
The re-DHCP authentication process is as follows:
Step 1 through step 6 are the same as those in the direct authentication/cross-subnet authentication
process.
7.
After receiving the authentication success message, the authentication client obtains a new
public IP address through DHCP and notifies the portal server that it has obtained a public IP
address.
8.
The portal server notifies the access device that the authentication client has obtained a new
public IP address.
9.
Detecting the change of the IP address by examining ARP packets received, the access device
notifies the portal server of the change.
10. The portal server notifies the authentication client of logon success.
11. The portal server sends a user IP address change acknowledgment message to the access
device.
With extended portal functions, the process includes additional steps:
12. The security policy server exchanges security check information with the authentication client
to check whether the authentication client meets the security requirements.
13. Based on the security check result, the security policy server authorizes the user to access
certain resources, and sends the authorization information to the access device. The access
device then controls access of the user based on the authorization information.
119
Portal support for EAP authentication process
Figure 48 Portal support for EAP authentication process
All portal authentication modes share the same EAP authentication steps. The following example
uses direct portal authentication to show the EAP authentication process:
1.
The authentication client sends an EAP Request/Identity message to the portal server to initiate
an EAP authentication process.
2.
The portal server sends a portal authentication request to the access device, and starts a timer
to wait for the portal authentication reply. The portal authentication request contains several
EAP-Message attributes, which are used to encapsulate the EAP packet sent from the
authentication client and carry the certificate information of the client.
3.
After the access device receives the portal authentication request, it constructs a RADIUS
authentication request and sends it to the RADIUS server. The EAP-Message attributes in the
RADIUS authentication request are those carried in the received portal authentication request.
4.
The access device sends a certificate request to the portal server according to the reply
received from the RADIUS server. The certificate request also contains several EAP-Message
attributes, which are used to transfer the certificate information of the RADIUS server. The
EAP-Message attributes in the certificate request are those carried in the RADIUS
authentication reply.
5.
After receiving the certificate request, the portal server sends an EAP authentication reply to
the authentication client, carrying the EAP-Message attribute values.
6.
The authentication client sends another EAP request to continue the EAP authentication with
the RADIUS server, during which there may be several portal authentication requests. The
subsequent authentication processes are the same as that initiated by the first EAP request,
except that the EAP request types vary with the EAP authentication phases.
7.
After the authentication client passes the EAP authentication, the RADIUS server sends an
authentication reply to the access device. This reply carries the EAP-Success message in the
EAP-Message attribute.
8.
The access device sends an authentication reply to the portal server. This reply carries the
EAP-Success message in the EAP-Message attribute.
9.
The portal server notifies the authentication client of the authentication success.
120
10. The portal server sends an authentication reply acknowledgment to the access device.
The remaining steps are for extended portal authentication. For more information about the steps,
see the portal authentication process with CHAP/PAP authentication.
Portal authentication across VPNs
Use portal authentication across MPLS VPNs in cases where branches belong to different VPNs that
are isolated from each other, and all portal users in the branches need to be authenticated by the
server at the headquarters. As shown in Figure 49, the PE connecting the authentication clients
serves as the NAS. The NAS is configured with portal authentication and AAA authentication, both of
which support authentication across VPNs. The NAS can transmit a client's portal authentication
packets in a VPN transparently through the MPLS backbone to the servers in another VPN. This
feature implements centralized client authentication across different VPNs while ensuring the
separation of packets of the different VPNs.
Figure 49 Network diagram for portal authentication across VPNs
VPN 1
CE
VPN 3
NAS
AAA
server
MPLS backbone
Host
PE
PE
VPN 2
Host
CE
P
Portal server
CE
This feature is not applicable to VPNs with overlapping address spaces.
This feature is not supported when the router is operating in gateway mode.
Portal authentication configured on MCE devices can also support authentication across VPNs. For
information about MCE, see MPLS Configuration Guide.
For information about AAA implementation across VPNs, see "Configuring AAA."
Portal configuration task list
To configure Layer 3 portal authentication:
Task
Remarks
Specifying a portal server for Layer 3 portal authentication
Required.
Enabling Layer 3 portal authentication
Required.
121
Task
Remarks
Configuring a portal-free rule
Configuring an authentication source
Controlling access of portal
users
Configuring an authentication destination subnet
Optional.
Setting the maximum number of online portal
Specifying an authentication domain for portal users
Specifying the NAS ID value carried in a RADIUS request
Specifying NAS-Port-Type for an
Configuring RADIUS related
Optional.
Specifying the NAS-Port-ID for an
Specifying a NAS ID profile for an
Specifying a source IP address for outgoing portal
Optional.
Specifying a device ID for the access device
Optional.
Specifying an autoredirection URL for authenticated portal
Optional.
Configuring online Layer 3 portal user detection
Configuring portal detection
Configuring the portal server detection function
Optional.
Configuring portal user information
Logging off portal
Optional.
Configuration prerequisites
Although the portal feature provides a solution for user identity authentication and security check, the
portal feature cannot implement this solution by itself. RADIUS authentication must be configured on
the access device to cooperate with the portal feature to complete user authentication.
The prerequisites for portal authentication configuration are as follows:
•
The portal server and the RADIUS server have been installed and configured properly. Local
portal authentication requires no independent portal server be installed.
•
With re-DHCP authentication, the IP address check function of the DHCP relay agent is
enabled on the access device, and the DHCP server is installed and configured properly.
•
The portal client, access device, and servers can reach each other.
•
With RADIUS authentication, usernames and passwords of the users are configured on the
RADIUS server, and the RADIUS client configurations are performed on the access device. For
information about RADIUS client configuration, see "Configuring AAA."
•
To implement extended portal functions, install and configure IMC EAD, and make sure that the
ACLs configured on the access device correspond to those specified for the resources in the
quarantined area and for the restricted resources on the security policy server. For information
about security policy server configuration on the access device, see "Configuring AAA."
For installation and configuration about the security policy server, see IMC EAD Security Policy Help.
The ACL for resources in the quarantined area and that for restricted resources correspond to
isolation ACL and security ACL on the security policy server respectively.
You can modify the authorized ACLs on the access device. However, your changes take effect only
on portal users logging on after the modification.
122
Specifying a portal server for Layer 3 portal
authentication
Perform this task to specify portal server parameters for Layer 3 portal authentication, including the
portal server IP address, shared encryption key, server port, and the URL address for Web
authentication. Follow these guidelines when you specify a portal server for Layer 3 authentication:
•
The specified parameters of a portal server can be modified or deleted only if the portal server is
not referenced on any interface.
•
To make sure the device can send packets to the portal server in an MPLS VPN, specify the
VPN instance to which the portal server belongs when specifying the portal server on the
device.
To specify a portal server for Layer 3 authentication:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
Specify a portal server and
configure related
parameters.
portal server server-name ip
ip-address [ key [ cipher |
simple ] key-string | port port-id |
server-type { cmcc | imc } | url
url-string | vpn-instance
vpn-instance-name ] *
By default, no portal server is
specified.
2.
Enabling Layer 3 portal authentication
You must first enable portal authentication on an access interface before it can perform portal
authentication for connected clients.
Configuration guidelines
•
You can enable both direct/cross-subnet portal authentication and 802.1X authentication on a
Layer 3 interface, and a user can access the network after passing either authentication. If you
enable both 802.1X authentication and re-DHCP portal authentication on a Layer 3 interface,
portal authentication will fail. For information about 802.1X, see "Configuring 802.1X."
•
The destination port number that the access device uses for sending unsolicited packets to the
portal server must be the same as the port number that the remote portal server actually uses.
•
The portal server and its parameters can be deleted or modified only when the portal server is
not referenced by any interface.
•
Cross-subnet authentication mode (portal server server-name method layer3) does not
require Layer 3 forwarding devices between the access device and the authentication clients.
However, if Layer 3 forwarding devices exist between the authentication client and the access
device, you must select the cross-subnet portal authentication mode.
•
In re-DHCP authentication mode, a client can use a public IP address to send packets before
passing portal authentication. However, responses to the packets are restricted.
Configuration prerequisites
Before enabling Layer 3 portal authentication on an interface, make sure:
•
An IP address is configured for the interface.
•
The interface is not added to any port aggregation group.
•
The portal server to be referenced on the interface exists.
123
Configuration procedure
To enable Layer 3 portal authentication:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
The interface must be a Layer 3
Ethernet interface.
3.
Enable Layer 3 portal
authentication on the
interface.
portal server server-name
method { direct | layer3 |
redhcp }
Not enabled by default.
Controlling access of portal users
Configuring a portal-free rule
A portal-free rule allows specified users to access specified external websites without portal
authentication.
The matching items for a portal-free rule include the source and destination IP address, TCP/UDP
port number, source MAC address, inbound interface, and VLAN. Packets matching a portal-free
rule will not trigger portal authentication, so users sending the packets can directly access the
specified external websites.
Configuration guidelines
•
If you specify both a VLAN and an interface in a portal-free rule, the interface must belong to the
VLAN. Otherwise, the rule does not take effect.
•
You cannot configure two or more portal-free rules with the same filtering criteria. Otherwise,
the system prompts that the rule already exists.
•
Regardless of whether portal authentication is enabled or not, you can only add or remove a
portal-free rule. You cannot modify it.
•
A Layer 2 interface in an aggregation group cannot be specified as the source interface of a
portal-free rule, and the source interface of a portal-free rule cannot be added to an aggregation
group.
Configuration procedure
To configure a portal-free rule:
Step
Command
1.
system-view
Enter system view.
124
Step
2.
Command
Configure a portal-free
rule.
portal free-rule rule-number { destination { any | ip { ip-address mask
{ mask-length | mask } | any } [ tcp tcp-port-number [ to tcp-port-number ]
| udp udp-port-number [ to udp-port-number ] ] } | source { any |
[ interface interface-type interface-number | ip { ip-address mask
{ mask-length | mask } | any } [ tcp tcp-port-number [ to tcp-port-number ]
| udp udp-port-number [ to udp-port-number ] ] | mac mac-address | vlan
vlan-id ] ] * } } *
Configuring an authentication source subnet
By configuring authentication source subnets, you specify that only HTTP packets from users on the
authentication source subnets can trigger portal authentication. If an unauthenticated user is not on
any authentication source subnet, the access device discards all the user's HTTP packets that do not
match any portal-free rule.
Configuration of authentication source subnets applies to only cross-subnet authentication. In direct
authentication mode, the authentication source subnet is 0.0.0.0/0. In re-DHCP authentication mode,
the authentication source subnet of an interface is the subnet to which the private IP address of the
interface belongs.
If both an authentication source subnet and destination subnet are configured on an interface, only
the authentication destination subnet takes effect.
To configure an authentication source subnet:
Step
Command
Remarks
1.
Enter system
view.
system-view
N/A
2.
Enter interface
view.
interface interface-type interface-number
N/A
Optional.
3.
Configure an
authentication
source subnet.
portal auth-network network-address
{ mask-length | mask }
By default, the authentication
source subnet is 0.0.0.0/0, which
means that users from any
subnets must pass portal
authentication.
You can configure multiple
authentication source subnets by
executing this command.
The system supports up to 16
authentication source subnets
and destination subnets.
Configuring an authentication destination subnet
By configuring authentication destination subnets, you specify that only users accessing the
specified subnets (excluding the destination IP addresses and subnets specified in portal-free rules)
trigger portal authentication. Users can access other subnets without portal authentication.
125
If both authentication source subnets and destination subnets are configured on an interface, only
the authentication destination subnet takes effect.
To configure an authentication destination subnet:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
Optional.
3.
Configure an authentication
destination subnet.
portal auth-network destination
network-address { mask-length |
mask }
By default, the authentication
destination subnet is 0.0.0.0/0,
which means that users
accessing any subnets must pass
portal authentication.
You can configure multiple
authentication destination
subnets by executing this
command.
The system supports up to 16
authentication source subnets
and destination subnets.
Setting the maximum number of online portal users
You can use this feature to control the total number of online portal users in the system.
If the maximum number of online portal you set is less than that of the current online portal users, the
limit can be set successfully and does not impact the online portal users, but the system does not
allow new portal users to log on until the number drops down below the limit.
To set the maximum number of online portal users allowed in the system:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Set the maximum number of
online portal users.
portal max-user max-number
By default, the maximum number
of online portal users is the
maximum number of online portal
users supported by the system.
Specifying an authentication domain for portal users
After you specify an authentication domain for portal users on an interface, the device uses the
authentication domain for authentication, authorization, and accounting (AAA) of all portal users on
the interface, ignoring the domain names carried in the usernames. This allows you to specify
different authentication domains for different interfaces as needed.
To specify the authentication domain for portal users on an interface:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
126
Step
3.
Specify an authentication
domain for portal users on
the interface.
Command
Remarks
portal domain domain-name
By default, no authentication
domain is specified for portal
users.
The device selects the authentication domain for a portal user on an interface in this order: the
authentication domain specified for the interface, the authentication domain carried in the username,
and the system default authentication domain. For information about the default authentication
domain, see "Configuring AAA."
Configuring RADIUS related attributes
Specifying the NAS ID value carried in a RADIUS request
If the device uses a RADIUS server for authentication, authorization, and accounting of portal users,
when a portal user logs on from an interface, the device sends a RADIUS request that carries the
NAS-Identifier attribute to the RADIUS server. The RADIUS server uses the NAS-Identifier attribute
in the RADIUS request to identify the device.
You can specify the NAS-identifier attribute value to be carried in a RADIUS request in system view
or interface view. The device prefers the value specified in interface view. If no NAS ID is configured
for the interface, the device uses the NAS ID configured in system view.
To specify the NAS ID value carried in a RADIUS request:
Step
Command
Remarks
1.
system-view
N/A
Enter system view.
•
2.
Specify the NAS ID value
carried in a RADIUS request.
•
In system view:
portal nas-id nas-identifier
In interface view:
By default, the device name
configured by the sysname
command is used as the NAS ID.
a. interface interface-type
interface-number
For information about the
sysname command, see
Fundamentals Command
Reference.
b. portal nas-id
nas-identifier.
Specifying NAS-Port-Type for an interface
NAS-Port-Type is a standard RADIUS attribute for indicating a user access port type. With this
attribute specified on an interface, when a portal user logs on from the interface, the device uses the
specified NAS-Port-Type value as that in the RADIUS request to be sent to the RADIUS server. If
NAS-Port-Type is not specified, the device uses the access port type obtained.
If there are multiple network devices between the Broadband Access Server (the portal
authentication access device) and a portal client, the BAS may not be able to obtain a user's correct
access port information.
To specify the NAS-Port-Type value for an interface:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
127
Step
Command
Remarks
3.
portal nas-port-type { ethernet |
wireless }
Not configured by default.
Specify the NAS-Port-Type
value for the interface.
Specifying the NAS-Port-ID for an interface
If the device uses a RADIUS server for authentication, authorization, and accounting of portal users,
when a portal user logs on from an interface, the device sends a RADIUS request that carries the
NAS-Port-ID attribute to the RADIUS server. The portal server configuration determines the usage of
the NAS-Port-ID attribute.
To specify the NAS-Port-ID value carried in a RADIUS request sent from an interface:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
portal nas-port-id
nas-port-id-value
By default, no NAS-Port-ID value
is specified for an interface, and
the device uses the information
obtained from the physical
interface where the portal user
accesses as the NAS-Port-ID
value in a RADIUS request.
3.
Configure the NAS-Port-ID
value.
Specifying a NAS ID profile for an interface
In some networks, user access points are identified by their access VLANs. Network carriers need to
use NAS-identifiers to identify user access points. With the NAS ID profile specified on an interface,
when a user logs in from the interface, the access device checks the specified profile to obtain the
NAS ID that is bound with the access VLAN. The value of this NAS ID is used as the NAS-identifier
attribute in the RADIUS packets to be sent to the RADIUS server.
The NAS ID profile defines the binding relationship between VLANs and NAS IDs. A NAS ID-VLAN
binding is defined by the nas-id id-value bind vlan vlan-id command, which is described in detail in
AAA configuration commands in the Security Command Reference.
If no NAS-ID profile is specified for an interface or no matching binding is found in the specified
profile:
•
If the NAS ID is configured using the portal nas-id command, the device uses the configured
NAS ID as that of the interface.
•
If the interface does not support NAS ID configuration, or has no NAS ID configured, the device
uses the device name as the interface NAS ID.
To configure a NAS ID profile on an interface:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a NAS ID profile and
enter NAS ID profile view.
aaa nas-id profile profile-name
For more information about the
command, see Security
Command Reference.
128
Step
Command
Remarks
3.
Bind a NAS ID with a VLAN.
nas-id nas-identifier bind vlan
vlan-id
For more information about the
command, see Security
Command Reference.
4.
Return to system view.
quit
N/A
5.
Enter interface view.
interface interface-type
interface-number
N/A
6.
Specify a NAS ID profile for
the interface.
portal nas-id-profile
profile-name
By default, an interface is
specified with no NAS ID profile.
Specifying a source IP address for outgoing portal
packets
After you specify a source IP address for outgoing portal packets on an interface, the IP address is
used as the source IP address of packets that the access device sends to the portal server, and the
destination IP address of packets that the portal server sends to the access device.
To specify a source IP address for outgoing portal packets:
Step
Command
Remarks
1.
Enter system
view.
system-view
N/A
2.
Enter interface
view.
interface interface-type
interface-number
N/A
Optional.
3.
Specify a source
IP address for
outgoing portal
packets.
portal nas-ip ip-address
By default, no source IP address is specified and
the IP address of the user logon interface is used
as the source IP address of outgoing portal
packets.
In NAT environments, Hewlett Packard
Enterprise recommends specifying the
interface's public IP address as the source IP
address of outgoing portal packets.
Specifying a device ID for the access device
Only Layer 3 portal authentication supports this feature.
After the access device is configured with a device ID, the redirection URL that the access device
sends to a portal client carries the parameter wlanacname and an XML value. The XML value is the
configured device ID. The portal server uses this configured device ID to determine which access
device a portal client is using.
To specify a device ID for a device:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Specify a device ID for the
device.
portal device-id id-value
By default, no device ID is
specified for a device.
129
Specifying an autoredirection URL for
authenticated portal users
If you specify an autoredirection URL on the access device, after an unauthenticated user passes
portal authentication through the portal authentication page, the access device redirects the user to
the URL.
To use this feature for remote Layer 3 portal authentication, the portal server must be an IMC portal
server that supports the page auto-redirection function.
To specify an autoredirection URL for authenticated portal users:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Specify an autoredirection
URL for authenticated portal
users.
portal redirect-url url-string
By default, an authenticated user
is redirected to the URL the user
typed in the address bar before
portal authentication.
Configuring portal detection functions
Configuring online Layer 3 portal user detection
With online portal user detection enabled on an interface, the device periodically sends probe
packets to the portal users on the interface to check whether the portal users are still online, to find
portal users who get offline without logging off.
•
If the device receives a reply from a portal user before sending probe packets to the portal user
for the maximum number of times, it considers that the portal user is online and keeps sending
probe packets to the portal user.
•
If the device receives no reply from a portal user after sending probe packets to the portal user
for the maximum number of times, it considers that the portal user is offline and stops sending
probe packets to the portal user and deletes the user.
To configure online Layer 3 portal user detection:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
3.
Configure online Layer 3
portal user detection.
access-user detect type { arp |
icmp } retransmit number
interval interval [ idle-time
idletime ]
Not configured by default.
NOTE:
Adjust the maximum number of transmission attempts and the interval of sending probe packets
according to the actual network conditions.
130
Configuring the portal server detection function
During portal authentication, if the communication between the access device and portal server is
broken, new portal users are not able to log on and the online portal users are not able to log off
normally. To address this problem, the access device needs to be able to detect the reachability
changes of the portal server quickly and take corresponding actions to deal with the changes. For
example, once detecting that the portal server is unreachable, the access device allows portal users
to access network resources without authentication. This function is referred to as portal
authentication bypass. It allows for flexible user access control.
With the portal server detection function, the device can detect the status of a specific portal server.
The specific configurations include:
1.
2.
3.
Detection methods (you can choose either or both)
{
Probing HTTP connections—The access device periodically sends TCP connection
requests to the HTTP service port of the portal servers configured on its interfaces. If the
TCP connection with a portal server can be established, the access device considers that
the probe succeeds (the HTTP service of the portal server is open and the portal server is
reachable). If the TCP connection cannot be established, the access device considers that
the probe fails and the portal server is unreachable.
{
Probing portal heartbeat packets—A portal server that supports the portal heartbeat
function (only the IMC portal server supports this function) sends portal heartbeat packets to
portal access devices periodically. If an access device receives a portal heartbeat packet or
an authentication packet within a probe interval, the access device considers that the probe
succeeds and the portal server is reachable. Otherwise, it considers that the probe fails and
the portal server is unreachable.
Probe parameters
{
Probe interval—Interval at which probe attempts are made.
{
Maximum number of probe attempts—Maximum number of consecutive probe attempts
allowed. If the number of consecutive probes reaches this value, the access device
considers that the portal server is unreachable.
Actions to be taken when the server reachability status changes (you can choose one or more)
{
Sending a trap message—When the status of a portal server changes, the access device
sends a trap message to the NMS. The trap message contains the portal server name and
the current state of the portal server.
{
Sending a log—When the status of a portal server changes, the access device sends a log
message. The log message indicates the portal server name and the current state and
original state of the portal server.
{
Disabling portal authentication (enabling portal authentication bypass)—When the
device detects that a portal server is unreachable, it disables portal authentication on the
interfaces that use the portal server (allows all portal users on the interfaces to access
network resources). When the device receives from the portal server portal heartbeat
packets or authentication packets (such as logon requests and logout requests), it
re-enables the portal authentication function.
You can configure any combination of the configuration items described as needed, with respect to
the following:
•
If both detection methods are specified, a portal server is regarded as unreachable as long as
one detection method fails, and an unreachable portal server is regarded as recovered only
when both detection methods succeed.
•
If multiple actions are specified, the access device executes all the specified actions when the
status of a portal server changes.
•
The detection function configured for a portal server takes effect on an interface only after you
enable portal authentication and reference the portal server on the interface.
To configure the portal server detection function:
131
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Configure the portal
server detection
function.
portal server server-name
server-detect method { http |
portal-heartbeat } * action { log |
permit-all | trap } * [ interval interval ]
[ retry retries ]
Not configured by default.
The portal server specified in the
command must exist.
The portal heartbeat detection method works only when the portal server supports the portal server
heartbeat function. Only the IMC portal server supports the portal server heartbeat function. To
implement detection with this method, you also need to configure the portal server heartbeat function
on the IMC portal server and make sure that the product of interval and retry is greater than or equal
to the portal server heartbeat interval. Hewlett Packard Enterprise recommends configuring the
interval to be greater than the portal server heartbeat interval configured on the portal server.
Configuring portal user information synchronization
Once the device loses communication with a portal server, the portal user information on the device
and that on the portal server may be inconsistent after the communication resumes. To solve this
problem, the device provides the portal user information synchronization function. This function is
implemented by sending and detecting the portal synchronization packet. The process is as follows:
1.
The portal server sends the online user information to the access device in a user
synchronization packet at the user heartbeat interval, which is set on the portal server.
2.
Upon receiving the user synchronization packet, the access device checks the user information
carried in the packet with its own. If the device finds a nonexistent user in the packet, it informs
the portal server of the information and the portal server will delete the user. If the device finds
that one of its users does not appear in the user synchronization packets within N consecutive
synchronization probe intervals (N is equal to the value of retries configured in the portal
server user-sync command), it considers that the user does not exist on the portal server and
logs the user off.
To configure the portal user information synchronization function:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Configure the portal
user information
synchronization
function.
portal server
server-name user-sync
[ interval interval ]
[ retry retries ]
Not configured by default.
The portal server specified in the command must
exist. This function can take effect only when the
specified portal server is referenced on the
interface connecting the users.
The user information synchronization function requires that a portal server supports the portal user
heartbeat function. Only the IMC portal server supports the portal user heartbeat function. To
implement the portal user synchronization function, you also need to configure the user heartbeat
function on the portal server and make sure that the product of interval and retry is greater than or
equal to the portal user heartbeat interval. Hewlett Packard Enterprise recommends configuring the
interval to be greater than the portal user heartbeat interval configured on the portal server.
For redundant user information on the device—information for users who are considered nonexistent
on the portal server, the device deletes the information during the (N+1)th interval, where N is equal
to the value of retries configured in the portal server user-sync command.
132
Logging off portal users
Logging off a user terminates the authentication process for the user or removes the user from the
authenticated users list.
To log off users:
Step
Command
1.
Enter system view.
system-view
2.
Log off users.
portal delete-user { ip-address | all | interface
interface-type interface-number }
Displaying and maintaining portal
Task
Command
Remarks
Display the ACLs on a specific
interface.
display portal acl { all | dynamic |
static } interface interface-type
interface-number [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display portal connection
statistics on a specific interface or
all interfaces.
display portal connection statistics
{ all | interface interface-type
interface-number } [ | { begin | exclude
| include } regular-expression ]
Available in any
view.
Display information about a
portal-free rule or all portal-free
rules.
display portal free-rule
[ rule-number ] [ | { begin | exclude |
include } regular-expression ]
Available in any
view.
Display the portal configuration of
a specific interface.
display portal interface
interface-type interface-number [ |
{ begin | exclude | include }
regular-expression ]
Available in any
view.
Display information about a
specific portal server or all portal
servers.
display portal server [ server-name ]
[ | { begin | exclude | include }
regular-expression ]
Available in any
view.
Display portal server statistics on
a specific interface or all
interfaces.
display portal server statistics { all |
interface interface-type
interface-number } [ | { begin | exclude
| include } regular-expression ]
Available in any
view.
Display TCP spoofing statistics.
display portal tcp-cheat statistics [ |
{ begin | exclude | include }
regular-expression ]
Available in any
view.
Display information about portal
users on a specific interface or all
interfaces.
display portal user { all | interface
interface-type interface-number } [ |
{ begin | exclude | include }
regular-expression ]
Available in any
view.
Clear portal connection statistics
on a specific interface or all
interfaces.
reset portal connection statistics
{all | interface interface-type
interface-number }
Available in user
view.
Clear portal server statistics on a
specific interface or all interfaces.
reset portal server statistics { all |
interface interface-type
interface-number }
Available in user
view.
133
Task
Command
Remarks
Clear TCP spoofing statistics.
reset portal tcp-cheat statistics
Available in user
view.
Portal configuration examples
Configuring direct portal authentication
Network requirements
As shown in Figure 50, the host is assigned with a public network IP address either manually or
through DHCP.
Configure the router to perform direct portal authentication for users on the host. Before a user
passes portal authentication, the user can access only the portal server. After passing portal
authentication, the user can access Internet resources.
Use a RADIUS server as the authentication/authorization server.
Figure 50 Network diagram
Portal server
GE3/0/2
2.2.2.1/24
Host
GE3/0/1
192.168.0.100/24
192.168.0.111/24
Router
2.2.2.2/24
Gateway : 2.2.2.1/24
RADIUS server
192.168.0.112/24
Configuration prerequisites
Configure IP addresses for the host, router, and servers as shown in Figure 50 and make sure that
they can reach each other.
Configure the RADIUS server properly to provide authentication/authorization functions for users.
Configuring the portal server
This example assumes that the portal server runs on IMC PLAT 5.1 SP1 (E0202P05) and IMC UAM
5.1 (E0301).
1.
Configure the portal server:
a. Log in to IMC and select the Service tab.
b. Select User Access Manager > Portal Service > Server from the navigation tree to enter
the portal server configuration page, as shown in Figure 51.
c. Configure the portal server parameters as needed. This example uses the default settings.
d. Click OK.
134
Figure 51 Portal server configuration
2.
Configure the IP address group:
a. Select User Access Manager > Portal Service > IP Group from the navigation tree to
enter the portal IP address group configuration page.
b. Click Add to enter the page shown in Figure 52.
c. Enter the IP group name.
d. Enter the start IP address and end IP address of the IP group.
Make sure that the host IP address is in the IP group.
e. Select a service group.
By default, the group Ungrouped is used.
f. Select the IP group type Normal.
g. Click OK.
Figure 52 Adding an IP address group
3.
Add a portal device:
a. Select User Access Manager > Portal Service > Device from the navigation tree to enter
the portal device configuration page.
b. Click Add to enter the page shown in Figure 53.
c. Enter the device name NAS, enter the IP address of the router's interface connected to the
user, and enter the key, which must be the same as that configured on the switch.
135
d. Set whether to enable IP address reallocation.
This example uses direct portal authentication, and therefore select No from the Reallocate
IP list.
e. Select whether to support sever heartbeat and user heartbeat functions.
In this example, select No for both Support Server Heartbeat and Support User
Heartbeat.
f. Click OK.
Figure 53 Adding a portal device
4.
Associate the portal device with the IP address group.
a. As shown in Figure 54, click the icon in the Port Group Information Management column
of device NAS to enter the port group configuration page.
Figure 54 Device list
b. On the port group configuration page, click Add to enter the page shown in Figure 55.
Perform the following configurations:
c. Enter the port group name.
d. Select the configured IP address group.
The IP address used by the user to access the network must be within this IP address
group.
e. Use the default settings for other parameters.
f. Click OK.
136
Figure 55 Adding a port group
5.
Select User Access Manager > Service Parameters > Validate from the navigation tree to
validate the configurations.
Configuring the router
1.
Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<Router> system-view
[Router] radius scheme rs1
# Set the server type for the RADIUS scheme. When using the IMC server, set the server type
to extended.
[Router-radius-rs1] server-type extended
# Specify the primary authentication/authorization server, and configure the keys for
communication with the servers.
[Router-radius-rs1] primary authentication 192.168.0.112
[Router-radius-rs1] key authentication radius
# Specify that the ISP domain name should not be included in the username sent to the
RADIUS server.
[Router-radius-rs1] user-name-format without-domain
[Router-radius-rs1] quit
2.
Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[Router] domain dm1
# Configure AAA methods for the ISP domain.
[Router-isp-dm1] authentication portal radius-scheme rs1
[Router-isp-dm1] authorization portal radius-scheme rs1
[Router-isp-dm1] quit
# Configure domain dm1 as the default ISP domain for all users. Then, if a user enters a
username without any ISP domain at logon, the authentication/authorization methods of the
default domain are used for the user.
[Router] domain default enable dm1
3.
Configure portal authentication:
# Configure a portal server on the router, specifying the portal server name as newpt, IP
address as 192.168.0.111, key as plaintext string portal, port number as 50100, and URL as
http://192.168.0.111:8080/portal.
[Router] portal server newpt ip 192.168.0.111 key simple portal port 50100 url
http://192.168.0.111:8080/portal
137
# Enable portal authentication on the interface connecting the host.
[Router] interface gigabitethernet 3/0/2
[Router–GigabitEthernet3/0/2] portal server newpt method direct
[Router–GigabitEthernet3/0/2] quit
Verifying the configuration
Execute the following command to see whether the portal configuration has taken effect:
[Router] display portal interface gigabitethernet 3/0/2
Portal configuration of GigabitEthernet3/0/2
IPv4:
Status: Portal running
Portal server: newpt
Authentication type: Direct
Authentication domain:
Authentication network:
The user can initiate portal authentication by using the iNode client or by accessing a webpage. All
the initiated Web requests are redirected to the portal authentication page
http://192.168.0.111:8080/portal. Before passing portal authentication, the user can access only the
authentication page. After passing portal authentication, the user can access Internet resources.
After the user passes the portal authentication, you can use the following command to view the portal
user information on the router.
[Router] display portal user interface gigabitethernet 3/0/2
Index:19
State:ONLINE
SubState:NONE
ACL:NONE
Work-mode:stand-alone
MAC
IP
Vlan
Interface
--------------------------------------------------------------------0015-e9a6-7cfe
2.2.2.2
0
GigabitEthernet3/0/2
On interface GigabitEthernet3/0/2:total 1 user(s) matched, 1 listed.
Configuring re-DHCP portal authentication
Network requirements
As shown in Figure 56, the host obtains an IP address from the DHCP server.
Configure the router to perform re-DHCP portal authentication for users on the host. Before a user
passes portal authentication, the DHCP server assigns a private IP address to the host. After the
user passes portal authentication, the DHCP server assigns a public IP address to the host and then
the user can access Internet resources.
A RADIUS server serves as the authentication/authorization server.
138
Figure 56 Network diagram
Configuration prerequisites and guidelines
•
Configure IP addresses for the router and servers as shown in Figure 56 and make sure the
host, router, and servers can reach each other.
•
Configure the RADIUS server properly to provide authentication and authorization functions for
users.
•
For re-DHCP portal authentication, configure a public address pool (20.20.20.0/24, in this
example) and a private address pool (10.0.0.0/24, in this example) on the DHCP server.
(Details not shown.)
•
For re-DHCP portal authentication, the router must be configured as a DHCP relay agent and
the portal-enabled interface must be configured with a primary IP address (a public IP address)
and a secondary IP address (a private IP address). For information about DHCP relay agent
configuration, see Layer 3—IP Services Configuration Guide.
•
Make sure the IP address of the portal device added on the portal server is the public IP
address of the interface connecting users (20.20.20.1 in this example), the private IP address
range for the IP address group associated with the portal device is the private network segment
where the users reside (10.0.0.0/24 in this example), and the public IP address range for the IP
address group is the public network segment 20.20.20.0/24.
Configuration procedure
1.
Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1, and enter its view.
<Router> system-view
[Router] radius scheme rs1
# Set the server type for the RADIUS scheme. When using the IMC server, set the server type
to extended.
[Router-radius-rs1] server-type extended
# Specify the primary authentication/authorization server, and configure the keys for
communication with the servers.
[Router-radius-rs1] primary authentication 192.168.0.113
[Router-radius-rs1] key authentication radius
# Specify that the ISP domain name should not be included in the username sent to the
RADIUS server.
[Router-radius-rs1] user-name-format without-domain
[Router-radius-rs1] quit
2.
Configure an authentication domain:
139
# Create an ISP domain named dm1 and enter its view.
[Router] domain dm1
# Configure AAA methods for the ISP domain.
[Router-isp-dm1] authentication portal radius-scheme rs1
[Router-isp-dm1] authorization portal radius-scheme rs1
[Router-isp-dm1] quit
# Configure domain dm1 as the default ISP domain for all users. Then, if a user enters a
username without any ISP domain at logon, the authentication/authorization methods of the
default domain are used for the user.
[Router] domain default enable dm1
3.
Configure portal authentication:
# Configure the portal server as follows:
{
Name: newpt
{
IP address: 192.168.0.111
{
Key: portal, in plain text
{
Port number: 50100
{
URL: http://192.168.0.111:8080/portal
[Router] portal server newpt ip 192.168.0.111 key simple portal port 50100 url
http://192.168.0.111:8080/portal
# Configure the router as a DHCP relay agent, and enable the IP address check function.
[Router] dhcp enable
[Router] dhcp relay server-group 0 ip 192.168.0.112
[Router] interface gigabitethernet 3/0/2
[Router–GigabitEthernet3/0/2] ip address 20.20.20.1 255.255.255.0
[Router–GigabitEthernet3/0/2] ip address 10.0.0.1 255.255.255.0 sub
[Router-GigabitEthernet3/0/2] dhcp select relay
[Router-GigabitEthernet3/0/2] dhcp relay server-select 0
[Router-GigabitEthernet3/0/2] dhcp relay address-check enable
# Enable re-DHCP portal authentication on the interface connecting the host.
[Router–GigabitEthernet3/0/2] portal server newpt method redhcp
[Router–GigabitEthernet3/0/2] quit
Configuring cross-subnet portal authentication
Network requirements
As shown in Figure 57, configure cross-subnet portal authentication on Router A to authenticate
users on the host. Before a user passes portal authentication, the user can access only the portal
server. After the user passes portal authentication, the user can access Internet resources.
A RADIUS server serves as the authentication/authorization server.
140
Figure 57 Network diagram
Configuration prerequisites and guidelines
•
Configure IP addresses for the host, routers, and servers as shown in Figure 57 and make sure
they can reach each other.
•
Configure the RADIUS server properly to provide authentication and authorization functions for
users.
•
Make sure the IP address of the portal device added on the portal server is the IP address of the
interface connecting users (20.20.20.1 in this example), and the IP address group associated
with the portal device is the network segment where the users reside (8.8.8.0/24 in this
example).
Configuration procedure
1.
Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<RouterA> system-view
[RouterA] radius scheme rs1
# Set the server type for the RADIUS scheme. When using the IMC server, set the server type
to extended.
[RouterA-radius-rs1] server-type extended
# Specify the primary authentication/authorization server, and configure the keys for
communication with the servers.
[RouterA-radius-rs1] primary authentication 192.168.0.112
[RouterA-radius-rs1] key authentication simple radius
# Specify that the ISP domain name should not be included in the username sent to the
RADIUS server.
[RouterA-radius-rs1] user-name-format without-domain
[RouterA-radius-rs1] quit
2.
Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[RouterA] domain dm1
# Configure AAA methods for the ISP domain.
[RouterA-isp-dm1] authentication portal radius-scheme rs1
[RouterA-isp-dm1] authorization portal radius-scheme rs1
[RouterA-isp-dm1] quit
# Configure domain dm1 as the default ISP domain for all users. Then, if a user enters a
username without any ISP domain at logon, the authentication/authorization methods of the
default domain are used for the user.
141
[RouterA] domain default enable dm1
3.
Configure portal authentication:
# Configure the portal server as follows:
{
Name: newpt
{
IP address: 192.168.0.111
{
Key: portal
{
Port number: 50100
{
URL: http://192.168.0.111:8080/portal
[RouterA] portal server newpt ip 192.168.0.111 key portal port 50100 url
http://192.168.0.111:8080/portal
# Enable Layer 3 portal authentication on the interface connecting Router B.
[RouterA] interface gigabitethernet 3/0/2
[RouterA–GigabitEthernet3/0/2] portal server newpt method layer3
[RouterA–GigabitEthernet3/0/2] quit
On Router B, configure a default route to subnet 192.168.0.0/24, setting the next hop as 20.20.20.1.
(Details not shown.)
Configuring direct portal authentication with extended
functions
Network requirements
As shown in Figure 58, the host is assigned with a public network IP address either manually or
through DHCP.
Configure the router to perform extended direct portal authentication for users on the host. If a user
fails security check after passing identity authentication, the user can access only subnet
192.168.0.0/24. After the user passes security check, the user can access Internet resources.
A RADIUS server serves as the authentication/authorization server.
Figure 58 Network diagram
Configuration prerequisites
•
Configure IP addresses for the host, router, and servers as shown in Figure 58 and make sure
they can reach each other before extended portal is enabled.
•
Configure the RADIUS server properly to provide authentication and authorization functions for
users.
142
Configuration procedure
1.
Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<Router> system-view
[Router] radius scheme rs1
# Set the server type for the RADIUS scheme. When using the IMC server, set the server type
to extended.
[Router-radius-rs1] server-type extended
# Specify the primary authentication/authorization server, and configure the keys for
communication with the servers.
[Router-radius-rs1] primary authentication 192.168.0.112
[Router-radius-rs1] key authentication radius
[Router-radius-rs1] user-name-format without-domain
# Configure the IP address of the security policy server.
[Router-radius-rs1] security-policy-server 192.168.0.113
[Router-radius-rs1] quit
2.
Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[Router] domain dm1
# Configure AAA methods for the ISP domain.
[Router-isp-dm1] authentication portal radius-scheme rs1
[Router-isp-dm1] authorization portal radius-scheme rs1
[Router-isp-dm1] quit
# Configure domain dm1 as the default ISP domain for all users. Then, if a user enters the
username without the ISP domain at logon, the authentication/authorization methods of the
default domain are used for the user.
[Router] domain default enable dm1
3.
Configure the ACL (ACL 3000 ) for resources on subnet 192.168.0.0/24 and the ACL (ACL
3001) for Internet resources:
[Router] acl number 3000
[Router-acl-adv-3000] rule permit ip destination 192.168.0.0 0.0.0.255
[Router-acl-adv-3000] rule deny ip
[Router-acl-adv-3000] quit
[Router] acl number 3001
[Router-acl-adv-3001] rule permit ip
[Router-acl-adv-3001] quit
Make sure you specify ACL 3000 as the isolation ACL and ACL 3001 as the security ACL on the
security policy server.
4.
Configure extended portal authentication:
# Configure the portal server as follows:
{
Name: newpt
{
IP address: 192.168.0.111
{
Key: portal, in plain text
{
Port number: 50100
{
URL: http://192.168.0.111:8080/portal
[Router] portal server newpt ip 192.168.0.111 key simple portal port 50100 url
http://192.168.0.111:8080/portal
143
# Enable extended portal authentication on the interface connecting the host.
[Router] interface gigabitethernet 3/0/2
[Router–GigabitEthernet3/0/2] portal server newpt method direct
[Router–GigabitEthernet3/0/2] quit
Configuring re-DHCP portal authentication with extended
functions
Network requirements
As shown in Figure 59, the host obtains an IP address from the DHCP server.
Configure the router to perform extended re-DHCP portal authentication for users on the host.
Before a user passes portal authentication, the DHCP server assigns a private IP address to the host.
After the user passes portal authentication, the DHCP server assigns a public IP address to the host.
If a user fails security check after passing identity authentication, the user can access only subnet
192.168.0.0/24. After passing security check, the user can access Internet resources.
A RADIUS server serves as the authentication/authorization server.
Figure 59 Network diagram
Configuration prerequisites and guidelines
•
Configure IP addresses for the router and servers as shown in Figure 59 and make sure the
host, router, and servers can reach each other.
•
Configure the RADIUS server properly to provide authentication and authorization functions for
users.
•
For re-DHCP portal authentication, configure a public address pool (20.20.20.0/24, in this
example) and a private address pool (10.0.0.0/24, in this example) on the DHCP server.
(Details not shown.)
•
For re-DHCP portal authentication, the router must be configured as a DHCP relay agent and
the portal-enabled interface must be configured with a primary IP address (a public IP address)
and a secondary IP address (a private IP address). For information about DHCP relay agent
configuration, see Layer 3—IP Services Configuration Guide.
•
Make sure the IP address of the portal device added on the portal server is the public IP
address of the interface connecting users (20.20.20.1 in this example), the private IP address
range for the IP address group associated with the portal device is the private network segment
where the users reside (10.0.0.0/24 in this example), and the public IP address range for the IP
address group is the public network segment 20.20.20.0/24.
144
Configuration procedure
1.
Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<Router> system-view
[Router] radius scheme rs1
# Set the server type for the RADIUS scheme. When using the IMC server, set the server type
to extended.
[Router-radius-rs1] server-type extended
# Specify the primary authentication/authorization server , and configure the keys for
communication with the servers.
[Router-radius-rs1] primary authentication 192.168.0.113
[Router-radius-rs1] key authentication simple radius
[Router-radius-rs1] user-name-format without-domain
# Configure the IP address of the security policy server.
[Router-radius-rs1] security-policy-server 192.168.0.114
[Router-radius-rs1] quit
2.
Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[Router] domain dm1
# Configure AAA methods for the ISP domain.
[Router-isp-dm1] authentication portal radius-scheme rs1
[Router-isp-dm1] authorization portal radius-scheme rs1
[Router-isp-dm1] quit
# Configure domain dm1 as the default ISP domain for all users. Then, if a user enters the
username without the ISP domain at logon, the authentication/authorization methods of the
default domain are used for the user.
[Router] domain default enable dm1
3.
Configure the ACL (ACL 3000 ) for resources on subnet 192.168.0.0/24 and the ACL (ACL
3001) for Internet resources:
[Router] acl number 3000
[Router-acl-adv-3000] rule permit ip destination 192.168.0.0 0.0.0.255
[Router-acl-adv-3000] rule deny ip
[Router-acl-adv-3000] quit
[Router] acl number 3001
[Router-acl-adv-3001] rule permit ip
[Router-acl-adv-3001] quit
Make sure you specify ACL 3000 as the isolation ACL and ACL 3001 as the security ACL on the
security policy server.
4.
Configure extended portal authentication:
# Configure the portal server as follows:
{
Name: newpt
{
IP address: 192.168.0.111
{
Key: portal, in plain text
{
Port number: 50100
{
URL: http://192.168.0.111:8080/portal
[Router] portal server newpt ip 192.168.0.111 key simple portal port 50100 url
http://192.168.0.111:8080/portal
145
# Configure the router as a DHCP relay agent, and enable the IP address check function.
[Router] dhcp enable
[Router] dhcp relay server-group 0 ip 192.168.0.112
[Router] interface gigabitethernet 3/0/2
[Router–GigabitEthernet3/0/2] ip address 20.20.20.1 255.255.255.0
[Router–GigabitEthernet3/0/2] ip address 10.0.0.1 255.255.255.0 sub
[Router-GigabitEthernet3/0/2] dhcp select relay
[Router-GigabitEthernet3/0/2] dhcp relay server-select 0
[Router-GigabitEthernet3/0/2] dhcp relay address-check enable
# Enable portal authentication on the interface connecting the host.
[Router–GigabitEthernet3/0/2] portal server newpt method redhcp
[Router–GigabitEthernet3/0/2] quit
Configuring cross-subnet portal authentication with extended
functions
Network requirements
As shown in Figure 60, configure Router A to perform extended cross-subnet portal authentication
for users on the host. If a user fails security check after passing identity authentication, the user can
access only subnet 192.168.0.0/24. After passing the security check, the user can access Internet
resources.
A RADIUS server serves as the authentication/authorization server.
Figure 60 Network diagram
Configuration prerequisites and guidelines
•
Configure IP addresses for the host, routers, and servers as shown in Figure 60 and make sure
that routes are available between devices.
•
Configure the RADIUS server properly to provide authentication and authorization functions for
users.
•
Make sure the IP address of the portal device added on the portal server is the IP address of the
interface connecting users (20.20.20.1 in this example), and the IP address group associated
with the portal device is the network segment where the users reside (8.8.8.0/24 in this
example).
146
Configuration procedure
1.
Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<RouterA> system-view
[RouterA] radius scheme rs1
# Set the server type for the RADIUS scheme. When using the IMC server, set the server type
to extended.
[RouterA-radius-rs1] server-type extended
# Specify the primary authentication/authorization server, and configure the keys for
communication with the servers.
[RouterA-radius-rs1] primary authentication 192.168.0.112
[RouterA-radius-rs1] key authentication simple radius
[RouterA-radius-rs1] user-name-format without-domain
# Configure the IP address of the security policy server.
[RouterA-radius-rs1] security-policy-server 192.168.0.113
[RouterA-radius-rs1] quit
2.
Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[RouterA] domain dm1
# Configure AAA methods for the ISP domain.
[RouterA-isp-dm1] authentication portal radius-scheme rs1
[RouterA-isp-dm1] authorization portal radius-scheme rs1
[RouterA-isp-dm1] quit
# Configure domain dm1 as the default ISP domain for all users. Then, if a user enters a
username without any ISP domain at logon, the authentication/authorization methods of the
default domain are used for the user.
[RouterA] domain default enable dm1
3.
Configure the ACL (ACL 3000 ) for resources on subnet 192.168.0.0/24 and the ACL (ACL
3001) for Internet resources:
[RouterA] acl number 3000
[RouterA-acl-adv-3000] rule permit ip destination 192.168.0.0 0.0.0.255
[RouterA-acl-adv-3000] rule deny ip
[RouterA-acl-adv-3000] quit
[RouterA] acl number 3001
[RouterA-acl-adv-3001] rule permit ip
[RouterA-acl-adv-3001] quit
Make sure you specify ACL 3000 as the isolation ACL and ACL 3001 as the security ACL on the
security policy server.
4.
Configure extended portal authentication:
# Configure the portal server as follows:
{
Name: newpt
{
IP address: 192.168.0.111
{
Key: portal, in plain text
{
Port number: 50100
{
URL: http://192.168.0.111:8080/portal
[RouterA] portal server newpt ip 192.168.0.111 key simple portal port 50100 url
http://192.168.0.111:8080/portal
147
# Enable portal authentication on the interface connecting Router B.
[RouterA] interface gigabitethernet 3/0/2
[RouterA–GigabitEthernet3/0/2] portal server newpt method layer3
[RouterA–GigabitEthernet3/0/2] quit
On Router B, configure a default route to subnet 192.168.0.0/24, setting the next hop as 20.20.20.1.
(Details not shown.)
Configuring portal server detection and portal user
information synchronization
Network requirements
As shown in Figure 61, a host is directly connected to a router (the access device) and must pass
portal authentication before it can access the Internet. A RADIUS server serves as the
authentication/authorization server.
Detailed requirements are as follows:
•
The host is assigned with a public network IP address either manually or through DHCP. Before
passing portal authentication, the host can access only the portal server. After passing portal
authentication, the host can access the Internet.
•
The access device (Router) can detect whether the portal server is reachable and send trap
messages upon state changes. When the portal server is unreachable due to, for example, a
connection failure, network device failure, or portal server failure, the access device can disable
portal authentication, allowing users to access the Internet without authentication.
•
The access device can synchronize portal user information with the portal server periodically.
Figure 61 Network diagram
Configuration considerations
1.
Configure the portal server and enable portal server heartbeat function and the portal user
heartbeat function.
2.
Configure the RADIUS server to implement authentication and authorization.
3.
Configure direct portal authentication on interface GigabitEthernet 3/0/2, which is directly
connected with the host.
4.
Configure the portal server detection function on the access device, so that the access device
can detect the status of the portal server by cooperating with the portal server heartbeat
function.
5.
Configure the portal user information synchronization function, so that the access device can
synchronize portal user information with the portal server by cooperating with the portal user
heartbeat function.
148
Configuration prerequisites
•
Configure IP addresses for the host, router, and servers as shown in Figure 61 and make sure
they can reach each other.
•
Configure the RADIUS server properly to provide authentication and authorization functions for
users.
Configuring the portal server
This example assumes that the portal server runs on IMC PLAT 5.1 SP1 (E0202P05) and IMC UAM
5.1 (E0301).
1.
Configure the portal server:
a. Log in to the IMC management platform and select the Service tab.
b. Select User Access Manager > Portal Service > Server from the navigation tree to enter
the portal server configuration page, as shown in Figure 62.
c. Configure the portal server heartbeat interval and user heartbeat interval.
d. Use default values for other parameters.
e. Click OK.
Figure 62 Portal server configuration
2.
Configure the IP address group:
a. Select User Access Manager > Portal Service > IP Group from the navigation tree to
enter the portal IP address group configuration page.
b. Click Add to enter the page shown in Figure 63.
c. Enter the IP group name.
d. Enter the start IP address and end IP address of the IP group.
Make sure that the host IP address is in the IP group.
e. Select a service group.
By default, the group Ungrouped is used.
f. Select the IP group type Normal.
g. Click OK.
149
Figure 63 Adding an IP address group
3.
Add a portal device:
a. Select User Access Manager > Portal Service > Device from the navigation tree to enter
the portal device configuration page.
b. Click Add to enter the page shown in Figure 64.
c. Enter the device name NAS.
d. Enter the IP address of the router's interface connected to the user.
e. Enter the key, which must be the same as that configured on the switch.
f. Set whether to enable IP address reallocation.
This example uses direct portal authentication, and therefore select No from the Reallocate
IP list.
g. Select Yes for both Support Server Heartbeat and Support User Heartbeat.
h. Click OK.
Figure 64 Adding a portal device
4.
Associate the portal device with the IP address group:
a. As shown in Figure 65, click the icon in the Port Group Information Management column
of device NAS to enter the port group configuration page.
Figure 65 Device list
150
b. On the port group configuration page, click Add to enter the page shown in Figure 66.
c. Enter the port group name.
d. Select the configured IP address group.
The IP address used by the user to access the network must be within this IP address
group.
e. Use the default settings for other parameters.
f. Click OK.
Figure 66 Adding a port group
5.
Select User Access Manager > Service Parameters > Validate from the navigation tree to
validate the configurations.
Configuring the router
1.
Configure a RADIUS scheme:
# Create RADIUS scheme rs1 and enter its view.
<Router> system-view
[Router] radius scheme rs1
# Configure the server type for the RADIUS scheme. When using the IMC server, configure the
RADIUS server type as extended.
[Router-radius-rs1] server-type extended
# Specify the primary authentication/authorization server, and configure the keys for
communication with the servers.
[Router-radius-rs1] primary authentication 192.168.0.112
[Router-radius-rs1] key authentication simple radius
# Configure the access device to not carry the ISP domain name in the username sent to the
RADIUS server.
[Router-radius-rs1] user-name-format without-domain
[Router-radius-rs1] quit
2.
Configure an authentication domain:
# Create ISP domain dm1 and enter its view.
[Router] domain dm1
# Configure AAA methods for the ISP domain.
[Router-isp-dm1] authentication portal radius-scheme rs1
[Router-isp-dm1] authorization portal radius-scheme rs1
[Router-isp-dm1] quit
151
# Configure domain dm1 as the default ISP domain for all users. Then, if a user enters a
username without any ISP domain at logon, the authentication/authorization methods of the
default domain are used for the user.
[Router] domain default enable dm1
3.
Configure portal authentication:
# Configure a portal server on the router, specifying the portal server name as newpt, IP
address as 192.168.0.111, key as plaintext string portal, port number as 50100, and URL as
http://192.168.0.111:8080/portal.
[Router] portal server newpt ip 192.168.0.111 key simple portal port 50100 url
http://192.168.0.111:8080/portal
# Enable portal authentication on the interface connecting the host.
[Router] interface gigabitethernet 3/0/2
[Router–GigabitEthernet3/0/2] portal server newpt method direct
[Router–GigabitEthernet3/0/2] quit
4.
Configure the portal server detection function:
# Configure the access device to detect portal server newpt, specifying the detection method
as portal heartbeat probe, setting the server probe interval to 40 seconds, and specifying the
access device to send a server unreachable trap message and disable portal authentication to
permit unauthenticated portal users if two consecutive probes fail.
[Router] portal server newpt server-detect method portal-heartbeat action trap
permit-all interval 40 retry 2
The product of interval and retry must be greater than or equal to the portal server heartbeat
interval, and Hewlett Packard Enterprise recommends configuring the interval to be greater
than the portal server heartbeat interval configured on the portal server.
5.
Configure portal user information synchronization:
# Configure the access device to synchronize portal user information with portal server newpt,
setting the synchronization probe interval to 600 seconds, and specifying the access device to
log off users if the users do not appear in the user synchronization packets sent from the server
within two consecutive probe intervals.
[Router] portal server newpt user-sync interval 600 retry 2
The product of interval and retry must be greater than or equal to the portal user heartbeat
interval, and Hewlett Packard Enterprise recommends configuring the interval to be greater
than the portal user heartbeat interval configured on the portal server.
Verifying the configuration
Use the following command to view information about the portal server.
<Router> display portal server newpt
Portal server:
1)newpt:
IP
: 192.168.0.111
Key
: ******
Port : 50100
URL
Status
: http://192.168.0.111:8080/portal
: Up
The Up state of the portal server indicates that the portal server is reachable. If the access device
detects that the portal server is unreachable, you can see the portal server status is Down in the
output, and the access device generates a server unreachable trap "portal server newpt lost" and
disables portal authentication on the access interface, so the client can access the external network
without authentication.
152
Cross-subnet portal authentication across VPNs
Network requirements
As shown in Figure 67, Router A, as the PE device connecting the user side, needs to provide
cross-subnet portal authentication for hosts in VPN 1. The RADIUS server/portal server is in VPN 3.
Figure 67 Network diagram
Configuration prerequisites
•
Before enabling portal authentication, be sure to configure the MPLS L3VPN capabilities
properly and specify VPN targets for VPN 1 and VPN 3 so that VPN 1 and VPN 3 can
communicate with each other. This example gives only the access authentication configuration
on the user-side PE. For information about MPLS L3VPN, see MPLS Configuration Guide.
•
Configure the RADIUS server properly to provide normal authentication/authorization functions
for users.
Configuration procedure
1.
Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<RouterA> system-view
[RouterA] radius scheme rs1
# Configure the RADIUS scheme belong to VPN instance vpn3, the MPLS L3VPN instance
bound to the interface connected to the portal/RADIUS server.
[RouterA-radius-rs1] vpn-instance vpn3
# Set the server type for the RADIUS scheme. When using the IMC server, set the server type
to extended.
[RouterA-radius-rs1] server-type extended
# Specify the primary authentication/authorization server, and configure the keys for
communication with the servers.
[RouterA-radius-rs1] primary authentication 192.168.0.111
[RouterA-radius-rs1] key authentication simple radius
# Configure the device to not carry the ISP domain name in the username sent to the RADIUS
server.
[RouterA-radius-rs1] user-name-format without-domain
# Specify the source IP address for RADIUS packets to be sent as 3.3.0.3. This address must
be the same as that of the access device specified on the server.
[RouterA-radius-rs1] nas-ip 3.3.0.3
[RouterA-radius-rs1] quit
2.
Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[RouterA] domain dm1
153
# Configure AAA methods for the ISP domain.
[RouterA-isp-dm1] authentication portal radius-scheme rs1
[RouterA-isp-dm1] authorization portal radius-scheme rs1
[RouterA-isp-dm1] quit
# Configure domain dm1 as the default ISP domain for all users. Then, if a user enters a
username without any ISP domain at logon, the authentication/authorization methods of the
default domain are used for the user.
[RouterA] domain default enable dm1
3.
Configure portal authentication:
# Configure the portal server as follows:
{
Name: newpt
{
IP address: 192.168.0.111
{
VPN: vpn3
{
Key: portal, in plain text
{
Port number: 50100
{
URL: http://192.168.0.111:8080/portal
[RouterA] portal server newpt ip 192.168.0.111 vpn-instance vpn3 key simple portal
port 50100 url http://192.168.0.111:8080/portal
# Enable Layer 3 portal authentication on the interface connecting the user side.
[RouterA] interface gigabitethernet 3/0/1
[RouterA–GigabitEthernet3/0/1] portal server newpt method layer3
[RouterA–GigabitEthernet3/0/1] quit
Verifying the configuration
Execute the display portal server command to check whether the portal configuration has taken
effect. After Host passes portal authentication, perform the display portal user command to view
information about online portal users on Router A.
[RouterA] display portal user all
Index:2
State:ONLINE
SubState:NONE
ACL:NONE
Work-mode:stand-alone
VPN instance:vpn1
MAC
IP
Vlan
Interface
---------------------------------------------------------------------------000d-88f7-c268
3.3.0.1
0
GigabitEthernet3/0/1
Total 1 user(s) matched, 1 listed.
Troubleshooting portal
Inconsistent keys on the access device and the portal server
Symptom
When a user is forced to access the portal server, the portal server displays a blank webpage , rather
than the portal authentication page or an error message.
154
Analysis
The keys on the access device and those on the portal server are not configured consistently,
causing CHAP message exchange failure. As a result, the portal server does not display the
authentication page.
Solution
•
Use the display portal server command to display the key for the portal server on the access
device and view the key for the access device on the portal server.
•
Use the portal server command to modify the key on the access device or modify the key for
the access device on the portal server to make sure that the keys are consistent.
Incorrect server port number on the access device
Symptom
After a user passes the portal authentication, you cannot force the user to log off by executing the
portal delete-user command on the access device, but the user can log off by using the disconnect
attribute on the authentication client.
Analysis
When you execute the portal delete-user command on the access device to force the user to log off,
the access device actively sends a REQ_LOGOUT message to the portal server. The default
listening port of the portal server is 50100. However, if the listening port configured on the access
device is not 50100, the destination port of the REQ_LOGOUT message is not the actual listening
port on the server, and the portal server cannot receive the REQ_LOGOUT message. As a result,
you cannot force the user to log off the portal server.
When the user uses the disconnect attribute on the client to log off, the portal server actively sends
a REQ_LOGOUT message to the access device. The source port is 50100 and the destination port
of the ACK_LOGOUT message from the access device is the source port of the REQ_LOGOUT
message so that the portal server can receive the ACK_LOGOUT message correctly, no matter
whether the listening port is configured on the access device. The user can log off the portal server.
Solution
Use the display portal server command to display the listening port of the portal server configured
on the access device and use the portal server command in the system view to modify it to make
sure that it is the actual listening port of the portal server.
155
Configuring port security
Overview
Port security is available only for SAP modules that are operating in bridge mode.
Port security combines and extends 802.1X and MAC authentication to provide MAC-based network
access control. It applies to networks that require different authentication methods for different users
on a port.
Port security prevents unauthorized access to a network by checking the source MAC address of
inbound traffic and prevents access to unauthorized devices by checking the destination MAC
address of outbound traffic.
Port security can control MAC address learning and authentication on a port to make sure the port
learns only source trusted MAC addresses.
A frame is illegal if its source MAC address cannot be learned in a port security mode, or if it is from
a client that has failed 802.1X or MAC authentication. The port security feature automatically takes a
pre-defined action on illegal frames. This automatic mechanism enhances network security and
reduces human intervention.
For scenarios that require only 802.1X authentication or MAC authentication, Hewlett Packard
Enterprise recommends you use the 802.1X authentication or MAC authentication feature rather
than port security.
For more information about 802.1X and MAC authentication, see "Configuring 802.1X" and
"Configuring MAC authentication."
Configuring port security
Port security supports the need to know (NTK) feature, intrusion protection, and port security traps.
NTK
NTK prevents traffic interception by checking the destination MAC address in outbound frames. The
feature ensures that frames are sent only to hosts that have passed authentication or whose MAC
addresses have been learned or configured on the access device.
Intrusion protection
The intrusion protection feature checks the source MAC address in inbound frames for illegal frames
and takes a pre-defined action on each detected illegal frame. The action can be disabling the port
temporarily, disabling the port permanently, or blocking frames from the illegal MAC address for 3
minutes (not user configurable).
Port security traps
To monitor user behavior, configure the port security module to send traps for port security events
such as login, logoff, and MAC authentication.
Port security modes
Port security supports the following categories of security mode:
•
MAC learning control—Includes autoLearn and secure. MAC address learning is permitted
on ports in autoLearn mode and disabled on ports in secure mode.
•
Authentication—Implements MAC authentication, 802.1X authentication, or a combination of
the two authentication methods.
156
Upon receiving a frame, the port in a security mode searches the MAC address table for the source
MAC address. If a match is found, the port forwards the frame. If no match is found, the port learns
the MAC address or performs authentication, depending on the security mode. If the frame is illegal,
the port takes the pre-defined NTK, intrusion protection, or trapping action.
The maximum number of users a port supports equals the maximum number of MAC addresses that
port security allows or the maximum number of concurrent users the authentication mode in use
allows, whichever is smaller. For example, if 802.1X allows more concurrent users than port
security's limit on the number of MAC addresses on the port in userLoginSecureExt mode, port
security's limit takes effect.
Table 8 describes the port security modes and the security features.
Table 8 Port security modes
Purpose
Turning off the port security
feature
Controlling MAC address
learning
Performing 802.1X
authentication
Security mode
Features that can
be triggered
noRestrictions (the default mode).
In this mode, port security is disabled on the port
and access to the port is not restricted.
N/A
autoLearn
secure
NTK/intrusion
protection
userLogin
N/A
userLoginSecure
userLoginSecureExt
NTK/intrusion
protection
userLoginWithOUI
Performing MAC
authentication
macAddressWithRadius
NTK/intrusion
protection
macAddressOrUserLoginSecure
Or
Performing a combination of
MAC authentication and
802.1X authentication
macAddressOrUserLoginSecureExt
macAddressElseUserLoginSecure
Else
NTK/intrusion
protection
macAddressElseUserLoginSecureE
xt
TIP:
•
•
•
•
•
•
userLogin specifies 802.1X authentication and port-based access control.
macAddress specifies MAC authentication.
Else specifies that the authentication method before Else is applied first. If the authentication fails,
whether to turn to the authentication method following Else depends on the protocol type of the
authentication request.
Typically, in a security mode with Or, the authentication method to be used depends on the protocol type
of the authentication request.
userLogin with Secure specifies 802.1X authentication and MAC-based access control.
Ext indicates allowing multiple 802.1X users to be authenticated and serviced at the same time. A security
mode without Ext allows only one user to pass 802.1X authentication.
Controlling MAC address learning
•
autoLearn
A port in this mode can learn MAC addresses, and allows frames from learned or configured
MAC addresses to pass. The automatically learned MAC addresses are secure MAC
157
addresses. You can also configure secure MAC addresses by using the port-security
mac-address security command. A secure MAC address never ages out by default.
When the number of secure MAC addresses reaches the upper limit, the port transitions to
secure mode.
The dynamic MAC address learning function in MAC address management is disabled on ports
operating in autoLearn mode, but you can configure MAC addresses by using the
mac-address dynamic and mac-address static commands.
•
secure
MAC address learning is disabled on a port in secure mode. You configure MAC addresses by
using the mac-address static and mac-address dynamic commands. For more information
about configuring MAC address table entries, see Layer 2—LAN Switching Configuration
Guide.
A port in secure mode allows only frames sourced from secure MAC addresses and manually
configured MAC addresses to pass.
Performing 802.1X authentication
•
userLogin
A port in this mode performs 802.1X authentication and implements port-based access control.
The port can service multiple 802.1X users. Once an 802.1X user passes authentication on the
port, any subsequent 802.1X users can access the network through the port without
authentication.
•
userLoginSecure
A port in this mode performs 802.1X authentication and implements MAC-based access control.
The port services only one user passing 802.1X authentication.
•
userLoginSecureExt
This mode is similar to the userLoginSecure mode except that this mode supports multiple
online 802.1X users.
•
userLoginWithOUI
This mode is similar to the userLoginSecure mode. The difference is that a port in this mode
also permits frames from one user whose MAC address contains a specific OUI. The port
performs 802.1X authentication upon receiving 802.1X frames, and performs OUI check upon
receiving non-802.1X frames.
Performing MAC authentication
macAddressWithRadius: A port in this mode performs MAC authentication and services multiple
users.
Performing a combination of MAC authentication and 802.1X authentication
•
macAddressOrUserLoginSecure
This mode is the combination of the macAddressWithRadius and userLoginSecure modes. The
port performs MAC authentication 30 seconds after receiving non-802.1X frames and performs
802.1X authentication upon receiving 802.1X frames.
•
macAddressOrUserLoginSecureExt
This mode is similar to the macAddressOrUserLoginSecure mode except that this mode
supports multiple 802.1X and MAC authentication users.
•
macAddressElseUserLoginSecure
This mode is the combination of the macAddressWithRadius and userLoginSecure modes, with
MAC authentication having a higher priority as the Else keyword implies. The port performs
MAC authentication 30 seconds after receiving non-802.1X frames.
•
macAddressElseUserLoginSecureExt
158
This mode is similar to the macAddressElseUserLoginSecure mode except that this mode
supports multiple 802.1X and MAC authentication users as the keyword Ext implies.
NOTE:
An OUI, as defined by the IEEE, is the first 24 bits of the MAC address, which uniquely identifies a
device vendor.
Working with guest VLAN and Auth-Fail VLAN
An 802.1X guest VLAN is the VLAN that a user is in before initiating authentication.
An 802.1X Auth-Fail VLAN is the VLAN that a user is in after failing authentication.
For more information about 802.1X guest VLAN and Auth-Fail VLAN, see "Configuring 802.1X."
Configuration task list
Task
Remarks
Enabling port security
Required.
Setting port security's limit on the number of MAC addresses on a port
Optional.
Setting the port security mode
Required.
Configuring port security features:
•
Configuring NTK
•
Configuring intrusion protection
•
Enabling port security traps
Optional.
Configure one or more
features as required.
Configuring secure MAC addresses
Optional.
Ignoring authorization information from the server
Optional.
Enabling port security
When port security is enabled, you cannot manually enable 802.1X or MAC authentication, or
change the access control mode or port authorization state. The port security automatically modifies
these settings in different security modes.
Before you enable port security, disable 802.1X and MAC authentication globally.
To enable port security:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable port security.
port-security enable
By default, port security is disabled.
You can use the undo port-security enable command to disable port security when no online users
are present.
Enabling or disabling port security resets the following security settings to the default:
•
802.1X access control mode is MAC-based, and the port authorization state is auto.
•
Port security mode is noRestrictions.
159
For more information about Configuring 802.1X, see "Configuring 802.1X."
For more information about MAC authentication configuration, see "Configuring MAC
authentication."
Setting port security's limit on the number of MAC
addresses on a port
You can set the maximum number of MAC addresses that port security allows on a port for the
following purposes:
•
Controlling the number of concurrent users on the port. The maximum number of concurrent
users on the port equals this limit or the limit of the authentication mode (802.1X for example) in
use, whichever is smaller.
•
Controlling the number of secure MAC addresses on the port in autoLearn mode.
The port security's limit on the number of MAC addresses on a port is independent of the MAC
learning limit described in MAC address table configuration in the Layer 2—LAN Switching
Configuration Guide.
To set the maximum number of secure MAC addresses allowed on a port:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
3.
Set the limit of port security
on the number of secure
MAC addresses.
port-security max-mac-count
count-value
Not limited by default.
Setting the port security mode
After enabling port security, you can change the port security mode of a port only when the port is
operating in noRestrictions (the default) mode. To change the port security mode for a port in any
other mode, first use the undo port-security port-mode command to restore the default port
security mode.
You can specify a port security mode when port security is disabled, but your configuration cannot
take effect.
You cannot change the port security mode of a port when online users are present.
Configuration prerequisites
Before you set a port security mode for a port, complete the following tasks:
•
Disable 802.1X and MAC authentication.
•
If you are configuring the autoLearn mode, set port security's limit on the number of MAC
addresses. You cannot change the setting when the port is operating in autoLearn mode.
Configuration procedure
To enable a port security mode:
160
Step
Command
Remarks
1.
system-view
N/A
2.
Enter system view.
Set an OUI value for user
authentication.
Required for the
userlogin-withoui mode.
port-security oui oui-value
index index-value
Not configured by default.
To set multiple OUI values, repeat
this step.
3.
4.
Enter interface view.
interface interface-type
interface-number
To specify the autoLearn or
userLoginWithOUI mode, you
must enter Layer 2 Ethernet
interface view.
Set the port security mode.
port-security port-mode
{ autolearn |
mac-authentication |
mac-else-userlogin-secure |
mac-else-userlogin-secure-ext
| secure | userlogin |
userlogin-secure |
userlogin-secure-ext |
userlogin-secure-or-mac |
userlogin-secure-or-mac-ext |
userlogin-withoui }
By default, a port operates in
noRestrictions mode.
Configuring port security features
Configuring NTK
The NTK feature checks destination MAC addresses in outbound frames to make sure frames are
forwarded only to authenticated devices. Any unicast frame with an unknown destination MAC
address is discarded. Not all port security modes support triggering the NTK feature. For more
information, see Table 8.
The NTK feature supports the following modes:
•
ntkonly—Forwards only unicast frames with authenticated destination MAC addresses.
•
ntk-withbroadcasts—Forwards only broadcast frames and unicast frames with authenticated
destination MAC addresses.
•
ntk-withmulticasts—Forwards only broadcast frames, multicast frames, and unicast frames
with authenticated destination MAC addresses.
To configure the NTK feature:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
3.
Configure the NTK feature.
port-security ntk-mode
{ ntk-withbroadcasts |
ntk-withmulticasts | ntkonly }
By default, NTK is disabled on a
port and all frames are allowed to
be sent.
161
Configuring intrusion protection
Intrusion protection enables a device to take one of the following actions in response to illegal
frames:
•
blockmac—Adds the source MAC addresses of illegal frames to the blocked MAC addresses
list and discards the frames. All subsequent frames sourced from a blocked MAC address will
be dropped. A blocked MAC address is restored to normal state after being blocked for 3
minutes. The interval is fixed and cannot be changed.
•
disableport—Disables the port until you bring it up manually.
•
disableport-temporarily—Disables the port for a specific period of time. The period can be
configured with the port-security timer disableport command.
On a port operating in either the macAddressElseUserLoginSecure mode or the
macAddressElseUserLoginSecureExt mode, intrusion protection is triggered only after both MAC
authentication and 802.1X authentication fail for the same frame.
To configure the intrusion protection feature:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
3.
Configure the intrusion
protection feature.
port-security intrusion-mode
{ blockmac | disableport |
disableport-temporarily }
By default, intrusion protection is
disabled.
4.
Return to system view.
quit
N/A
5.
Set the silence timeout
period during which a port
remains disabled.
port-security timer disableport
time-value
Optional.
20 seconds by default.
Enabling port security traps
You can configure the port security module to send traps for the following categories of events:
•
addresslearned—Learning of new MAC addresses.
•
dot1xlogfailure/dot1xlogon/dot1xlogoff—802.1X authentication failure, success, and
802.1X user logoff.
•
ralmlogfailure/ralmlogon/ralmlogoff—MAC authentication failure, MAC authentication user
logon, and MAC authentication user logoff.
•
intrusion—Detection of illegal frames.
To enable port security traps:
Step
Command
Remarks
1.
Enter system
view.
system-view
N/A
2.
Enable port
security traps.
port-security trap { addresslearned |
dot1xlogfailure | dot1xlogoff | dot1xlogon |
intrusion | ralmlogfailure | ralmlogoff |
ralmlogon }
By default, port security
traps are disabled.
162
Configuring secure MAC addresses
Secure MAC addresses are configured or learned in autoLearn mode and can survive link down/up
events. You can bind a secure MAC address to only one port in a VLAN.
IMPORTANT:
When the maximum number of secure MAC address entries is reached, the port changes to secure
mode, and no more secure MAC addresses can be added or learned. The port allows only frames
sourced from a secure MAC address or a MAC address configured by using the mac-address
dynamic or mac-address static command to pass through.
Secure MAC addressesinclude static, sticky, and dynamic secure MAC addresses.
Table 9 A comparison of static, sticky, and dynamic secure MAC addresses
Type
Address sources
Aging mechanism
Can be saved and
survive a device
reboot?
Not available.
Static
Manually added
Sticky
Manually added,
converted from
dynamic secure
MAC addresses, or
automatically
learned when the
dynamic secure
MAC function
(port-security
mac-address
dynamic) is
disabled.
Dynamic
Converted from
sticky MAC
addresses or
automatically
learned after the
dynamic secure
MAC function is
enabled.
They never age out unless you manually
remove them, change the port security mode,
or disable the port security feature.
Sticky MAC addresses by default do not age
out, but you can configure an aging timer or
use the aging timer together with the inactivity
aging function to delete old sticky MAC
addresses:
•
If only an aging timer is configured, the
aging timer counts up regardless of
whether traffic data has been sent from
the sticky MAC address.
•
If both an aging timer and the inactivity
aging function are configured, the aging
timer restarts once traffic data is detected
from the sticky MAC address.
Yes.
Yes.
The secure MAC
aging timer restarts at
a reboot.
No.
Same as sticky MAC addresses.
All dynamic secure
MAC addresses are
lost at reboot.
Configuration prerequisites
•
Enable port security.
•
Set port security's limit on the number of MAC addresses on the port. Perform this task before
you enable autoLearn mode.
•
Set the port security mode to autoLearn.
Configuration procedure
To configure a secure MAC address:
163
Step
Command
Remarks
1.
system-view
N/A
Enter system view.
Optional.
2.
Set the secure MAC
aging timer.
port-security timer autolearn aging
time-value
•
3.
Configure a secure
MAC address.
•
By default, secure MAC
addresses do note age out, and
you can remove them only by
performing the undo
port-security mac-address
security command, changing the
port security mode, or disabling
the port security feature.
In system view:
port-security mac-address
security [sticky] mac-address
interface interface-type
interface-number vlan vlan-id
In Layer 2 Ethernet interface view:
Use either method.
a. interface interface-type
interface-number
No secure MAC address exists by
default.
b. port-security mac-address
security [ sticky ]
mac-address vlan vlan-id
c. quit
4.
Enter Layer 2 Ethernet
interface view.
interface interface-type
interface-number
5.
Enable inactivity
aging.
port-security mac-address
aging-type inactivity
N/A
Optional.
By default, the inactivity aging
function is disabled.
Optional.
6.
Enable the dynamic
secure MAC function.
port-security mac-address dynamic
By default, sticky MAC addresses
can be saved to the configuration
file, and once saved, can survive
a device reboot.
Ignoring authorization information from the server
Perform this task to configure a port to ignore the authorization information received from the server
(an RADIUS server or the local device) after an 802.1X user or MAC authentication user passes
authentication.
To configure a port to ignore authorization information from the server:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
3.
Ignore the authorization
information received from
the authentication server.
port-security authorization
ignore
By default, a port uses the
authorization information received
from the authentication server.
164
Displaying and maintaining port security
Task
Command
Remarks
Display port security configuration
information, operation
information, and statistics about
one or more ports or all ports.
display port-security [ interface interface-list ]
[ | { begin | exclude | include }
regular-expression ]
Available in any
view.
Display information about secure
MAC addresses.
display port-security mac-address security
[ interface interface-type interface-number ]
[ vlan vlan-id ] [ count ] [ | { begin | exclude |
include } regular-expression ]
Available in any
view.
Display information about blocked
MAC addresses.
display port-security mac-address block
[ interface interface-type interface-number ]
[ vlan vlan-id ] [ count ] [ | { begin | exclude |
include } regular-expression ]
Available in any
view.
Port security configuration examples
Configuring the autoLearn mode
Network requirements
See Figure 68. Configure port GigabitEthernet 3/0/1 on the Router, as follows:
•
Accept up to 64 users on the port without authentication.
•
Permit the port to learn and add MAC addresses as sticky MAC addresses, and set the secure
MAC aging timer to 30 minutes.
•
After the number of secure MAC addresses reaches 64, the port stops learning MAC addresses.
If any frame with an unknown MAC address arrives, intrusion protection starts, and the port
shuts down and stays silent for 30 seconds.
Figure 68 Network diagram
Configuration procedure
# Enable port security.
<Router> system-view
[Router] port-security enable
# Set the secure MAC aging timer to 30 minutes.
[Router] port-security timer autolearn aging 30
# Enable intrusion protection traps on port GigabitEthernet 3/0/1.
[Router] port-security trap intrusion
[Router] interface gigabitethernet 3/0/1
# Set port security's limit on the number of MAC addresses to 64 on the port.
165
[Router-GigabitEthernet3/0/1] port-security max-mac-count 64
# Set the port security mode to autoLearn.
[Router-GigabitEthernet3/0/1] port-security port-mode autolearn
# Configure the port to be silent for 30 seconds after the intrusion protection feature is triggered.
[Router-GigabitEthernet3/0/1] port-security intrusion-mode disableport-temporarily
[Router-GigabitEthernet3/0/1] quit
[Router] port-security timer disableport 30
Verifying the configuration
# Display the port security configuration.
<Router> display port-security interface gigabitethernet 3/0/1
Equipment port-security is enabled
Intrusion trap is enabled
AutoLearn aging time is 30 minutes
Disableport Timeout: 30s
OUI value:
GigabitEthernet3/0/1 is link-up
Port mode is autoLearn
NeedToKnow mode is disabled
Intrusion Protection mode is DisablePortTemporarily
Max MAC address number is 64
Stored MAC address number is 5
Authorization is permitted
Security MAC address learning mode is sticky
Security MAC address aging type is absolute
The output shows that the port security's limit on the number of secure MAC addresses on the port is
64, the port security mode is autoLearn, intrusion protection traps are enabled, and the intrusion
protection action is disabling the port (DisablePortTemporarily) for 30 seconds.
# Repeatedly perform the display port-security command to track the number of MAC addresses
learned by the port, or perform the display this command in interface view to display the learned
secure MAC addresses.
<Router> system-view
[Router] interface gigabitethernet 3/0/1
[Router-GigabitEthernet3/0/1] display this
#
interface GigabitEthernet3/0/1
port-security max-mac-count 64
port-security port-mode autolearn
port-security mac-address security sticky 0002-0000-0015 vlan 1
port-security mac-address security sticky 0002-0000-0014 vlan 1
port-security mac-address security sticky 0002-0000-0013 vlan 1
port-security mac-address security sticky 0002-0000-0012 vlan 1
port-security mac-address security sticky 0002-0000-0011 vlan 1
#
Perform the display port-security interface command after the number of MAC addresses learned
by the port reaches 64, and you can see that the port security mode has changed to secure.
166
# Execute the display interface command, and you can see that the port security feature has
disabled the port.
[Router-GigabitEthernet3/0/1] display interface gigabitethernet 3/0/1
GigabitEthernet3/0/1 current state: DOWN (Port Security Disabled)
IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: 000f-cb00-5558
Description: GigabitEthernet3/0/1 Interface
......
The port should be re-enabled 30 seconds later.
[Router-GigabitEthernet3/0/1] display interface gigabitethernet 3/0/1
GigabitEthernet3/0/1 current state: UP
IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: 000f-cb00-5558
Description: GigabitEthernet3/0/1 Interface
......
Delete several secure MAC addresses, and you can see that the port security mode of the port
changes to autoLearn, and the port can learn MAC addresses again.
Configuring the userLoginWithOUI mode
Network requirements
As shown in Figure 69, a client is connected to the Router through port GigabitEthernet 3/0/1. The
Router authenticates the client with a RADIUS server. If the authentication succeeds, the client is
authorized to access the Internet.
•
The RADIUS server at 192.168.1.2 functions as the primary authentication server and the
secondary accounting server, and the RADIUS server at 192.168.1.3 functions as the
secondary authentication server and the primary accounting server. The shared key for
authentication is name, and that for accounting is money.
•
All users use the default authentication, authorization, and accounting methods of ISP domain
sun, which can accommodate up to 30 users.
•
The RADIUS server response timeout time is 5 seconds and the maximum number of RADIUS
packet retransmission attempts is 5. The Router sends real-time accounting packets to the
RADIUS server at 15–minute intervals, and sends usernames without domain names to the
RADIUS server.
Configure port GigabitEthernet 3/0/1 of the Router to:
•
Allow only one 802.1X user to be authenticated.
•
Allow up to 16 OUI values to be configured and allow one terminal that uses any of the OUI
values to access the port in addition to an 802.1X user.
Figure 69 Network diagram
167
Configuration procedure
The following configuration steps cover some AAA/RADIUS configuration commands. For more
information about the commands, see Security Command Reference.
Configuration procedures for the host and RADIUS servers are not shown.
1.
Configure the RADIUS protocol:
# Configure a RADIUS scheme named radsun.
<Router> system-view
[Router] radius scheme radsun
[Router-radius-radsun] primary authentication 192.168.1.2
[Router-radius-radsun] primary accounting 192.168.1.3
[Router-radius-radsun] secondary authentication 192.168.1.3
[Router-radius-radsun] secondary accounting 192.168.1.2
[Router-radius-radsun] key authentication name
[Router-radius-radsun] key accounting money
[Router-radius-radsun] timer response-timeout 5
[Router-radius-radsun] retry 5
[Router-radius-radsun] timer realtime-accounting 15
[Router-radius-radsun] user-name-format without-domain
[Router-radius-radsun] quit
# Configure ISP domain sun to use RADIUS scheme radsun for authentication, authorization,
and accounting of all types of users. Specify that the ISP domain can contain up to 30 users.
[Router] domain sun
[Router-isp-sun] authentication default radius-scheme radsun
[Router-isp-sun] authorization default radius-scheme radsun
[Router-isp-sun] accounting default radius-scheme radsun
[Router-isp-sun] access-limit enable 30
[Router-isp-sun] quit
2.
Configure 802.1X:
# Set the 802.1X authentication method to CHAP. (This configuration is optional. By default, the
authentication method is CHAP for 802.1X.)
[Router] dot1x authentication-method chap
3.
Configure port security:
# Enable port security.
[Router] port-security enable
# Add five OUI values.
[Router] port-security oui 1234-0100-1111 index 1
[Router] port-security oui 1234-0200-1111 index 2
[Router] port-security oui 1234-0300-1111 index 3
[Router] port-security oui 1234-0400-1111 index 4
[Router] port-security oui 1234-0500-1111 index 5
[Router] interface gigabitethernet 3/0/1
# Set the port security mode to userLoginWithOUI.
[Router-GigabitEthernet3/0/1] port-security port-mode userlogin-withoui
[Router-GigabitEthernet3/0/1] quit
Verifying the configuration
# Display the RADIUS scheme radsun.
[Router] display radius scheme radsun
168
SchemeName
: radsun
Index : 1
Type : standard
Primary Auth Server:
IP: 192.168.1.2
Port: 1812
State: active
Port: 1813
State: active
Port: 1812
State: active
Port: 1813
State: active
Encryption Key : N/A
VPN instance
: N/A
Probe username : N/A
Probe interval : N/A
Primary Acct Server:
IP: 192.168.1.3
Encryption Key : N/A
VPN instance
: N/A
Probe username : N/A
Probe interval : N/A
Second Auth Server:
IP: 192.168.1.3
Encryption Key : N/A
VPN instance
: N/A
Probe username : N/A
Probe interval : N/A
Second Acct Server:
IP: 192.168.1.2
Encryption Key : N/A
VPN instance
: N/A
Auth Server Encryption Key : ******
Acct Server Encryption Key : ******
VPN instance
: N/A
Accounting-On packet disable, send times : 50 , interval : 3s
Interval for timeout(second)
: 5
Retransmission times for timeout
: 5
Interval for realtime accounting(minute)
: 15
Retransmission times of realtime-accounting packet
: 5
Retransmission times of stop-accounting packet
: 500
Quiet-interval(min)
: 5
Username format
: without-domain
Data flow unit
: Byte
Packet unit
: one
# Display the configuration of the ISP domain sun.
[Router] display domain sun
Domain : sun
State : Active
Access-limit : 30
Accounting method : Required
Default authentication scheme
: radius:radsun
Default authorization scheme
: radius:radsun
Default accounting scheme
: radius:radsun
Domain User Template:
Idle-cut : Disabled
169
Session-time : exclude-idle-time
Self-service : Disabled
Authorization attributes:
# Display the port security configuration.
<Router> display port-security interface gigabitethernet 3/0/1
[Router] display port-security interface gigabitethernet 3/0/1
Equipment port-security is enabled
Intrusion trap is enabled
AutoLearn aging time is 30 minutes
Disableport Timeout: 30s
OUI value:
Index is 1,
OUI value is 123401
Index is 2,
OUI value is 123402
Index is 3,
OUI value is 123403
Index is 4,
OUI value is 123404
Index is 5,
OUI value is 123405
GigabitEthernet3/0/1 is link-up
Port mode is userLoginWithOUI
NeedToKnow mode is disabled
Intrusion Protection mode is NoAction
Max MAC address number is not configured
Stored MAC address number is 0
Authorization is permitted
Security MAC address learning mode is sticky
Security MAC address aging type is absolute
After an 802.1X user gets online, you can see that the number of secure MAC addresses stored is 1.
# Display 802.1X information.
[Router] display dot1x interface GigabitEthernet 3/0/1
Equipment 802.1X protocol is enabled
CHAP authentication is enabled
Proxy trap checker is disabled
Proxy logoff checker is disabled
EAD quick deploy is disabled
Configuration: Transmit Period
30 s,
Quiet Period
Supp Timeout
Reauth Period
Handshake Period
Quiet Period Timer is disabled
30 s,
Server Timeout
3600 s
The maximal retransmitting times
2
EAD quick deploy configuration:
EAD timeout:
30m
The maximum 802.1X user resource number is 2048 per slot
Total current used 802.1X resource number is 1
GigabitEthernet3/0/1
15 s
60 s,
is link-up
802.1X protocol is enabled
170
100 s
Proxy trap checker is
disabled
Proxy logoff checker is disabled
Handshake is enabled
Handshake secure is disabled
802.1X unicast-trigger is enabled
Periodic reauthentication is disabled
The port is an authenticator
Authentication Mode is Auto
Port Control Type is Mac-based
802.1X Multicast-trigger is enabled
Mandatory authentication domain: NOT configured
Guest VLAN: NOT configured
Auth-Fail VLAN: NOT configured
Critical VLAN: NOT configured
Critical recovery-action: NOT configured
Max number of on-line users is 1024
EAPOL Packet: Tx 16331, Rx 102
Sent EAP Request/Identity Packets : 16316
EAP Request/Challenge Packets: 6
EAP Success Packets: 4, Fail Packets: 5
Received EAPOL Start Packets : 6
EAPOL LogOff Packets: 2
EAP Response/Identity Packets : 80
EAP Response/Challenge Packets: 6
Error Packets: 0
1. Authenticated user : MAC address: 0002-0000-0011
Controlled User(s) amount to 1
In addition, the port allows an additional user whose MAC address has an OUI among the specified
OUIs to access the port.
# Display MAC address information for interface GigabitEthernet 3/0/1.
[Router] display mac-address interface gigabitethernet 3/0/1
MAC ADDR
VLAN ID
STATE
PORT INDEX
AGING TIME(s)
1234-0300-0011
1
Learned
GigabitEthernet3/0/1
AGING
---
1 mac address(es) found
---
Configuring the macAddressElseUserLoginSecure mode
Network requirements
As shown in Figure 69, a client is connected to the Router through GigabitEthernet 3/0/1. The Router
authenticates the client by a RADIUS server. If the authentication succeeds, the client is authorized
to access the Internet.
Restrict port GigabitEthernet 3/0/1 of the Router:
•
Allow more than one MAC authenticated user to log on.
•
For 802.1X users, perform MAC authentication first and then, if MAC authentication fails,
802.1X authentication. Allow only one 802.1X user to log on.
171
•
Use the hyphenated, lowercased MAC address of a user as both the username and password
for MAC authentication of the user.
•
Set the total number of MAC authenticated users and 802.1X authenticated users to 64.
•
Enable NTK to prevent frames from being sent to unknown MAC addresses.
Configuration procedure
Configuration procedures for the host and RADIUS servers are not shown.
1.
Configure the RADIUS protocol:
Configure the RADIUS authentication/accounting and ISP domain settings the same as in
"Configuring the userLoginWithOUI mode."
2.
Configure port security:
# Enable port security.
<Router> system-view
[Router] port-security enable
# Use MAC-based user accounts for MAC authentication users. Each MAC address must be
hyphenated and in lowercase.
[Router] mac-authentication user-name-format mac-address with-hyphen lowercase
[Router] interface gigabitethernet 3/0/1
# Specify ISP domain sun for MAC authentication.
[Router] mac-authentication domain sun
[Router] interface gigabitethernet 3/0/1
# Set the 802.1X authentication method to CHAP. (This configuration is optional. By default, the
authentication method is CHAP for 802.1X.)
[Router] dot1x authentication-method chap
# Set port security's limit on the number of MAC addresses to 64 on the port.
[Router-GigabitEthernet3/0/1] port-security max-mac-count 64
# Set the port security mode to macAddressElseUserLoginSecure.
[Router-GigabitEthernet3/0/1] port-security port-mode mac-else-userlogin-secure
# Set the NTK mode of the port to ntkonly.
[Router-GigabitEthernet3/0/1] port-security ntk-mode ntkonly
[Router-GigabitEthernet3/0/1] quit
Verifying the configuration
# Display the port security configuration.
[Router] display port-security interface gigabitethernet 3/0/1
Equipment port-security is enabled
Intrusion trap is enabled
AutoLearn aging time is 30 minutes
Disableport Timeout: 30s
OUI value:
GigabitEthernet3/0/1 is link-up
Port mode is macAddressElseUserLoginSecure
NeedToKnow mode is NeedToKnowOnly
Intrusion Protection mode is NoAction
Max MAC address number is 64
Stored MAC address number is 0
Authorization is permitted
Security MAC address learning mode is sticky
172
Security MAC address aging type is absolute
# Display MAC authentication information.
[Router] display mac-authentication interface gigabitethernet 3/0/1
MAC address authentication is enabled.
User name format is MAC address in lowercase,like xx-xx-xx-xx-xx-xx
Fixed username:mac
Fixed password:not configured
Offline detect period is 300s
Quiet period is 60s
Server response timeout value is 100s
The max allowed user number is 2048 per slot
Current user number amounts to 3
Current domain is sun
Silent MAC User info:
MAC Addr
From Port
Port Index
GigabitEthernet3/0/1 is link-up
MAC address authentication is enabled
Authenticate success: 3, failed: 7
Max number of on-line users is 1024
Current online user number is 3
MAC ADDR
Authenticate state
1234-0300-0011
MAC_AUTHENTICATOR_SUCCESS
Auth Index
13
1234-0300-0012
MAC_AUTHENTICATOR_SUCCESS
14
1234-0300-0013
MAC_AUTHENTICATOR_SUCCESS
15
# Display 802.1X authentication information.
<Router> display dot1x interface GigabitEthernet 3/0/1
Equipment 802.1X protocol is enabled
CHAP authentication is enabled
Proxy trap checker is disabled
Proxy logoff checker is disabled
EAD quick deploy is disabled
Configuration: Transmit Period
30 s,
Handshake Period
Quiet Period
60 s,
Quiet Period Timer is disabled
Supp Timeout
30 s,
Server Timeout
The maximal retransmitting times
2
EAD quick deploy configuration:
EAD timeout:
30m
The maximum 802.1X user resource number is 2048 per slot
Total current used 802.1X resource number is 1
GigabitEthernet3/0/1
is link-up
802.1X protocol is enabled
173
15 s
100 s
Proxy trap checker is
disabled
Proxy logoff checker is disabled
Handshake is enabled
Handshake secure is disabled
802.1X unicast-trigger is enabled
Periodic reauthentication is disabled
The port is an authenticator
Authentication Mode is Auto
Port Control Type is Mac-based
802.1X Multicast-trigger is enabled
Mandatory authentication domain: NOT configured
Guest VLAN: NOT configured
Auth-Fail VLAN: NOT configured
Critical VLAN: NOT configured
Critical recovery-action: NOT configured
Max number of on-line users is 1024
EAPOL Packet: Tx 16331, Rx 102
Sent EAP Request/Identity Packets : 16316
EAP Request/Challenge Packets: 6
EAP Success Packets: 4, Fail Packets: 5
Received EAPOL Start Packets : 6
EAPOL LogOff Packets: 2
EAP Response/Identity Packets : 80
EAP Response/Challenge Packets: 6
Error Packets: 0
1. Authenticated user : MAC address: 0002-0000-0011
Controlled User(s) amount to 1
As NTK is enabled, frames with an unknown destination MAC address, multicast address, or
broadcast address will be discarded.
Troubleshooting port security
Cannot set the port security mode
Symptom
Cannot set the port security mode.
[Router-GigabitEthernet3/0/1] port-security port-mode autolearn
Error:When we change port-mode, we should first change it to noRestrictions, then change
it to the other.
Analysis
For ports operating in a port security mode other than noRestrictions, you cannot change the port
security mode directly using the port-security port-mode command.
Solution
Set the port security mode to noRestrictions first.
[Router-GigabitEthernet3/0/1] undo port-security port-mode
174
[Router-GigabitEthernet3/0/1] port-security port-mode autolearn
Cannot configure secure MAC addresses
Symptom
Cannot configure secure MAC addresses.
[Router-GigabitEthernet3/0/1] port-security mac-address security 1-1-2 vlan 1
Error: Security MAC address configuration failed.
Error:Can not operate security MAC address for current port mode is not autoLearn!
Analysis
Secure MAC addresses can be configured only on ports operating in autoLearn mode.
Solution
Set the port security mode to autoLearn.
[Router-GigabitEthernet3/0/1] undo port-security port-mode
[Router-GigabitEthernet3/0/1] port-security max-mac-count 64
[Router-GigabitEthernet3/0/1] port-security port-mode autolearn
[Router-GigabitEthernet3/0/1] port-security mac-address security 1-1-2 vlan 1
Cannot change port security mode when a user is online
Symptom
Port security mode cannot be changed when an 802.1X authenticated or MAC authenticated user is
online.
[RouterGigabitEthernet3/0/1] undo port-security port-mode
Error:Cannot configure port-security for there is 802.1X user(s) on line on port
GigabitEthernet3/0/1.
Analysis
Changing port security mode is not allowed when an 802.1X authenticated or MAC authenticated
user is online.
Solution
Use the cut command to forcibly disconnect the user from the port before changing the port security
mode.
[Router-GigabitEthernet3/0/1] quit
[Router] cut connection interface gigabitethernet 3/0/1
[Router] interface gigabitethernet 3/0/1
[Router-GigabitEthernet3/0/1] undo port-security port-mode
175
Configuring a user profile
Overview
A user profile provides a configuration template to save predefined configurations, such as a Quality
of Service (QoS) policy. Different user profiles are applicable to different application scenarios.
The user profile implements service applications on a per-user basis. Every time a user accesses the
device, the device automatically applies the configurations in the user profile that is associated only
with this user.
User-based traffic policing is more flexible than interface-based traffic policing. In interface-based
traffic policing, if a user moves between ports to access a device, you must remove the policy from
the previous port and then configure the same policy on the port being used to restrict user behaviors.
The configuration task is tedious and error prone.
The user profile supports working with L2TP, PPPoE, 802.1X and portal authentications and restricts
authenticated users' behaviors as follows:
1.
2.
After the authentication server verifies a user, the server sends the device the name of the user
profile associated with the user.
{
If the profile is enabled, the device applies the configurations in the user profile, and allows
user access based on all valid configurations.
{
If the user profile is disabled, the device denies the user access.
After the user logs out, the device automatically disables the configurations in the user profile,
and the restrictions on the user access are removed.
User profile configuration task list
Task
Remarks
Creating a user profile
Required.
Performing configurations in user profile view
Required.
Enabling a user profile
Required.
Creating a user profile
Before you create a user profile, complete the following tasks:
•
Configure authentication parameters on the device.
•
Perform configurations on the client, the device, and the authentication server, for example,
username, password, authentication scheme, domain, and binding a user profile with a user.
To create a user profile:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a user profile,
and enter its view.
user-profile profile-name
You can use the command to enter the view
of an existing user profile.
176
Performing configurations in user profile view
After a user profile is created, perform configurations in user profile view. The configuration made in
user profile view takes effect when the user profile is enabled and a user using the user profile goes
online.
Supported configurations include QoS policies. The QoS policies applied in user profile view support
only the remark, car, and filter actions.
For more information about QoS policies, see ACL and QoS Configuration Guide.
Enabling a user profile
Enable a user profile so that configurations in the profile can be applied by the device to restrict user
behaviors. If the device detects that the user profile is disabled, the device denies the associated
user even the user has been verified by the authentication server.
You can only edit or remove the configurations in a disabled user profile.
Disabling a user profile logs out the users that are using the user profile.
To enable a user profile:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable a user profile.
user-profile profile-name enable
A user profile is disabled by
default.
Displaying and maintaining user profile
Task
Command
Remarks
Display information about all the
created user profiles.
display user-profile [ | { begin |
exclude | include } regular-expression ]
Available in any view.
177
Configuring password control
Overview
Password control refers to a set of functions provided by the local authentication server to control
user login passwords, super passwords, and user login status based on predefined policies. The rest
of this section describes password control functions in detail.
•
Minimum password length
By setting a minimum password length, you can enforce users to use passwords long enough
for system security. If a user specifies a shorter password, the system rejects the setting and
prompts the user to re-specify a password.
•
Minimum password update interval
This function allows you to set the minimum interval at which users can change their passwords.
If a non-manage level user logs in to change the password but the time elapsed since the last
change is less than this interval, the system denies the request. For example, if you set this
interval to 48 hours, a non-manage level user cannot change the password twice within 48
hours. This prevents users from changing their passwords frequently.
This function is not effective on users of the manage level. For information about user levels,
see Fundamentals Configuration Guide.
This function is not effective on a user who is prompted to change the password at the first login
or a user whose password has just been aged out.
•
Password aging
Password aging imposes a lifecycle on a user password. After the password aging time expires,
the user needs to change the password.
If a user enters an expired password when logging in, the system displays an error message
and prompts the user to provide a new password and to confirm it by entering it again. The new
password must be a valid one and the user must enter exactly the same password when
confirming it.
•
Early notice on pending password expiration
When a user logs in, the system checks whether the password will expire in a time equal to or
less than the specified notification period. If so, the system notifies the user when the password
will expire and provides a choice for the user to change the password. If the user sets a new
password that is complexity-compliant, the system records the new password and the setup
time. If the user chooses not to change leave the password or the user fails to change it, the
system allows the user to log in using the current password.
Telnet, SSH, and terminal users (log in to the device through console or AUX interfaces) can
change their passwords by themselves. FTP users, on the contrary, can only have their
passwords changed by the administrator.
•
Login with an expired password
You can allow a user to log in a certain number of times within a specific period of time after the
password expires, so that the user does not need to change the password immediately. For
example, if you set the maximum number of logins with an expired password to 3 and the time
period to 15 days, a user can log in three times within 15 days after the password expires.
•
Password history
With this feature enabled, the system maintains certain entries of passwords that a user has
used. When a user changes the password, the system checks the new password against the
history passwords and the current password. The new password must be different from the
used ones by at least four characters and the four characters must not be the same. Otherwise,
the user will fail to change the password and the system displays an error message.
178
You can set the maximum number of history password records for the system to maintain for
each user. When the number of history password records exceeds your setting, the latest
record overwrites the earliest one.
•
Login attempt limit
Limiting the number of consecutive failed login attempts can effectively prevent password
guessing.
If an FTP or VTY user fails authentication due to a password error, the system adds the user to
a password control blacklist. If a user fails to provide the correct password after the specified
number of consecutive attempts, the system takes action as configured:
{
Prohibiting the user from logging in until the user is removed from the password control
blacklist manually.
{
Allowing the user to try continuously and removing the user from the password control
blacklist when the user logs in to the system successfully or the blacklist entry times out (the
blacklist entry times out after 1 minute).
{
Prohibiting the user from logging in within a configurable period of time, and allowing the
user to log in again after the period of time elapses or the user is removed from the
password control blacklist.
A password control blacklist can contain up to 1024 entries.
A login attempt using a wrong username will undoubtedly fail but the username will not be
added into the password control blacklist.
Users accessing the system through the console or AUX interface are not blacklisted, because
the system is unable to obtain the IP addresses of these users and these users are privileged
and therefore relatively secure to the system.
•
Password composition policy
A password can be a combination of characters from the following four types:
{
Uppercase letters A to Z
{
Lowercase letters a to z
{
Digits 0 to 9
{
Special characters. For information about special characters, see the password command
in Security Command Reference.
Depending on the system security requirements, you can set the minimum number of character
types a password must contain and the minimum number of characters for each type, as shown
in Table 10.
Table 10 Password composition policy
Password
combination level
Minimum number of
character types
Minimum number of characters
for each type
Level 1
One
One
Level 2
Two
One
Level 3
Three
One
Level 4
Four
One
In non-FIPS mode, all the combination levels are available for a password. In FIPS mode, only
the level 4 combination is available for a password.
When a user sets or changes the password, the system checks if the password meets the
composition requirement. If not, the system displays an error message.
•
Password complexity checking policy
A less complicated password such as a password containing the username or repeated
characters is more likely to be cracked. For security purposes, you can configure a password
179
complexity checking policy to make sure that all user passwords are relatively complicated.
With such a policy configured, when a user configures a password, the system checks the
complexity of the password. If the password is complexity-incompliant, the system refuses the
password and displays a password configuration failure message.
You can impose the following password complexity requirements:
•
{
A password cannot contain the username or the reverse of the username. For example, if
the username is abc, a password such as abc982 or 2cba is not complex enough.
{
No character of the password is repeated three or more times consecutively. For example,
password a111 is not complex enough.
Password display in the form of a string of asterisks (*)
For the sake of security, the password a user enters is displayed in the form of a string of
asterisks (*).
•
Authentication timeout management
Authentication timeout management is only for Telnet and Terminal users.
The authentication period is from when the server obtains the username to when the server
finishes authenticating the user's password. If a user fails to log in within the configured period
of time, the system tears down the connection.
•
Maximum account idle time
You can set the maximum account idle time so that accounts staying idle for this period of time
become invalid. For example, if you set the maximum account idle time to 60 days and the user
of the account test has not logged in successfully within 60 days after the last successful login,
the account becomes invalid and the user is unable to log in again.
•
Logging
The system logs all successful password changing events and the events of adding users to the
password control blacklist.
FIPS compliance
The router supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for
features, commands, and parameters might differ in FIPS mode (see "Configuring FIPS") and
non-FIPS mode.
Password control configuration task list
The password control functions can be configured in several views, and different views support
different functions. The settings configured in different views or for different objects have different
application ranges and different priorities:
•
Settings for super passwords apply only to super passwords.
•
Settings in local user view apply only to the password of the local user.
•
Settings in user group view apply to the passwords of the local users in the user group if you do
not configure password policies for these users in local user view.
•
Global settings in system view have the following application situations:
{
They apply to the passwords of local users in all user groups if you do not configure
password policies for these users in both local user view and user group view.
{
They apply to the super passwords if you do not configure password policies for super
passwords.
The previous four types of settings have the following priorities:
{
For local user passwords, the settings with a smaller application range have higher priority.
180
{
For super passwords, the settings configured specifically for super passwords, if any,
override those configured globally.
To configure password control:
Task
Remarks
Enabling password control
Required.
Setting global password control parameters
Optional.
Setting user group password control parameters
Optional.
Setting local user password control parameters
Optional.
Setting super password control parameters
Optional.
Setting a local user password in interactive mode
Optional.
Enabling password control
To enable password control functions:
1.
Enable the global password control feature in system view.
Password control configurations take effect only after the password control feature is enabled
globally.
2.
Enable password control functions individually.
The following password control functions need to be enabled individually after the password
control feature is enabled globally:
{
Password aging
{
Minimum password length
{
Password history
{
Password composition checking
To enable password control:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the global password
control feature.
password-control enable
By default, the global password
control feature is disabled.
3.
Enable a specific password
control function.
password-control { aging |
composition | history | length }
enable
Optional.
All of the four password control
functions are enabled by default.
After global password control is enabled, local user passwords configured on the device are not
displayed when you use the corresponding display command.
Setting global password control parameters
The action specified by the password-control login-attempt command takes effect immediately
and affects the users already in the password control blacklist. Other password control
configurations take effect only on users logging in later and passwords configured later.
To set global password control parameters:
181
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Set the password aging
time.
password-control aging
aging-time
Optional.
Set the minimum password
update interval.
password-control password
update interval interval
Optional.
Set the minimum password
length.
password-control length length
3.
4.
5.
Configure the password
composition policy.
password-control composition
type-number type-number
[ type-length type-length ]
6.
Configure the password
complexity checking policy.
password-control complexity
{ same-character | user-name }
check
7.
Set the maximum number of
history password records for
each user.
password-control history
max-record-num
8.
9.
90 days by default.
24 hours by default.
Optional.
10 characters by default.
Optional.
•
In non-FIPS mode:
By default, a password must
contain at least one type of
characters and each type
must contain at least one
character.
•
In FIPS mode:
By default, a password must
contain four types of
characters and each type
must contain at least one
character.
Optional.
By default, the system does not
perform password complexity
checking.
Optional.
4 by default.
Optional.
Specify the maximum
number of login attempts
and the action to be taken
when a user fails to log in
after the specified number of
attempts.
password-control login-attempt
login-times [ exceed { lock |
lock-time time | unlock } ]
By default, the maximum number
of login attempts is 3 and a user
failing to log in after the specified
number of attempts must wait for
1 minute before trying again.
Set the number of days
during which the user is
warned of the pending
password expiration.
password-control
alert-before-expire alert-time
Optional.
7 days by default.
10. Set the maximum number of
days and maximum number
of times that a user can log
in after the password
expires.
password-control
expired-user-login delay delay
times times
11. Set the authentication
timeout time.
password-control
authentication-timeout
authentication-timeout
Optional.
12. Set the maximum account
idle time.
password-control login
idle-time idle-time
Optional.
Optional.
By default, a user can log in three
times within 30 days after the
password expires.
60 seconds by default.
90 days by default.
Setting user group password control parameters
182
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a user group and
enter user group view.
user-group group-name
N/A
3.
Configure the password
aging time for the user
group.
password-control aging
aging-time
4.
Configure the minimum
password length for the user
group.
password-control length length
Configure the password
composition policy for the
user group.
password-control composition
type-number type-number
[ type-length type-length ]
Optional.
By default, the aging time of the
user group is the same as the
global password aging time.
Optional.
By default, the minimum
password length of the user group
is the same as the global
minimum password length.
Optional.
5.
By default, the password
composition policy of the user
group is the same as the global
password composition policy.
Setting local user password control parameters
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a local user and enter
local user view.
local-user user-name
N/A
Optional.
3.
Configure the password
aging time for the local user.
password-control aging
aging-time
By default, the setting equals that
for the user group to which the
local user belongs. If no aging
time is configured for the user
group, the global setting applies
to the local user.
Optional.
4.
Configure the minimum
password length for the local
user.
password-control length length
By default, the setting equals that
for the user group to which the
local user belongs. If no minimum
password length is configured for
the user group, the global setting
applies to the local user.
Optional.
5.
Configure the password
composition policy for the
local user.
password-control composition
type-number type-number
[ type-length type-length ]
183
By default, the settings equal
those for the user group to which
the local user belongs. If no
password composition policy is
configured for the user group, the
global settings apply to the local
user.
Setting super password control parameters
CLI commands include four levels: visit, monitor, system, and manage, in ascending order.
Accordingly, login users are divided into four levels, each corresponding to a command level. A user
of a certain level can only use the commands at that level or lower levels.
To switch from a lower user level to a higher one, a user needs to enter a password for authentication.
This password is called a super password. For more information on super passwords, see
Fundamentals Configuration Guide.
To set super password control parameters:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Set the password aging time
for super passwords.
password-control super aging
aging-time
Optional.
By default, the super password
aging time is the same as the
global password aging time.
Optional.
3.
Configure the minimum
length for super passwords.
password-control super length
length
4.
Configure the password
composition policy for super
passwords.
password-control super
composition type-number
type-number [ type-length
type-length ]
By default, the minimum super
password length is the same as
the global minimum password
length.
Optional.
By default, the super password
composition policy is the same as
the global password composition
policy.
Setting a local user password in interactive mode
You can set a password for a local user in interactive mode. When doing so, you need to confirm the
password.
To set a password for a local user in interactive mode:
Step
Command
1.
Enter system view.
system-view
2.
Create a local user and enter local user view.
local-user user-name
3.
Set the password for the local user in interactive mode.
password
Displaying and maintaining password control
Task
Command
Remarks
Display password control
configuration information.
display password-control
[ super ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
184
Task
Command
Remarks
Display information about users in
the password control blacklist.
display password-control
blacklist [ user-name name | ip
ipv4-address | ipv6 ipv6-address ]
[ | { begin | exclude | include }
regular-expression ]
Available in any view.
Delete users from the password
control blacklist.
reset password-control
blacklist { all | user-name
name }
Available in user view.
Available in user view.
Clear history password records.
reset password-control
history-record [ user-name
name | super [ level level ] ]
This command can delete the
history password records of one
or all users even when the
password history function is
disabled.
Password control configuration example
Network requirements
Implement the following global password control policy:
•
An FTP or VTY user failing to provide the correct password in two successive login attempts is
permanently prohibited from logging in.
•
A user can log in five times within 60 days after the password expires.
•
The password expires after 30 days.
•
The minimum password update interval is 36 hours.
•
The maximum account idle time is 30 days.
•
A password cannot contain the username or the reverse of the username.
•
No character occurs consecutively three or more times in a password.
Implement the following super password control policy:A super password must contain at least three
types of valid characters, five or more of each type.
Implement the following password control policy for local Telnet user test:
•
The password must contain at least 12 characters.
•
The password must consist of at least two types of valid characters, five or more of each type.
•
The password for the local user expires after 20 days.
Configuration procedure
# Enable the password control feature globally.
<Sysname> system-view
[Sysname] password-control enable
# Prohibit the user from logging in forever after two successive login failures.
[Sysname] password-control login-attempt 2 exceed lock
# Globally set all passwords to expire after 30 days
[Sysname] password-control aging 30
# Set the minimum password update interval to 36 hours.
[Sysname] password-control password update interval 36
# Specify that a user can log in five times within 60 days after the password expires.
185
[Sysname] password-control expired-user-login delay 60 times 5
# Set the maximum account idle time to 30 days.
[Sysname] password-control login idle-time 30
# Refuse any password that contains the username or the reverse of the username.
[Sysname] password-control complexity user-name check
# Specify that no character of the password can be repeated three or more times consecutively.
[Sysname] password-control complexity same-character check
# Specify that all super passwords must each contain at least three types of valid characters and
each type contains at least five characters.
[Sysname] password-control super composition type-number 3 type-length 5
# Configure a super password.
[Sysname] super password level 3 simple 12345ABGFTweuix
# Create a local user named test.
[Sysname] local-user test
# Set the service type of the user to Telnet.
[Sysname-luser-test] service-type telnet
# Set the minimum password length to 12 for the local user.
[Sysname-luser-test] password-control length 12
# Specify that the passwords of the local user must contain at least two types of valid characters and
each type contains at least five characters.
[Sysname-luser-test] password-control composition type-number 2 type-length 5
# Set the password for the local user to expire after 20 days.
[Sysname-luser-test] password-control aging 20
# Configure the password of the local user in interactive mode.
[Sysname-luser-test] password
Password:***********
Confirm :***********
Updating user(s) information, please wait........
[Sysname-luser-test] quit
Verifying the configuration
# Display the global password control configuration.
<Sysname> display password-control
Global password control configurations:
Password control:
Enabled
Password aging:
Enabled (30 days)
Password length:
Enabled (10 characters)
Password composition:
Enabled (1 types,
Password history:
Enabled (max history record:4)
1 characters per type)
Early notice on password expiration: 7 days
User authentication timeout:
60 seconds
Maximum failed login attempts:
2 times
Login attempt-failed action:
Lock
Minimum password update time:
36 hours
User account idle-time:
30 days
Login with aged password:
5 times in 60 day(s)
186
Password complexity:
Enabled (username checking)
Enabled (repeated characters checking)
# Display the password control configuration for super passwords.
<Sysname> display password-control super
Super password control configurations:
Password aging:
Enabled (30 days)
Password length:
Enabled (10 characters)
Password composition:
Enabled (3 types,
5 characters per type)
# Display the password control configuration for local user test.
<Sysname> display local-user user-name test
The contents of local user test:
State:
Active
ServiceType:
telnet
Access-limit:
Disable
User-group:
system
Current AccessNum: 0
Bind attributes:
Authorization attributes:
Password aging:
Enabled (20 days)
Password length:
Enabled (12 characters)
Password composition:
Enabled (2 types,
Total 1 local user(s) matched.
187
5 characters per type)
Configuring RSH
Remote shell (RSH) allows users to execute OS commands on a remote host that runs the RSH
daemon.
Windows NT, 2000, XP, and 2003 are shipped with no RSH daemon. The RSH daemon must be
separately obtained and installed on the remote host.
The RSH daemon supports authentication of an RSH client by the username. Figure 70 shows a
network diagram for the typical RSH application.
Figure 70 RSH application
Configuration prerequisites
•
Run RSH daemon on the remote host.
•
Make sure there are routes between the device and the remote host.
Configuration procedure
To execute a remote host OS command from the device:
Task
Command
Execute an OS command of a
remote host.
rsh host [ user username ]
command remote-command
Remarks
Available in user view.
If RSH daemon authentication is enabled on the remote host, you must provide the username
configured on the remote host in advance.
RSH configuration example
Network requirements
As shown in Figure 71, run Windows 2000 on the remote host and start the RSH daemon service on
it. Use the router to set the time of the remote host remotely.
Figure 71 Network diagram
Configuration Procedure
1.
Check that the RSH daemon has been installed and started properly on the remote host:
188
a. From the Windows Control Panel, open the Administrative Tools folder. (For Windows XP,
if you use the category view of the Control Panel window, select Administrative Tools
from Performance and Maintenance.)
Figure 72 Administrative Tools folder
b. Double-click the Services icon to display the Services window.
Figure 73 Services window
c. Check for the Remote Shell Daemon entry. If it does not exist, install the daemon first.
d. Look at the Status column to check whether the Remote Shell Daemon service is started.
In this example, the service is not started yet.
e. Double-click the Remote Shell Daemon service row, and then in the popped up Remote
Shell Daemon Properties window, click Start to start the service, as shown in Figure 74.
189
Figure 74 Remote Shell Daemon Properties window
2.
Configure the router:
# Configure a route to the remote host. (Details not shown.)
# Set the time of the host remotely.
<Router>rsh 192.168.1.10 command time
Trying 192.168.1.10 ...
Press CTRL+K to abort
The current time is:
6:56:42.57
Enter the new time: 12:00
12:00
190
Managing public keys
To protect data confidentiality during transmission, the data sender uses an algorithm and a key to
encrypt the plain text data before sending the data out. The receiver uses the same algorithm with
the help of a key to decrypt the data, as shown in Figure 75.
Figure 75 Encryption and decryption
The keys that participate in the conversion between plain text and cipher text can be the same or
different, dividing the encryption and decryption algorithms into the following types:
•
Symmetric key algorithm—The keys for encryption and decryption are the same.
•
Asymmetric key algorithm—The keys for encryption and decryption are different. One is the
public key, and the other is the private key. The information encrypted with the public key can
only be decrypted with the corresponding private key, and vice versa. The private key is kept
secret, and the public key may be distributed widely. The private key cannot be practically
derived from the public key. Asymmetric key algorithms include RSA and DSA.
The asymmetric key algorithms can be used for the following purposes:
•
To encrypt and decrypt data—Any public key receiver can use the public key to encrypt
information, but only the private key owner can decrypt the information. This mechanism
ensures confidentiality. Only RSA can be used for data encryption and decryption.
•
To authenticate a sender—Also called "digital signature." The key owner uses the private key
to "sign" information to be sent, and the receiver decrypts the information with the sender's
public key to verify information authenticity. RSA and DSA can be used for digital signature.
Asymmetric key algorithms are widely used in various applications. For example, SSH and PKI use
the algorithms for digital signature. For information about SSH and PKI, see "Configuring SSH" and
"Configuring PKI."
FIPS compliance
The router supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for
features, commands, and parameters might differ in FIPS mode (see "Configuring FIPS") and
non-FIPS mode.
Configuration task list
Public key configuration tasks enable you to manage the local asymmetric key pairs and configure
the peer host public keys on the local device. By completing these tasks, the local device is ready to
work with applications such as SSH to implement data encryption/decryption, or digital signature.
Complete these tasks to configure public keys:
Task
Configuring a local asymmetric
Remarks
Creating a local asymmetric key pair
191
Choose one or
Task
Remarks
key pair on the local device
more tasks.
Displaying or exporting the local host public key
Destroying a local asymmetric key pair
Exporting an RSA key pair
Importing an RSA key pair
Specifying the peer public key on the local device
Required.
Creating a local asymmetric key pair
When you create an asymmetric key pair on the local device, follow these guidelines:
•
Create an asymmetric key pair of the proper type to work with a target application.
•
After you enter the command, specify a proper modulus length for the key pair. The following
table compares these types of key pairs.
Table 11 A comparison between different types of asymmetric key pairs
Type
Number of key pairs
Modulus length
RSA
Two key pairs, one server key pair and
one host key pair. Each key pair
comprises a public key and a private key.
512 to 2048 bits.
DSA
One key pair, the host key pair.
1024 by default.
512 to 2048 bits.
Remarks
To achieve high
security, specify at least
768 bits.
1024 by default.
IMPORTANT:
Only SSH1.5 uses the RSA server key pair.
To create a local asymmetric key pair:
Step
Command
Remarks
1.
system-view
N/A
Enter system view.
By default, no asymmetric key pair is
created.
2.
Create a local
asymmetric key pair.
public-key local create
{ dsa | rsa } [ name
key-name ]
Key pairs created with this command are
saved automatically and can survive
system reboots.
In FIPS mode, the DSA key modulus length
is at least 1024 bits, and the RSA key
modulus length must be 2048 bits.
Displaying or exporting the local host public key
In some applications, such as SSH, to allow your local device to be authenticated by a peer device
through digital signature, you must display or export the local host public key, which will then be
specified on the peer device.
To display or export the local host public key, choose one of the following methods:
•
Displaying and recording the host public key information
192
•
Displaying the host public key in a specific format and saving it to a file
•
Exporting the host public key in a specific format to a file
If your local device functions to authenticate the peer device, you must specify the peer public key on
the local device. For more information, see "Specifying the peer public key on the local device."
Displaying and recording the host public key
information
Task
Command
Remarks
Display the local RSA public keys.
display public-key local rsa public [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Display the local DSA host public
key.
display public-key local dsa public [ |
{ begin | exclude | include }
regular-expression ]
Use at least one
command.
The display public-key local rsa public command displays both the RSA server and host public
keys. Recording the RSA host public key is enough.
After you display the host public key, record the key information for manually configuration of the key
on the peer device.
Displaying the host public key in a specific format
and saving it to a file
Step
Command
Remarks
1.
system-view
N/A
Enter system view.
•
2.
Display the local host
public key in a specific
format.
•
Display the RSA host public key:
public-key local export public
rsa { openssh | ssh1 | ssh2 }
Display the DSA host public key:
public-key local export public
dsa { openssh | ssh2 }
Use at least one command.
After you display the host public key in a specific format, save the key to a file, and transfer the file to
the peer device.
Exporting the host public key in a specific format
to a file
Step
Command
Remarks
1.
system-view
N/A
Enter system view.
193
Step
Command
•
2.
Export the local host public
key in a specific format to a
file.
•
Remarks
Export the RSA host public
key:
public-key local export rsa
{ openssh | ssh1 | ssh2 }
filename
Export the DSA host public
key:
public-key local export dsa
{ openssh | ssh2 } filename
Use at least one command.
After you export the host public key in a specific format to a file, transfer the file to the peer device.
Destroying a local asymmetric key pair
You might have to destroy a local asymmetric key pair and generate a new pair when an intrusion
event has occurred, the storage media of the device is replaced, the asymmetric key has been used
for a long time, or the local certificate expires. For more information about the local certificate, see
"Configuring PKI."
To destroy a local asymmetric key pair:
Step
Command
1.
Enter system view.
system-view
2.
Destroy a local asymmetric key pair.
public-key local destroy { dsa | rsa } [ name
key-name ]
Exporting an RSA key pair
To copy a local RSA key pair to another device, you must export the RSA key pair on the local device
and then import it to the target router. For information about importing an RSA key pair, see
"Importing an RSA key pair."
To export an RSA key pair:
Step
Command
Remarks
1.
system-view
N/A
2.
Enter system view.
Export an RSA key pair in
PEM format.
public-key local export rsa name
key-name pem { 3des-cbc |
aes-cbc-128 | aes-cbc-192 |
aes-cbc-256 | des-cbc } password
The command displays the
public key and private key of the
exported RSA key pair in PEM
format on the terminal. The
private key is encrypted using
the encryption algorithm and
password specified in the
command.
You cannot export the default
RSA key pair.
Importing an RSA key pair
After you export an RSA key pair on a device, you can import the key pair to another device.
194
To import an RSA key pair:
Step
Command
Remarks
1.
system-view
N/A
2.
Enter system view.
Import an RSA key pair.
public-key local import rsa
name key-name pem
After you execute the public-key
local import command, copy the
private key of the RSA key pair at the
prompt (the public key is included in
the private key), press Ctrl+C, and
then enter the password used to
encrypt the RSA key pair when the
key pair was exported.
You cannot use an imported RSA key
pair as the default RSA key pair.
The RSA key pair to be imported must
be in PEM format.
Specifying the peer public key on the local device
In SSH, to enable the local device to authenticate a peer device, specify the peer public key on the
local device. The device supports up to 20 peer public keys.
For information about displaying or exporting the host public key, see "Displaying or exporting the
local host public key."
To specify the peer public key on the local device:
Method
Prerequisites
1.
Import the public key
from a public key file
(recommended)
2.
•
Manually configure
the public key—input
or copy the key data
•
Remarks
Save the host public key of the
intended asymmetric key pair in a file.
Transfer a copy of the file through
FTP or TFTP in binary mode to the
local device.
Display and record the public key of
the intended asymmetric key pair.
If the peer device is an HPE device,
use the display public-key local
public command to view and record
its public key. A public key displayed
by other methods for the HPE device
may not be in a correct format.
During the import process, the system
automatically converts the public key
to a string in Public Key Cryptography
Standards (PKCS) format.
•
•
The recorded public key must be
in the correct format, or the
manual configuration of a
format-incompliant public key
will fail.
Always use the first method if
you are not sure about the
format of the recorded public
key.
To import the host public key from a public key file to the local device:
Step
Command
1.
Enter system view.
system-view
2.
Import the host public key from the public key
file.
public-key peer keyname import sshkey filename
To manually configure the peer public key on the local device:
Step
Command
Remarks
1.
system-view
N/A
Enter system view.
195
Step
Command
Remarks
Specify a name for the public
key and enter public key
view.
public-key peer keyname
N/A
3.
Enter public key code view.
public-key-code begin
N/A
4.
Configure the peer public
key.
Type or copy the key
Spaces and carriage
returns are allowed
between characters.
2.
5.
Return to public key view.
public-key-code end
When you exit public key
code view, the system
automatically saves the
public key.
6.
Return to system view.
peer-public-key end
N/A
Displaying public keys
Task
Command
Remarks
Display the local public keys
display public-key local { dsa | rsa }
public [ | { begin | exclude | include }
regular-expression ]
Available in any view.
Display the specified or all peer
public keys on the local device.
display public-key peer [ brief | name
publickey-name ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Public key configuration examples
Manually specifying the peer public key on the local device
Network requirements
As shown in Figure 76, to prevent illegal access, Router B (the local device) authenticates Router A
(the peer device) through a digital signature. Before configuring authentication parameters on Router
B, configure the public key of Router A on Router B.
•
Configure Router B to use the asymmetric key algorithm of RSA to authenticate Router A.
•
Manually specify the host public key of Router A's public key pair on Router B.
Figure 76 Network diagram
Configuration procedure
1.
Configure Router A:
# Create a local RSA key pair with the default name and the default modulus length of 1024 bits.
<RouterA> system-view
[RouterA] public-key local create rsa
The range of public key size is (512 ~ 2048).
196
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Press CTRL+C to abort.
Input the bits of the modulus[default = 1024]:
Generating Keys...
++++++
++++++
++++++++
++++++++
# Display the public keys of the local RSA key pairs.
[RouterA] display public-key local rsa public
=====================================================
Time of Key pair created: 09:50:06
2007/08/07
Key name: HOST_KEY
Key type: RSA Encryption Key
=====================================================
Key code:
30819F300D06092A864886F70D010101050003818D0030818902818100D90003FA95F5A44A2A2CD3F
814F
9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E766BD
995C
669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA326470034DC07
8B2B
AA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A10203010001
=====================================================
Time of Key pair created: 09:50:07
2007/08/07
Key name: SERVER_KEY
Key type: RSA Encryption Key
=====================================================
Key code:
307C300D06092A864886F70D0101010500036B003068026100999089E7AEE9802002D9EB2D0433B87
BB61
58E35000AFB3FF310E42F109829D65BF70F7712507BE1A3E0BC5C2C03FAAF00DFDDC63D004B4490DA
CBA3
CFA9E84B9151BDC7EECE1C8770D961557D192DE2B36CAF9974B7B293363BB372771C2C1F020301000
1
2.
Configure Router B:
# Configure the host public key of Router A's RSA key pairs on Router B. In public key code
view, enter the host public key of Router A. The host public key is the content of HOST_KEY
displayed on Router A by using the display public-key local dsa public command.
<RouterB> system-view
[RouterB] public-key peer routera
Public key view: return to System View with "peer-public-key end".
[RouterB-pkey-public-key] public-key-code begin
Public key code view: return to last view with "public-key-code end".
[RouterB-pkey-key-code]30819F300D06092A864886F70D010101050003818D0030818902818100
D900
03FA95F5A44A2A2CD3F814F9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E5
197
1E5E
353B3A9AB16C9E766BD995C669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62
DB12
5035EA326470034DC078B2BAA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A
1020
3010001
[RouterB-pkey-key-code] public-key-code end
[RouterB-pkey-public-key] peer-public-key end
# Display the host public key of Router A saved on Router B.
[RouterB] display public-key peer name routera
=====================================
Key Name
: routera
Key Type
: RSA
Key Module: 1024
=====================================
Key Code:
30819F300D06092A864886F70D010101050003818D0030818902818100D90003FA95F5A44A2A2CD3F
814F
9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E766BD
995C
669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA326470034DC07
8B2B
AA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A10203010001
The output shows that the host public key of Router A saved on Router B is consistent with the
one created on Router A.
Importing a public key from a public key file
Network requirements
As shown in Figure 77, to prevent illegal access, Router B (the local device) authenticates Router A
(the peer device) through a digital signature. Before configuring authentication parameters on Router
B, configure the public key of Router A on Router B.
•
Configure Router B to use the asymmetric key algorithm of RSA to authenticate Router A.
•
Import the host public key of Router A from the public key file to Router B.
Figure 77 Network diagram
Configuration procedure
1.
Create key pairs on Router A and export the host public key:
# Create a local RSA key pair with the default name and the default modulus length of 1024 bits.
<RouterA> system-view
[RouterA] public-key local create rsa
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
198
Press CTRL+C to abort.
Input the bits of the modulus[default = 1024]:
Generating Keys...
++++++
++++++
++++++++
++++++++
# Display the public keys of the local RSA key pairs.
[RouterA] display public-key local rsa public
=====================================================
Time of Key pair created: 09:50:06
2007/08/07
Key name: HOST_KEY
Key type: RSA Encryption Key
=====================================================
Key code:
30819F300D06092A864886F70D010101050003818D0030818902818100D90003FA95F5A44A2A2CD3F
814F
9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E766BD
995C
669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA326470034DC07
8B2B
AA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A10203010001
=====================================================
Time of Key pair created: 09:50:07
2007/08/07
Key name: SERVER_KEY
Key type: RSA Encryption Key
=====================================================
Key code:
307C300D06092A864886F70D0101010500036B003068026100999089E7AEE9802002D9EB2D0433B87
BB61
58E35000AFB3FF310E42F109829D65BF70F7712507BE1A3E0BC5C2C03FAAF00DFDDC63D004B4490DA
CBA3
CFA9E84B9151BDC7EECE1C8770D961557D192DE2B36CAF9974B7B293363BB372771C2C1F020301000
1
# Export the RSA host public key HOST_KEY to a file named routera.pub.
[RouterA] public-key local export public rsa ssh2 routera.pub
2.
Enable the FTP server function on Router A:
# Enable the FTP server function, and create an FTP user with the username ftp, password 123,
and user level 3. This user level makes sure the user has the permission to perform FTP
operations.
[RouterA] ftp server enable
[RouterA] local-user ftp
[RouterA-luser-ftp] password simple 123
[RouterA-luser-ftp] service-type ftp
[RouterA-luser-ftp] authorization-attribute level 3
[RouterA-luser-ftp] quit
3.
From Router B, use FTP to log in to Router A, and get the public key file routera.pub with the
file transfer mode of binary.
199
<RouterB> ftp 10.1.1.1
Trying 10.1.1.1 ...
Press CTRL+K to abort
Connected to 10.1.1.1.
220 FTP service ready.
User(10.1.1.1:(none)):ftp
331 Password required for ftp.
Password:
230 User logged in.
[ftp] binary
200 Type set to I.
[ftp] get routera.pub
227 Entering Passive Mode (10,1,1,1,5,148).
125 BINARY mode data connection already open, transfer starting for /routera.pub.
226 Transfer complete.
FTP: 299 byte(s) received in 0.189 second(s), 1.00Kbyte(s)/sec.
[ftp] quit
221 Server closing.
4.
Import the host public key of Router A to Router B:
# Import the host public key of Router A from the key file routera.pub to Router B.
<RouterB> system-view
[RouterB] public-key peer routera import sshkey routera.pub
# Display the host public key of Router A on Router B.
[RouterB] display public-key peer name routera
=====================================
Key Name
: routera
Key Type
: RSA
Key Module: 1024
=====================================
Key Code:
30819F300D06092A864886F70D010101050003818D0030818902818100D90003FA95F5A44A2A2CD3F
814F
9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E766BD
995C
669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA326470034DC07
8B2B
AA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A10203010001
The output shows that the host public key of Router A saved on Router B is consistent with the
one created on Router A.
Exporting and importing an RSA key pair
Network requirements
Create and export an RSA key pair on Router A, and then import the key pair to Router B.
200
Figure 78 Network diagram
Configuration procedure
1.
Configure Router A:
# Create a local RSA key pair named rsa1 with the default modulus length of 1024 bits.
<RouterA> system-view
[RouterA] public-key local create rsa name rsa1
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Press CTRL+C to abort.
Input the bits of the modulus[default = 1024]:
Generating Keys...
++++++++++++++++
+++++++
+++++++++
+++
# Export the RSA key pair rsa1 by using the encryption algorithm 3DES CBC and password
12345678.
[RouterA] public-key local export rsa name rsa1 pem 3des-cbc-128 12345678
-----BEGIN PUBLIC KEY----MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC6Ne4EtnoKqBCL2YZvSjrG+8He
sae5FWtyj9D25PEkXagpLqb3i9Gm/Qbb6cqLLPUIgDS8eK7Wt/dXLeFUCDc0lY8V
gujJPvarFL4+Jn+VuL9znNbboA9IxPH2fMvew8lkPCwkXoP+52J+1LRpYkh+rIpE
Kj7FG/3/wzGsXu8WJQIDAQAB
-----END PUBLIC KEY---------BEGIN RSA PRIVATE KEY----Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,7F8FAB15399DF87C
MGaftNqe4esjetm7bRJHSpsbwZ9YUpvA9iWh8R406NGq8e+1A/ZiK23+t1XqRwaU
1FXnwbqHgW1pZ7JxQdgBuC9uXc4VQyP/xe6xCyUepdMC71fmeOaiwUFrj6LAzzBg
o3SfhX1NHyHBnr7c6SnIeUTG2g/qRdj40TD4HcRjgPaLaTGguZ553GyS6ODWAwL7
ZBTjv+vow9kfewZ74ocoBje2gLcWlbmiEKCJGV06zW4gv2AH6I8TAhv4GovIN/v1
lCsD2PscXnPOloLTE/8EDLRHNE8RpIYDWqI/YI8Yg6wlx29mf29+cj/9r4gPrDPy
c/TQ0a0g95Khdy+yl4eDKaFiQQ+Kqn4zdzDTDNq7LRtqr7lGQzVw6srfrr71ib7J
yJFdi2RXETEgOS/jE+xGtNqd38F/YzIRPax7NNMK+hAJC2MzdbN/BEoLWOqG7Plm
hvCE3LFxelExLJU+0XfAX77TI2+5LEHBi1UiGLeH08fd1XUQCefARlIxGoRJdtTu
gHP4+NF4PC9B1/GZoAYUp+171p1QwPk0vyU3TXijueqVUpQBUHGxSE0UW+SS1iwL
8vsSLHIwK4aZ77Z1o+Uw1QBoqw9jpubG4gUkX8RII8E8b13I6/QTH78E4/FgAmIQ
HTYnE2RDHXkhPGR5FGJsZnd21XLvd2BEkGGmhTk80nDeiI2XH3D48E6UahQwcam/
q/txd/KsLnp0rpJkc/WhOTprioeLQQEBayixKRWzNLsZt3L6lqYbA01Z1THho+EV
0Ng0EZKQyiRV1j7gsBYFRinbSAsIpeYlr7gDAnBCRJdSfPNBKG+ewg==
-----END RSA PRIVATE KEY-----
201
Copy the private key (started from -----BEGIN RSA PRIVATE KEY----- ) to a file for later import.
2.
Configure Router B:
# Import the RSA key pair in PEM format, and name the imported RSA key pair as rsa1 on
Router B.
When you see End with a Ctrl+C on a line by itself, copy the private key of the RSA key pair
to Router B, press Ctrl+C, and then enter the password used to encrypt the RSA key pair when
the key pair was exported.
[RouterB] public-key local import rsa name rsa1 pem
Enter PEM-formatted certificate.
End with a Ctrl+C on a line by itself.
-----BEGIN RSA PRIVATE KEY----Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,7F8FAB15399DF87C
MGaftNqe4esjetm7bRJHSpsbwZ9YUpvA9iWh8R406NGq8e+1A/ZiK23+t1XqRwaU
1FXnwbqHgW1pZ7JxQdgBuC9uXc4VQyP/xe6xCyUepdMC71fmeOaiwUFrj6LAzzBg
o3SfhX1NHyHBnr7c6SnIeUTG2g/qRdj40TD4HcRjgPaLaTGguZ553GyS6ODWAwL7
ZBTjv+vow9kfewZ74ocoBje2gLcWlbmiEKCJGV06zW4gv2AH6I8TAhv4GovIN/v1
lCsD2PscXnPOloLTE/8EDLRHNE8RpIYDWqI/YI8Yg6wlx29mf29+cj/9r4gPrDPy
c/TQ0a0g95Khdy+yl4eDKaFiQQ+Kqn4zdzDTDNq7LRtqr7lGQzVw6srfrr71ib7J
yJFdi2RXETEgOS/jE+xGtNqd38F/YzIRPax7NNMK+hAJC2MzdbN/BEoLWOqG7Plm
hvCE3LFxelExLJU+0XfAX77TI2+5LEHBi1UiGLeH08fd1XUQCefARlIxGoRJdtTu
gHP4+NF4PC9B1/GZoAYUp+171p1QwPk0vyU3TXijueqVUpQBUHGxSE0UW+SS1iwL
8vsSLHIwK4aZ77Z1o+Uw1QBoqw9jpubG4gUkX8RII8E8b13I6/QTH78E4/FgAmIQ
HTYnE2RDHXkhPGR5FGJsZnd21XLvd2BEkGGmhTk80nDeiI2XH3D48E6UahQwcam/
q/txd/KsLnp0rpJkc/WhOTprioeLQQEBayixKRWzNLsZt3L6lqYbA01Z1THho+EV
0Ng0EZKQyiRV1j7gsBYFRinbSAsIpeYlr7gDAnBCRJdSfPNBKG+ewg==
-----END RSA PRIVATE KEY----^C
Please input the password:
Verifying the configuration
Verify that the public key of RSA key pair rsa1 on Router B is the same as the public key of RSA
key pair rsa1 on Router A.
# Display the public key information of local RSA key pairs on Router B.
<RouterB> display public-key local rsa public
Time of Key pair created: 14:42:29
2013/03/21
Key name: rsa1
Key type: RSA
=====================================================
Key code:30819F300D06092A864886F70D010101050003818D0030818902818100CD7891BEB84FE
E1F6ECF45C4D533B03BAFD73A983D3DEA9FE362C153D6E2BEB80DD234E749A42A5541F23B6C45AEC
04C7F80D81F40B18105A88DFDE1802279062906F8DC65872A1F763F7BF471548D709118494C5F622
0E58D5F2722A7A183999075EB494828DB7843855A81A0E701C1CDC15BBEF136329308DC179CD9D38
BB30203010001
<RouterB>
# Display the public key information of local RSA key pairs on Router A.
<RouterA> display public-key local rsa public
202
Time of Key pair created: 14:42:29
2013/03/21
Key name: rsa1
Key type: RSA
=====================================================
Key code:30819F300D06092A864886F70D010101050003818D0030818902818100CD7891BEB84FE
E1F6ECF45C4D533B03BAFD73A983D3DEA9FE362C153D6E2BEB80DD234E749A42A5541F23B6C45AEC
04C7F80D81F40B18105A88DFDE1802279062906F8DC65872A1F763F7BF471548D709118494C5F622
0E58D5F2722A7A183999075EB494828DB7843855A81A0E701C1CDC15BBEF136329308DC179CD9D38
BB30203010001
203
Configuring PKI
Overview
The PKI uses a general security infrastructure to provide information security through public key
technologies.
PKI, also called asymmetric key infrastructure, uses a key pair to encrypt and decrypt the data. The
key pair consists of a private key and a public key. The private key must be kept secret but the public
key needs to be distributed. Data encrypted by one of the two keys can only be decrypted by the
other.
A key problem with PKI is how to manage the public keys. PKI employs the digital certificate
mechanism to solve this problem. The digital certificate mechanism binds public keys to their owners,
helping distribute public keys in large networks securely.
With digital certificates, the PKI system provides network communication and e-commerce with
security services such as user authentication, data non-repudiation, data confidentiality, and data
integrity.
PKI system provides certificate management for IPsec.
PKI terms
Digital certificate
A digital certificate is a file signed by a certificate authority (CA) for an entity. It includes mainly the
identity information of the entity, the public key of the entity, the name and signature of the CA, and
the validity period of the certificate, where the signature of the CA ensures the validity and authority
of the certificate. A digital certificate must comply with the international standard of ITU-T X.509. The
most common standard is X.509 v3.
This document involves local certificate and CA certificate. A local certificate is a digital certificate
signed by a CA for an entity, and a CA certificate is the certificate of a CA. If multiple CAs are trusted
by different users in a PKI system, the CAs will form a CA tree with the root CA at the top level. The
root CA has a CA certificate signed by itself and each lower level CA has a CA certificate signed by
the CA at the next higher level.
CRL
An existing certificate might need to be revoked when, for example, the username changes, the
private key leaks, or the user stops the business. Revoking a certificate will remove the binding of the
public key with the user identity information. In PKI, the revocation is made through certificate
revocation lists (CRLs). Whenever a certificate is revoked, the CA publishes one or more CRLs to
show all certificates that have been revoked. The CRLs contain the serial numbers of all revoked
certificates and provide an effective way for checking the validity of certificates.
A CA might publish multiple CRLs when the number of revoked certificates is so large that publishing
them in a single CRL might degrade network performance, and it uses CRL distribution points to
indicate the URLs of these CRLs.
CA policy
A CA policy is a set of criteria that a CA follows in processing certificate requests, issuing and
revoking certificates, and publishing CRLs. Usually, a CA advertises its policy in the form of
certification practice statement (CPS). A CA policy can be acquired through out-of-band means such
as phone, disk, and email. Because different CAs might use different methods to examine the
binding of a public key with an entity, make sure you understand the CA policy before selecting a
trusted CA for certificate request.
204
PKI architecture
A PKI system consists of entities, a CA, a registration authority (RA) and a PKI repository, as shown
in Figure 79.
Figure 79 PKI architecture
Entity
An entity is an end user of PKI products or services, such as a person, an organization, a device like
a router or a switch, or a process running on a computer.
CA
A CA is a trusted authority responsible for issuing and managing digital certificates. A CA issues
certificates, specifies the validity periods of certificates, and revokes certificates as needed by
publishing CRLs.
RA
A registration authority (RA) is an extended part of a CA or an independent authority. An RA can
implement functions including identity authentication, CRL management, key pair generation and
key pair backup. The PKI standard recommends that an independent RA be used for registration
management to achieve higher security of application systems.
PKI repository
A PKI repository can be a Lightweight Directory Access Protocol (LDAP) server or a common
database. It stores and manages information like certificate requests, certificates, keys, CRLs and
logs when it provides a simple query function.
LDAP is a protocol for accessing and managing PKI information. An LDAP server stores user
information and digital certificates from the RA server and provides directory navigation service.
From an LDAP server, an entity can obtain local and CA certificates of its own as well as certificates
of other entities.
PKI operation
In a PKI-enabled network, an entity can request a local certificate from the CA and the device can
check the validity of certificates. Here is how it works:
1.
An entity submits a certificate request to the RA.
2.
The RA reviews the identity of the entity and then sends the identity information and the public
key with a digital signature to the CA.
3.
The CA verifies the digital signature, approves the application, and issues a certificate.
205
4.
The RA receives the certificate from the CA, sends it to the LDAP server or other distribution
points to provide directory navigation service, and notifies the entity that the certificate is
successfully issued.
5.
The entity obtains the certificate. With the certificate, the entity can communicate with other
entities safely through encryption and digital signature.
6.
The entity makes a request to the CA when it needs to revoke its certificate. The CA approves
the request, updates the CRLs and publishes the CRLs on the LDAP server or other distribution
points.
PKI applications
The PKI technology can satisfy the security requirements of online transactions. As an infrastructure,
PKI has a wide range of applications. The following lists some common application examples:
•
VPN—A VPN is a private data communication network built on the public communication
infrastructure. A VPN can leverage network layer security protocols (for instance, IPsec) in
conjunction with PKI-based encryption and digital signature technologies for confidentiality.
•
Secure email—Emails require confidentiality, integrity, authentication, and non-repudiation.
PKI can address these needs. The secure email protocol that is developing rapidly is S/MIME,
which is based on PKI and allows for transfer of encrypted mails with signature.
FIPS compliance
The device supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for
features, commands, and parameters might differ in FIPS mode (see "Configuring FIPS") and
non-FIPS mode.
PKI configuration task list
Task
Remarks
Configuring a PKI entity
Required.
Configuring a PKI domain
Required.
Configuring automatic
certificate request
Requesting a certificate
Manually requesting a
certificate
Required.
Use either method.
Obtaining certificates
Optional.
Verifying PKI certificates
Optional.
Destroying the local RSA key pair
Optional.
Removing a certificate
Optional.
Configuring an access control policy
Optional.
Configuring a PKI entity
A certificate is the binding of a public key and the identity information of an entity, where the identity
information is identified by an entity distinguished name (DN). A CA identifies a certificate applicant
uniquely by entity DN.
206
An entity DN is defined by these parameters:
•
Common name of the entity.
•
Country code of the entity, a standard 2-character code. For example, US represents the United
States.
•
FQDN of the entity, a unique identifier of an entity on the network. It consists of a host name and
a domain name and can be resolved to an IP address. For example, www.whatever.com is an
FQDN, where www is a host name and whatever.com a domain name.
•
IP address of the entity.
•
Locality where the entity resides.
•
Organization to which the entity belongs.
•
Unit of the entity in the organization.
•
State where the entity resides.
The configuration of an entity DN must comply with the CA certificate issue policy. You need to
determine, for example, which entity DN parameters are mandatory and which are optional.
Otherwise, certificate requests might be rejected.
To configure a PKI entity:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an entity and enter its
view.
pki entity entity-name
3.
Configure the common
name for the entity.
common-name name
4.
Configure the country code
for the entity.
country country-code-str
5.
Configure the FQDN for the
entity.
fqdn name-str
6.
Configure the IP address for
the entity.
ip ip-address
7.
Configure the locality for the
entity.
locality locality-name
8.
Configure the organization
name for the entity.
organization org-name
9.
Configure the unit name for
the entity.
organization-unit org-unit-name
10. Configure the state or
province for the entity.
No entity exists by default.
You can create up to two entities
on a device.
Optional.
No common name is specified by
default.
Optional.
No country code is specified by
default.
Optional.
No FQDN is specified by default.
Optional.
No IP address is specified by
default.
Optional.
No locality is specified by default.
Optional.
No organization is specified by
default.
Optional.
No unit is specified by default.
Optional.
state state-name
207
No state or province is specified
by default.
Step
11. Configure the PKI entity to
include the device serial
number in the identity
information.
Command
Remarks
Optional.
include serial-number
By default, the PKI entity does not
contain the device serial number
in the identity information.
NOTE:
The Windows 2000 CA server has some restrictions on the data length of a certificate request. If the
entity DN in a certificate request goes beyond a certain limit, the server will not respond to the
certificate request.
Configuring a PKI domain
Before requesting a PKI certificate, an entity needs to be configured with some enrollment
information, which is referred to as a PKI domain. A PKI domain is intended only for convenience of
reference by other applications like IKE, and has only local significance. The PKI domain configured
on a device is invisible to the CA and other devices, and each PKI domain has its own parameters.
A PKI domain is defined by these parameters:
•
Trusted CA—An entity requests a certificate from a trusted CA.
•
Entity—A certificate applicant uses an entity to provide its identity information to a CA.
•
RA—Generally, an independent RA is in charge of certificate request management. It receives
the registration request from an entity, examines its qualification, and determines whether to
ask the CA to sign a digital certificate. The RA only examines the application qualification of an
entity. It does not issue any certificate. Sometimes, the registration management function is
provided by the CA, in which case no independent RA is required. Hewlett Packard Enterprise
recommends that you to deploy an independent RA.
•
URL of the registration server—An entity sends a certificate request to the registration server
through SCEP, a dedicated protocol for an entity to communicate with a CA.
•
Polling interval and count—After an applicant makes a certificate request, the CA might need
a long period of time if it verifies the certificate request manually. During this period, the
applicant needs to query the status of the request periodically to get the certificate as soon as
possible after the certificate is signed. You can configure the polling interval and count to query
the request status.
•
IP address of the LDAP server—An LDAP server is usually deployed to store certificates and
CRLs. If this is the case, you need to configure the IP address of the LDAP server.
•
Fingerprint for root certificate verification—After receiving the root certificate of the CA, an
entity needs to verify the fingerprint of the root certificate, namely, the hash value of the root
certificate content. This hash value is unique to every certificate. If the fingerprint of the root
certificate does not match the one configured for the PKI domain, the entity will reject the root
certificate.
To configure a PKI domain:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a PKI domain and
enter its view.
pki domain domain-name
No PKI domain exists by default.
208
You can configure up to 32 PKI
domains on a device.
Step
Command
Remarks
No trusted CA is specified by
default.
3.
Specify the trusted CA.
ca identifier name
The CA name is required only
when you obtain a CA certificate.
It is not used for local certificate
request.
4.
Specify the entity for
certificate request.
certificate request entity
entity-name
No entity is specified by default.
5.
Specify the authority for
certificate request.
certificate request from { ca |
ra }
No authority is specified by
default.
6.
Configure the URL of the
server for certificate request.
certificate request url url-string
7.
Configure the polling interval
and attempt limit for querying
the certificate request status.
certificate request polling
{ count count | interval minutes }
The polling is executed for up to
50 times at the interval of 20
minutes by default.
Specify the LDAP server.
ldap-server ip ip-address [ port
port-number ] [ version
version-number ]
Optional.
8.
9.
Configure the fingerprint for
root certificate verification.
The specified entity must exist.
No URL is configured by default.
The URL does not support
domain name resolution.
Optional.
root-certificate fingerprint
{ md5 | sha1 } string
No LDP server is specified by
default.
Required when the certificate
request mode is auto and optional
when the certificate request mode
is manual. In the latter case, if you
do not configure this command,
the fingerprint of the root
certificate must be verified
manually.
No fingerprint is configured by
default.
Requesting a certificate
When requesting a certificate, an entity introduces itself to the CA by providing its identity information
and public key, which will be the major components of the certificate. A certificate request can be
submitted to a CA in offline mode or online mode. In offline mode, a certificate request is submitted to
a CA by an "out-of-band" means such as phone, disk, or email.
Online certificate request can be initiated in manual mode or auto mode
Configuring automatic certificate request
In auto mode, an entity automatically requests a certificate from the CA server if it has no local
certificate for an application working with PKI. For example, when PKI certificate authentication is
used, if no local certificate is available during IKE negotiation, the entity automatically requests one,
and saves the local certificate after retrieving it from the CA. If the PKI domain has no CA certificate
before the entity submits the certificate request, the entity automatically obtains the CA certificate
first.
If an automatically requested certificate will expire or has expired, the entity does not initiate a
re-request to the CA automatically, and the services using the certificate might be interrupted.
209
To configure automatic certificate request:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter PKI domain view.
pki domain domain-name
N/A
3.
Set the certificate request
mode to auto.
certificate request mode auto
[ key-length key-length |
password { cipher | simple }
password ] *
Manual by default.
Manually requesting a certificate
In manual mode, you must submit a local certificate request for an entity. Before the request, you
must obtain a CA certificate and generate a key pair for the PKI domain.
The CA certificate in the PKI domain is used to verify the authenticity and validity of a local certificate.
Generating a key pair is an important step in certificate request. The key pair includes a public key
and a private key. The private key is kept by the user. The public key is transferred to the CA along
with some other information. For more information about RSA key pair configuration, see "Managing
public keys."
Configuration guidelines
•
If a PKI domain already has a local certificate, creating an RSA key pair might result in
inconsistency between the key pair and the certificate. To generate a new RSA key pair, delete
the local certificate and then execute the public-key local create command. For more
information about the public-key local create command, see Security Command Reference.
•
A newly created key pair will overwrite the existing one. If you perform the public-key local
create command in the presence of a local RSA key pair, the system will ask you whether you
want to overwrite the existing one.
•
If a PKI domain already has a local certificate, you cannot request another certificate for it. This
helps avoid inconsistency between the certificate and the registration information resulting from
configuration changes. Before requesting a new certificate, use the pki delete-certificate
command to delete the existing local certificate and the CA certificate stored locally.
•
When it is impossible to request a certificate from the CA through SCEP, you can print the
request information or save the request information to a local file, and then send the printed
information or saved file to the CA by an out-of-band means. To print the request information,
use the pki request-certificate domain command with the pkcs10 keyword. To save the
request information to a local file, use the pki request-certificate domain command with the
pkcs10 filename filename option.
•
Make sure the clocks of the entity and the CA are synchronous. Otherwise, the validity period of
the certificate will be abnormal.
•
In FIPS mode, MD5 certificates cannot be imported.
Configuration procedure
To manually requesting a certificate:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter PKI domain view.
pki domain domain-name
N/A
3.
Set the certificate request
mode to manual.
certificate request mode
manual
Optional.
210
Manual by default.
Step
Command
Remarks
4.
Return to system view.
quit
N/A
5.
Obtain a CA certificate
manually.
See "Obtaining certificates"
N/A
6.
Generate a local RSA key
pair.
public-key local create rsa
Submit a local certificate
request manually.
pki request-certificate domain
domain-name [ password ]
[ pkcs10 [ filename filename ] ]
7.
No local RSA key pair exists by
default.
In FIPS mode, the RSA key pair
length is fixed to 2048 bits.
N/A
This command is not saved in the
configuration file.
Obtaining certificates
You can download CA certificates or local certificates from the CA server and save them locally. To
do so, use either the offline mode or the online mode. In offline mode, you must obtain a certificate by
an out-of-band means like FTP, disk, or email, and then import it into the local PKI system.
Certificate retrieval serves the following purposes:
•
Locally store the certificates associated with the local security domain for improved query
efficiency and reduced query count.
•
Prepare for certificate verification.
Before retrieving a local certificate in online mode, be sure to complete LDAP server configuration.
If a PKI domain already has a CA certificate, you cannot obtain another CA certificate for it. This
restriction helps avoid inconsistency between the certificate and registration information resulted
from configuration changes. To obtain a new CA certificate, use the pki delete-certificate command
to delete the existing CA certificate and the local certificate first.
Be sure that the device system time falls in the validity period of the certificate so that the certificate
is valid.
To obtain a certificate manually:
Step
Command
Remarks
1.
system-view
N/A
Enter system view.
•
2.
Obtain a certificate
manually
•
In online mode:
pki retrieval-certificate { ca | local }
domain domain-name
In offline mode:
pki import-certificate { ca | local }
domain domain-name { der | p12 | pem }
[ filename filename ]
Use either command.
The pki
retrieval-certificate
configuration is not
saved in the
configuration file.
Verifying PKI certificates
A certificate needs to be verified before being used. Verifying a certificate will check that the
certificate is signed by the CA and that the certificate has neither expired nor been revoked.
You can specify whether CRL checking is required in certificate verification. If you enable CRL
checking, CRLs will be used in verification of a certificate. In this case, be sure to obtain the CA
211
certificate and CRLs to the local device before the certificate verification. If you disable CRL checking,
you only need to obtain the CA certificate.
The CRL update period defines the interval at which the entity downloads CRLs from the CRL server.
The CRL update period setting manually configured on the device is prior to that carried in the CRLs.
Verifying PKI certificates with CRL checking
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter PKI domain view.
pki domain domain-name
N/A
3.
Specify the URL of the CRL
distribution point.
Optional.
crl url url-string
No CRL distribution point URL is
specified by default.
Optional.
By default, the CRL update period
depends on the next update field
in the CRL file.
4.
Set the CRL update period.
crl update-period hours
5.
Enable CRL checking.
crl check enable
6.
Return to system view.
quit
N/A
7.
Obtain the CA certificate.
See "Obtaining certificates"
N/A
8.
Obtain the CRLs.
pki retrieval-crl domain
domain-name
9.
Verify the validity of a
certificate.
pki validate-certificate { ca |
local } domain domain-name
Optional.
Enabled by default.
N/A
This command is not saved in the
configuration file.
N/A
Verifying PKI certificates without CRL checking
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter PKI domain view.
pki domain domain-name
N/A
3.
Disable CRL checking.
crl check disable
Enabled by default.
4.
Return to system view.
quit
N/A
5.
Obtain the CA certificate.
See "Obtaining certificates"
N/A
6.
Verify the validity of the
certificate.
pki validate-certificate { ca |
local } domain domain-name
N/A
Destroying the local RSA key pair
A certificate has a lifetime, which is determined by the CA. When the private key leaks or the
certificate is about to expire, you can destroy the old RSA key pair and then create a pair to request
a new certificate.
212
To destroy the local RSA key pair:
Step
Command
1.
Enter system view.
system-view
2.
Destroy a local RSA key pair.
public-key local destroy rsa
Removing a certificate
When a certificate requested manually is about to expire or you want to request a new certificate, you
can delete the current local certificate or CA certificate.
To remove a certificate:
Step
Command
1.
Enter system view.
system-view
2.
Delete certificates.
pki delete-certificate { ca | local } domain domain-name
Configuring an access control policy
By configuring a certificate attribute-based access control policy, you can further control access to
the server, providing additional security for the server.
To configure a certificate attribute-based access control policy:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a certificate attribute
group and enter its view.
pki certificate attribute-group
group-name
No certificate attribute group
exists by default.
3.
Configure an attribute rule
for the certificate issuer
name, certificate subject
name, or alternative subject
name.
attribute id { alt-subject-name
{ fqdn | ip } | { issuer-name |
subject-name } { dn | fqdn | ip } }
{ ctn | equ | nctn | nequ }
attribute-value
Optional.
4.
Return to system view.
quit
N/A
5.
Create a certificate
attribute-based access
control policy and enter its
view.
pki certificate
access-control-policy
policy-name
No access control policy exists by
default.
Configure a certificate
attribute-based access
control rule.
rule [ id ] { deny | permit }
group-name
6.
Displaying and maintaining PKI
213
No restriction exists on the issuer
name, certificate subject name
and alternative subject name by
default.
No access control rule exists by
default.
A certificate attribute group must
exist to be associated with a rule.
Task
Command
Remarks
Display the contents or request
status of a certificate.
display pki certificate { { ca |
local } domain domain-name |
request-status } [ | { begin |
exclude | include }
regular-expression ]
Available in any view.
Display CRLs.
display pki crl domain
domain-name [ | { begin |
exclude | include }
regular-expression ]
Available in any view.
Display information about one or
all certificate attribute groups.
display pki certificate
attribute-group { group-name |
all } [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display information about one or
all certificate attribute-based
access control policies.
display pki certificate
access-control-policy
{ policy-name | all } [ | { begin |
exclude | include }
regular-expression ]
Available in any view.
PKI configuration examples
The SCEP add-on is required when you use the Windows Server as the CA. In this case, when you
configure the PKI domain, you must use the certificate request from ra command to specify that
the entity requests a certificate from an RA.
The SCEP add-on is not required when RSA Keon is used. In this case, when configuring a PKI
domain, you need to use the certificate request from ca command to specify that the entity
requests a certificate from a CA.
Certificate request from an RSA Keon CA server
Network requirements
The device submits a local certificate request to the CA server. The device acquires the CRLs for
certificate verification.
Figure 80 Network diagram
Configuring the CA server
1.
Create a CA server named myca:
In this example, you need to configure these basic attributes on the CA server at first:
{
Nickname—Name of the trusted CA.
{
Subject DN—DN information of the CA, including the Common Name (CN), Organization
Unit (OU), Organization (O), and Country (C).
The other attributes might be left using the default values.
2.
Configure extended attributes:
214
After configuring the basic attributes, you need to perform configuration on the jurisdiction
configuration page of the CA server. This includes selecting the proper extension profiles,
enabling the SCEP autovetting function, and adding the IP address list for SCEP autovetting.
3.
Configure the CRL distribution behavior:
After completing the configuration, you need to perform CRL related configurations. In this
example, select the local CRL distribution mode of HTTP and set the HTTP URL to
http://4.4.4.133:447/myca.crl.
After the configuration, make sure the system clock of the device is synchronous to that of the
CA, so that the device can request certificates and obtain CRLs properly.
Configuring the router
1.
Configure the entity DN:
# Configure the entity name as aaa and the common name as router.
<Router> system-view
[Router] pki entity aaa
[Router-pki-entity-aaa] common-name router
[Router-pki-entity-aaa] quit
2.
Configure the PKI domain:
# Create PKI domain torsa and enter its view.
[Router] pki domain torsa
# Configure the name of the trusted CA as myca.
[Router-pki-domain-torsa] ca identifier myca
# Configure the URL of the registration server in the format of http://host:port/Issuing
Jurisdiction ID, where Issuing Jurisdiction ID is a hexadecimal string generated on the CA
server.
[Router-pki-domain-torsa] certificate request url
http://4.4.4.133:446/c95e970f632d27be5e8cbf80e971d9c4a9a93337
# Set the registration authority to CA.
[Router-pki-domain-torsa] certificate request from ca
# Specify the entity for certificate request as aaa.
[Router-pki-domain-torsa] certificate request entity aaa
# Configure the URL for the CRL distribution point.
[Router-pki-domain-torsa] crl url http://4.4.4.133:447/myca.crl
[Router-pki-domain-torsa] quit
3.
Generate a local key pair using RSA:
[Router] public-key local create rsa
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Press CTRL+C to abort.
Input the bits in the modulus [default = 1024]:
Generating Keys...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++
4.
Apply for certificates:
# Obtain the CA certificate and save it locally.
215
[Router] pki retrieval-certificate ca domain torsa
Retrieving CA/RA certificates. Please wait a while......
The trusted CA's finger print is:
MD5
fingerprint:EDE9 0394 A273 B61A F1B3 0072 A0B1 F9AB
SHA1 fingerprint: 77F9 A077 2FB8 088C 550B A33C 2410 D354 23B2 73A8
Is the finger print correct?(Y/N):y
Saving CA/RA certificates chain, please wait a moment......
CA certificates retrieval success.
# Obtain CRLs and save them locally.
[Router] pki retrieval-crl domain torsa
Connecting to server for retrieving CRL. Please wait a while.....
CRL retrieval success!
# Request a local certificate manually.
[Router] pki request-certificate domain torsa challenge-word
Certificate is being requested, please wait......
[Router]
Enrolling the local certificate,please wait a while......
Certificate request Successfully!
Saving the local certificate to device......
Done!
Verifying the configuration
# Use the following command to display information about the obtained local certificate.
[Router] display pki certificate local domain torsa
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
9A96A48F 9A509FD7 05FFF4DF 104AD094
Issuer:
C=cn
O=org
OU=test
CN=myca
Validity
Not Before: Jan
8 09:26:53 2007 GMT
Not After : Jan
8 09:26:53 2008 GMT
Subject:
CN=router
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00D67D50 41046F6A 43610335 CA6C4B11
F8F89138 E4E905BD 43953BA2 623A54C0
EA3CB6E0 B04649CE C9CDDD38 34015970
981E96D9 FF4F7B73 A5155649 E583AC61
216
D3A5C849 CBDE350D 2A1926B7 0AE5EF5E
D1D8B08A DBF16205 7C2A4011 05F11094
73EB0549 A65D9E74 0F2953F2 D4F0042F
19103439 3D4F9359 88FB59F3 8D4B2F6C
2B
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 CRL Distribution Points:
URI:http://4.4.4.133:447/myca.crl
You can also use some other display commands (display pki certificate ca domain and display
pki crl domain commands) to display detailed information about the CA certificate and CRLs.
Certificate request from a Windows 2003 CA server
Network requirements
Configure PKI entity Router to request a local certificate from the CA server.
Figure 81 Network diagram
Configuring the CA server
1.
Install the certificate service suites:
a. Select Control Panel > Add or Remove Programs from the start menu.
b. Select Add/Remove Windows Components > Certificate Services.
c. Click Next to begin the installation.
2.
Install the SCEP add-on:
As a CA server running the Windows 2003 server does not support SCEP by default, you need
to install the SCEP add-on so that the router can register and obtain its certificate automatically.
After the SCEP add-on installation completes, a URL is displayed, which you need to configure
on the router as the URL of the server for certificate registration.
3.
Modify the certificate service attributes:
a. Select Control Panel > Administrative Tools > Certificate Authority from the start menu.
If the CA server and SCEP add-on have been installed successfully, there should be two
certificates issued by the CA to the RA.
b. Right-click the CA server in the navigation tree and select Properties > Policy Module.
c. Click Properties and select Follow the settings in the certificate template, if applicable.
Otherwise, automatically issue the certificate.
4.
Modify the Internet Information Services (IIS) attributes:
a. Select Control Panel > Administrative Tools > Internet Information Services (IIS)
Manager from the start menu.
b. Select Web Sites from the navigation tree.
c. Right-click Default Web Site and select Properties > Home Directory.
d. Specify the path for certificate service in the Local path text box.
217
To avoid conflict with existing services, specify an available port number as the TCP port
number of the default website.
After completing the configuration, check that the system clock of the router is synchronous to
that of the CA server, so that the router can request a certificate normally.
Configuring the router
1.
Configure the entity DN:
# Configure the entity name as aaa and the common name as router.
<Router> system-view
[Router] pki entity aaa
[Router-pki-entity-aaa] common-name router
[Router-pki-entity-aaa] quit
2.
Configure the PKI domain:
# Create PKI domain torsa and enter its view.
[Router] pki domain torsa
# Configure the name of the trusted CA as myca.
[Router-pki-domain-torsa] ca identifier myca
# Configure the URL of the registration server in the format of http://host:port/
certsrv/mscep/mscep.dll, where host:port indicates the IP address and port number of the CA
server.
[Router-pki-domain-torsa] certificate request url
http://4.4.4.1:8080/certsrv/mscep/mscep.dll
# Set the registration authority to RA.
[Router-pki-domain-torsa] certificate request from ra
# Specify the entity for certificate request as aaa.
[Router-pki-domain-torsa] certificate request entity aaa
3.
Generate a local key pair using RSA:
[Router] public-key local create rsa
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Press CTRL+C to abort.
Input the bits in the modulus [default = 1024]:
Generating Keys...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++
4.
Apply for certificates:
# Obtain the CA certificate and save it locally.
[Router] pki retrieval-certificate ca domain torsa
Retrieving CA/RA certificates. Please wait a while......
The trusted CA's finger print is:
MD5
fingerprint:766C D2C8 9E46 845B 4DCE 439C 1C1F 83AB
SHA1 fingerprint:97E5 DDED AB39 3141 75FB DB5C E7F8 D7D7 7C9B 97B4
Is the finger print correct?(Y/N):y
218
Saving CA/RA certificates chain, please wait a moment......
CA certificates retrieval success.
# Request a local certificate manually.
[Router] pki request-certificate domain torsa challenge-word
Certificate is being requested, please wait......
[Router]
Enrolling the local certificate,please wait a while......
Certificate request Successfully!
Saving the local certificate to device......
Done!
Verifying the configuration
# Use the following command to display information about the obtained local certificate.
[Router] display pki certificate local domain torsa
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
48FA0FD9 00000000 000C
Issuer:
CN=myca
Validity
Not Before: Nov 21 12:32:16 2007 GMT
Not After : Nov 21 12:42:16 2008 GMT
Subject:
CN=router
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00A6637A 8CDEA1AC B2E04A59 F7F6A9FE
5AEE52AE 14A392E4 E0E5D458 0D341113
0BF91E57 FA8C67AC 6CE8FEBB 5570178B
10242FDD D3947F5E 2DA70BD9 1FAF07E5
1D167CE1 FC20394F 476F5C08 C5067DF9
CB4D05E6 55DC11B6 9F4C014D EA600306
81D403CF 2D93BC5A 8AF3224D 1125E439
78ECEFE1 7FA9AE7B 877B50B8 3280509F
6B
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
B68E4107 91D7C44C 7ABCE3BA 9BF385F8 A448F4E1
X509v3 Authority Key Identifier:
keyid:9D823258 EADFEFA2 4A663E75 F416B6F6 D41EE4FE
X509v3 CRL Distribution Points:
URI:http://l00192b/CertEnroll/CA%20server.crl
URI:file://\\l00192b\CertEnroll\CA server.crl
219
Authority Information Access:
CA Issuers - URI:http://l00192b/CertEnroll/l00192b_CA%20server.crt
CA Issuers - URI:file://\\l00192b\CertEnroll\l00192b_CA server.crt
1.3.6.1.4.1.311.20.2:
.0.I.P.S.E.C.I.n.t.e.r.m.e.d.i.a.t.e.O.f.f.l.i.n.e
You can also use some other display pki certificate ca domain command to display more
information about the CA certificate.
IKE negotiation with RSA digital signature
Network requirements
An IPsec tunnel is set up between Router A and Router B to secure the traffic between Host A on
subnet 10.1.1.0/24 and Host B on subnet 11.1.1.0/24.
Router A and Router B use IKE for IPsec tunnel negotiation and RSA digital signature of a PKI
certificate system for identity authentication. Router A and Router B use the same CA.
Figure 82 Network diagram
Configuration procedure
1.
Configure Router A:
# Configure the entity DN.
<RouterA> system-view
[RouterA] pki entity en
[RouterA-pki-entity-en] ip 2.2.2.1
[RouterA-pki-entity-en] common-name routera
[RouterA-pki-entity-en] quit
220
# Configure the PKI domain. The URL of the registration server varies with the CA server.
[RouterA] pki domain 1
[RouterA-pki-domain-1] ca identifier CA1
[RouterA-pki-domain-1] certificate request url
http://1.1.1.100/certsrv/mscep/mscep.dll
[RouterA-pki-domain-1] certificate request entity en
[RouterA-pki-domain-1] ldap-server ip 1.1.1.102
# Set the registration authority to RA.
[RouterA-pki-domain-1] certificate request from ra
# Configure the CRL distribution URL. This is not necessary if CRL checking is disabled.
[RouterA-pki-domain-1] crl url ldap://1.1.1.102
[RouterA-pki-domain-1] quit
# Create a local key pair using RSA.
[RouterA] public-key local create rsa
# Request a certificate.
[RouterA] pki retrieval-certificate ca domain 1
[RouterA] pki retrieval-crl domain 1
[RouterA] pki request-certificate domain 1
# Configure IKE proposal 1, using RSA signature for identity authentication.
[RouterA] ike proposal 1
[RouterA-ike-proposal-1] authentication-method rsa-signature
[RouterA-ike-proposal-1] quit
# Specify the PKI domain for the IKE peer.
[RouterA] ike peer peer
[RouterA-ike-peer-peer] certificate domain 1
2.
Configure Router B:
# Configure the entity DN.
<RouterB> system-view
[RouterB] pki entity en
[RouterB-pki-entity-en] ip 3.3.3.1
[RouterB-pki-entity-en] common-name routerb
[RouterB-pki-entity-en] quit
# Configure the PKI domain. The URL of the registration server varies with the CA server.
[RouterB] pki domain 1
[RouterB-pki-domain-1] ca identifier CA1
[RouterB-pki-domain-1] certificate request url
http://1.1.1.100/certsrv/mscep/mscep.dll
[RouterB-pki-domain-1] certificate request entity en
[RouterB-pki-domain-1] ldap-server ip 1.1.1.102
# Set the registration authority to RA.
[RouterB-pki-domain-1] certificate request from ra
# Configure the CRL distribution URL. This is not necessary if CRL checking is disabled.
[RouterB-pki-domain-1] crl url ldap://1.1.1.102
[RouterB-pki-domain-1] quit
# Create a local key pair using RSA.
[RouterB] public-key local create rsa
# Request a certificate.
221
[RouterB] pki retrieval-certificate ca domain 1
[RouterB] pki retrieval-crl domain 1
[RouterB] pki request-certificate domain 1
# Configure IKE proposal 1, using RSA signature for identity authentication.
[RouterB] ike proposal 1
[RouterB-ike-proposal-1] authentication-method rsa-signature
[RouterB-ike-proposal-1] quit
# Specify the PKI domain for the IKE peer.
[RouterB] ike peer peer
[RouterB-ike-peer-peer] certificate domain 1
NOTE:
The configuration procedure covers only the configurations for IKE negotiation using RSA digital
signature. For an IPsec tunnel to be established, you also need to perform IPsec configurations. For
more information about IPsec configuration, see "Configuring IPsec."
Troubleshooting PKI
Failed to obtain a CA certificate
Symptom
Failed to obtain a CA certificate.
Analysis
Possible reasons include:
•
The network connection is not proper. For example, the network cable might be damaged or
loose.
•
No trusted CA is specified.
•
The URL of the registration server for certificate request is not correct or not configured.
•
No authority is specified for certificate request.
•
The system clock of the device is not synchronized with that of the CA.
Solution
1.
Make sure the network connection is physically proper.
2.
Check that the required commands are configured properly.
3.
Use the ping command to verify that the RA server is reachable.
4.
Specify the authority for certificate request.
5.
Synchronize the system clock of the device with that of the CA.
Failed to request a local certificate
Symptom
Failed to request a local certificate.
Analysis
Possible reasons include:
222
•
The network connection is not proper. For example, the network cable might be damaged or
loose.
•
No CA certificate has been obtained.
•
The current key pair has been bound to a certificate.
•
No trusted CA is specified.
•
The URL of the registration server for certificate request is not correct or not configured.
•
No authority is specified for certificate request.
•
Some required parameters of the entity DN are not configured.
Solution
1.
Make sure the network connection is physically proper.
2.
Obtain a CA certificate.
3.
Regenerate a key pair.
4.
Specify a trusted CA.
5.
Use the ping command to verify that the RA server is reachable.
6.
Specify the authority for certificate request.
7.
Configure the required entity DN parameters.
Failed to obtain CRLs
Symptom
Failed to obtain CRLs.
Analysis
Possible reasons include:
•
The network connection is not proper. For example, the network cable might be damaged or
loose.
•
No CA certificate has been obtained before you try to obtain CRLs.
•
The IP address of LDAP server is not configured.
•
The CRL distribution URL is not configured.
•
The LDAP server version is wrong.
•
The domain name of the CRL distribution point failed to be resolved.
Solution
1.
Make sure the network connection is physically proper.
2.
Obtain a CA certificate.
3.
Specify the IP address of the LDAP server.
4.
Specify the CRL distribution URL.
5.
Re-configure the LDAP version.
6.
Configure the correct DNS server that can resolve the domain name of the CRL distribution
point.
223
Configuring IPsec
Unless otherwise specified, the term "IKE" in this chapter refers to IKE version 1.
Overview
IP Security (IPsec) is a security framework defined by the IETF for securing IP communications. It is
a Layer 3 VPN technology that transmits data in a secure tunnel established between two endpoints.
IPsec provides the following security services in insecure network environments:
•
Confidentiality—The sender encrypts packets before transmitting them over the Internet,
protecting the packets from being eavesdropped en route.
•
Data integrity—The receiver verifies the packets received from the sender to make sure they
are not tampered with during transmission.
•
Data origin authentication—The receiver verifies the authenticity of the sender.
•
Anti-replay—The receiver examines packets and drops outdated and duplicate packets.
IPsec delivers the following benefits:
•
Reduced key negotiation overheads and simplified maintenance by supporting the IKE protocol.
IKE provides automatic key negotiation and automatic IPsec security association (SA) setup
and maintenance.
•
Good compatibility. You can apply IPsec to all IP-based application systems and services
without modifying them.
•
Encryption on a per-packet rather than per-flow basis. Per-packet encryption allows for
flexibility and greatly enhances IP security.
IPsec comprises a set of protocols, including Authentication Header (AH), Encapsulating Security
Payload (ESP), Internet Key Exchange (IKE), and algorithms for authentication and encryption. AH
and ESP provides security services and IKE performs automatic key exchange. For more
information about IKE, see "Configuring IKE."
IPsec can protect both IPv4 and IPv6 packets.
Basic concepts
Security protocols
IPsec comes with two security protocols:
•
AH (protocol 51)—Provides data origin authentication, data integrity, and anti-replay services
by adding an AH header to each IP packet. AH is suitable only for transmitting non-critical data
because it cannot prevent eavesdropping, although it can prevent data tampering. AH supports
authentication algorithms such as MD5 and SHA-1.
•
ESP (protocol 50)—Provides data encryption as well as data origin authentication, data
integrity, and anti-replay services by inserting an ESP header and an ESP trailer in IP packets.
Unlike AH, ESP encrypts data before encapsulating the data to guarantee data confidentiality.
ESP supports encryption algorithms such as DES, 3DES, and AES, and authentication
algorithms such as MD5 and SHA-1. The authentication function is optional to ESP.
Both AH and ESP provide authentication services, but the authentication service provided by AH is
stronger. In practice, you can choose either or both security protocols. When both AH and ESP are
used, an IP packet is encapsulated first by ESP and then by AH. Figure 83 shows the format of IPsec
packets.
224
Security association
A security association is an agreement negotiated between two communicating parties called IPsec
peers. It comprises a set of parameters for data protection, including security protocols,
encapsulation mode, authentication and encryption algorithms, and shared keys and their lifetime.
SAs can be set up manually or through IKE.
An SA is unidirectional. At least two SAs are needed to protect data flows in a bidirectional
communication. If two peers want to use both AH and ESP to protect data flows between them, they
construct an independent SA for each protocol.
An SA is identified by a triplet, which consists of the security parameter index (SPI), destination IP
address, and security protocol identifier (AH or ESP).
An SPI is a 32-bit number for uniquely identifying an SA. It is transmitted in the AH/ESP header. A
manually configured SA requires an SPI to be specified manually for it. An IKE-created SA will have
an SPI generated at random.
A manually configured SA never ages out. An IKE created SA has a specific period of lifetime, which
comes in two types:
•
Time-based lifetime—Defines how long the SA can be valid after it is created.
•
Traffic-based lifetime—Defines the maximum traffic that the SA can process.
The SA becomes invalid when either of the lifetime timers expires. Before the SA expires, IKE
negotiates a new SA, which takes over immediately after its creation.
Encapsulation modes
IPsec supports the following IP packet encapsulation modes:
•
Tunnel mode—IPsec protects the entire IP packet, including both the IP header and the
payload. It uses the entire IP packet to calculate an AH or ESP header, and then encapsulates
the original IP packet and the AH or ESP header with a new IP header. If you use ESP, an ESP
trailer is also encapsulated. Tunnel mode is typically used for protecting gateway-to-gateway
communications.
•
Transport mode—IPsec protects only the IP payload. It uses only the IP payload to calculate
the AH or ESP header, and inserts the calculated header between the original IP header and
payload. If you use ESP, an ESP trailer is also encapsulated. The transport mode is typically
used for protecting host-to-host or host-to-gateway communications.
Figure 83 shows how the security protocols encapsulate an IP packet in different encapsulation
modes.
Figure 83 Encapsulation by security protocols in different modes
Authentication algorithms and encryption algorithms
1.
Authentication algorithms:
IPsec uses hash algorithms to perform authentication. A hash algorithm produces a
fixed-length digest for an arbitrary-length message. IPsec peers respectively calculate
message digests for each packet. If the resulting digests are identical, the packet is considered
intact.
IPsec supports the following hash algorithms for authentication:
225
{
MD5—Takes a message of arbitrary length as input and produces a 128-bit message
digest.
{
SHA-1—Takes a message of a maximum length less than the 64th power of 2 in bits as
input and produces a 160-bit message digest.
Compared with SHA-1, MD5 is faster but less secure.
2.
Encryption algorithms:
IPsec mainly uses symmetric encryption algorithms, which encrypt and decrypt data by using
the same keys. The following encryption algorithms are available for IPsec on the device:
{
DES—Encrypts a 64-bit plain text block with a 56-bit key. DES is the least secure but the
fastest algorithm. It is sufficient for general security requirements.
{
3DES—Encrypts plain text data with three 56-bit DES keys. The key length totals up to 168
bits. It provides moderate security strength and is slower than DES.
{
AES—Encrypts plain text data with a 128-bit, 192-bit, or 256-bit key. AES provides the
highest security strength and is slower than 3DES.
IPsec SA setup modes
IPsec SA setup modes include the following:
•
Manual mode—In this mode, you manually configure and maintain all SA settings. Advanced
features like periodical key update are not available. However, this mode implements IPsec
independently of IKE.
•
ISAKMP mode—In this mode, IKE automatically negotiates and maintains IPsec SAs for
IPsec.
•
GDOI mode—This mode is used to build a group encrypted transport (GET) VPN. The SAs and
keys are managed by the key server in a centralized way, and are issued to the group
members.
If the number of IPsec tunnels in your network is small, use the manual mode. If the number of IPsec
tunnels is large, use the ISAKMP mode.
IPsec tunnel
An IPsec tunnel is a bidirectional channel created between two peers. An IPsec tunnel comprises
one or more pairs of SAs.
IPsec tunnel interface
An IPsec tunnel interface is a Layer 3 logical interface. It supports dynamic routing. All packets
including multicast packets that are routed to an IPsec tunnel interface are IPsec protected.
The IPsec tunnel interface has the following advantages:
•
Simplified configuration—The IPsec tunnel interface is easier to configure compared to using
access control lists (ACLs) to identify protected packets. The IPsec tunnel interface improves
network scalability and reduces maintenance costs.
•
Reduced payload—The IPsec tunnel interface requires less protocol costs and uses less
bandwidth than IPsec over GRE and IPsec over L2TP, which require a GRE header or L2TP
header to be added to each packet.
•
Flexible service application—You can apply a service such as NAT or QoS to packets before
or after they are encrypted by IPsec. To handle packets prior to IPsec encryption, apply the
service to the IPsec tunnel interface. To handle IPsec encrypted packets, apply the service to
the physical outbound interface.
Operation of the IPsec tunnel interface
IPsec encapsulation and de-encapsulation occur on IPsec tunnel interfaces. Figure 84 shows how a
clear text packet arriving at a router is forwarded to the IPsec tunnel interface, encapsulated, and
forwarded out.
226
Figure 84 Encapsulation process of a clear text packet
Router
Clear text
packets
Inbound
interface
(1)
(4)
Forwarding
Inbound
Encrypted
packets
(2)
(3)
Encryption
Outbound
interface
IPsec virtual
tunnel interface
Outbound
IPsec tunnel
1.
The router forwards a clear text packet received on the inbound interface to the forwarding
module.
2.
The forwarding module looks up the routing table and, if the packet must be IPsec protected,
forwards the packet to the IPsec tunnel interface. The original IP packet is encapsulated into to
form a new IP packet. The source and destination of the new packet are respectively the source
and destination address of the tunnel interface.
3.
The IPsec tunnel interface encapsulates the packet, and then sends the packet to the
forwarding module.
4.
The forwarding module looks up the routing table again and forwards the IPsec-encrypted
packet out of the physical outbound interface that is associated with the tunnel interface.
Figure 85 shows how an IPsec packet is de-encapsulated on an IPsec tunnel interface.
Figure 85 De-encapsulation process of an IPsec packet
5.
The router forwards an IPsec packet received on the inbound interface to the forwarding
module.
6.
Identifying that the destination address of the packet is the tunnel interface and the protocol is
AH or ESP, the forwarding module forwards the packet to the IPsec tunnel interface for
de-encapsulation.
7.
The IPsec tunnel interface de