HP 5500 HI Switch Series

HP 5500 HI Switch Series
Security
Configuration Guide
Part number: 5998-2383
Software version: Release 5203 and Release 5206
Document version: 6W102-20140228
Legal and notice information
© Copyright 2014 Hewlett-Packard Development Company, L.P.
No part of this documentation may be reproduced or transmitted in any form or by any means without
prior written consent of Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice.
HEWLETT-PACKARD COMPANY MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS
MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE. Hewlett-Packard shall not be liable for errors contained
herein or for incidental or consequential damages in connection with the furnishing, performance, or
use of this material.
The only warranties for HP 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. HP shall not be liable for technical or editorial errors or omissions contained
herein.
Contents
Configuring AAA ························································································································································· 1 AAA overview ··································································································································································· 1 RADIUS ······································································································································································ 2 HWTACACS ····························································································································································· 7 Domain-based user management ··························································································································· 9 RADIUS server feature of the switch ···················································································································· 10 AAA for MPLS L3VPNs ········································································································································· 11 Protocols and standards ······································································································································· 11 RADIUS attributes ·················································································································································· 12 FIPS compliance ····························································································································································· 15 AAA configuration considerations and task list ·········································································································· 15 Configuring AAA schemes ············································································································································ 16 Configuring local users ········································································································································· 16 Configuring RADIUS schemes ······························································································································ 21 Configuring HWTACACS schemes ····················································································································· 34 Configuring AAA methods for ISP domains ················································································································ 41 Configuration prerequisites ·································································································································· 41 Creating an ISP domain ······································································································································· 41 Configuring ISP domain attributes ······················································································································· 41 Configuring AAA authentication methods for an ISP domain ·········································································· 43 Configuring AAA authorization methods for an ISP domain ··········································································· 44 Configuring AAA accounting methods for an ISP domain ··············································································· 46 Tearing down user connections ···································································································································· 47 Configuring a NAS ID-VLAN binding ·························································································································· 47 Specifying the device ID used in stateful failover mode ···························································································· 48 Configuring a switch as a RADIUS server ··················································································································· 48 RADIUS server functions configuration task list ·································································································· 48 Configuring a RADIUS user ·································································································································· 48 Specifying a RADIUS client ·································································································································· 49 Displaying and maintaining AAA ································································································································ 50 AAA configuration examples ········································································································································ 50 AAA for Telnet users by an HWTACACS server ······························································································· 50 AAA for Telnet users by separate servers ··········································································································· 51 Authentication/authorization for SSH/Telnet users by a RADIUS server ························································ 53 Level switching authentication for Telnet users by an HWTACACS server ····················································· 56 RADIUS authentication and authorization for Telnet users by a switch··························································· 60 Troubleshooting AAA ···················································································································································· 62 Troubleshooting RADIUS······································································································································· 62 Troubleshooting HWTACACS······························································································································ 63 802.1X overview ······················································································································································· 64 802.1X architecture ······················································································································································· 64 Controlled/uncontrolled port and port authorization status ······················································································ 64 802.1X-related protocols ·············································································································································· 65 Packet formats ························································································································································ 65 EAP over RADIUS ·················································································································································· 67 Initiating 802.1X authentication ··································································································································· 67 802.1X client as the initiator································································································································ 67 Access device as the initiator ······························································································································· 67 i
802.1X authentication procedures ······························································································································ 68 A comparison of EAP relay and EAP termination ······························································································ 68 EAP relay ································································································································································ 69 EAP termination ····················································································································································· 70 Configuring 802.1X ·················································································································································· 72 HP implementation of 802.1X ······································································································································ 72 Access control methods ········································································································································ 72 Using 802.1X authentication with other features ······························································································ 72 Configuration prerequisites ··········································································································································· 77 802.1X configuration task list······································································································································· 78 Enabling 802.1X ···························································································································································· 78 Configuration guidelines ······································································································································ 78 Configuration procedure ······································································································································ 79 Enabling EAP relay or EAP termination ······················································································································· 79 Setting the port authorization state ······························································································································ 80 Specifying an access control method ·························································································································· 80 Setting the maximum number of concurrent 802.1X users on a port ······································································· 81 Setting the maximum number of authentication request attempts ············································································· 81 Setting the 802.1X authentication timeout timers ······································································································· 82 Configuring the online user handshake function ········································································································ 82 Configuration guidelines ······································································································································ 82 Configuration procedure ······································································································································ 83 Configuring the authentication trigger function ·········································································································· 83 Configuration guidelines ······································································································································ 83 Configuration procedure ······································································································································ 84 Specifying a mandatory authentication domain on a port························································································ 84 Configuring the quiet timer ··········································································································································· 84 Enabling the periodic online user re-authentication function····················································································· 85 Configuration guidelines ······································································································································ 85 Configuration procedure ······································································································································ 85 Configuring a port to send EAPOL frames untagged································································································· 86 Setting the maximum number of 802.1X authentication attempts for MAC authentication users ························· 86 Configuring a VLAN group ··········································································································································· 86 Configuring an 802.1X guest VLAN ··························································································································· 87 Configuration guidelines ······································································································································ 87 Configuration prerequisites ·································································································································· 88 Configuration procedure ······································································································································ 88 Configuring an 802.1X Auth-Fail VLAN······················································································································ 88 Configuration guidelines ······································································································································ 88 Configuration prerequisites ·································································································································· 89 Configuration procedure ······································································································································ 89 Configuring an 802.1X critical VLAN ························································································································· 89 Configuration guidelines ······································································································································ 89 Configuration prerequisites ·································································································································· 90 Configuration procedure ······································································································································ 90 Specifying supported domain name delimiters··········································································································· 90 Displaying and maintaining 802.1X ··························································································································· 91 802.1X authentication configuration example ··········································································································· 91 Network requirements ··········································································································································· 91 Configuration procedure ······································································································································ 92 Verifying the configuration ··································································································································· 93 802.1X with guest VLAN and VLAN assignment configuration example ······························································· 94 Network requirements ··········································································································································· 94 Configuration procedure ······································································································································ 95 ii
Verifying the configuration ··································································································································· 96 802.1X with ACL assignment configuration example ······························································································· 96 Network requirements ··········································································································································· 96 Configuration procedure ······································································································································ 97 Verifying the configuration ··································································································································· 97 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 ···································································································································· 102 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 approaches ································································································································ 104 MAC authentication timers ································································································································· 105 Using MAC authentication with other features ········································································································· 105 VLAN assignment ················································································································································ 105 ACL assignment ··················································································································································· 105 Guest VLAN ························································································································································· 105 Critical VLAN ······················································································································································· 106 Configuration task list ·················································································································································· 106 Basic configuration for MAC authentication ············································································································· 106 Configuring MAC authentication globally········································································································ 107 Configuring MAC authentication on a port ····································································································· 107 Specifying a MAC authentication domain ················································································································ 108 Configuring a MAC authentication guest VLAN ······································································································ 108 Configuring a MAC authentication critical VLAN ···································································································· 109 Configuring MAC authentication delay····················································································································· 110 Enabling MAC authentication multi-VLAN mode ······································································································ 110 Displaying and maintaining MAC authentication ···································································································· 111 MAC authentication configuration examples ············································································································ 111 Local MAC authentication configuration example··························································································· 111 RADIUS-based MAC authentication configuration example··········································································· 113 ACL assignment configuration example············································································································ 115 Configuring portal authentication ·························································································································· 118 Overview······································································································································································· 118 Extended portal functions ··································································································································· 118 Portal system components ··································································································································· 118 Portal system using the local portal server ········································································································ 120 Portal authentication modes ······························································································································· 121 Portal support for EAP ········································································································································· 122 Layer 2 portal authentication process ··············································································································· 123 Layer 3 portal authentication process ··············································································································· 124 iii
Portal stateful failover ·········································································································································· 127 Portal authentication across VPNs ····················································································································· 129 Portal configuration task list ········································································································································ 129 Configuration prerequisites ········································································································································· 130 Specifying the portal server ········································································································································ 131 Specifying the local portal server for Layer 2 portal authentication ······························································ 131 Specifying a portal server for Layer 3 portal authentication ·········································································· 132 Configuring the local portal server ···························································································································· 132 Customizing authentication pages ···················································································································· 132 Configuring the local portal server ···················································································································· 135 Enabling portal authentication ···································································································································· 136 Enabling Layer 2 portal authentication ············································································································· 136 Enabling Layer 3 portal authentication ············································································································· 136 Controlling access of portal users ······························································································································ 137 Configuring a portal-free rule····························································································································· 137 Configuring an authentication source subnet ··································································································· 138 Setting the maximum number of online portal users ························································································ 139 Specifying an authentication domain for portal users ····················································································· 139 Configuring Layer 2 portal authentication to support Web proxy································································· 140 Enabling support for portal user moving ·········································································································· 140 Specifying an Auth-Fail VLAN for portal authentication ·························································································· 141 Configuring RADIUS related attributes ······················································································································ 142 Specifying NAS-Port-Type for an interface ······································································································· 142 Specifying a NAS ID profile for an interface ··································································································· 142 Specifying a source IP address for outgoing portal packets ··················································································· 143 Configuring portal stateful failover····························································································································· 143 Specifying an auto redirection URL for authenticated portal users ········································································· 145 Configuring portal detection functions ······················································································································· 146 Configuring online Layer 2 portal user detection ···························································································· 146 Configuring the portal server detection function ······························································································ 146 Configuring portal user information synchronization ······················································································ 148 Logging off portal users ··············································································································································· 148 Displaying and maintaining portal ···························································································································· 149 Portal configuration examples ···································································································································· 150 Configuring direct portal authentication ··········································································································· 150 Configuring re-DHCP portal authentication ······································································································ 154 Configuring cross-subnet portal authentication ································································································ 156 Configuring direct portal authentication with extended functions·································································· 158 Configuring re-DHCP portal authentication with extended functions ···························································· 160 Configuring cross-subnet portal authentication with extended functions······················································· 162 Configuring portal stateful failover ···················································································································· 164 Configuring portal server detection and portal user information synchronization ······································· 172 Cross-subnet portal authentication across VPNs ······························································································ 177 Configuring Layer 2 portal authentication ········································································································ 179 Troubleshooting portal ················································································································································· 183 Inconsistent keys on the access device and the portal server ········································································· 183 Incorrect server port number on the access device·························································································· 183 Configuring triple authentication ··························································································································· 185 Overview······································································································································································· 185 Triple authentication mechanism ······················································································································· 185 Using triple authentication with other features ································································································· 186 Configuring triple authentication ································································································································ 186 Triple authentication configuration examples ··········································································································· 187 Triple authentication basic function configuration example ··········································································· 187 iv
Triple authentication supporting VLAN assignment and Auth-Fail VLAN configuration example ·············· 189 Configuring port security ········································································································································ 195 Overview······································································································································································· 195 Port security features ··········································································································································· 195 Port security modes ············································································································································· 195 Working with guest VLAN and Auth-Fail VLAN ······························································································ 198 Configuration task list ·················································································································································· 198 Enabling port security ·················································································································································· 199 Setting port security's limit on the number of MAC addresses on a port······························································· 199 Setting the port security mode ···································································································································· 200 Configuration prerequisites ································································································································ 200 Configuration procedure ···································································································································· 200 Configuring port security features ······························································································································ 201 Configuring NTK ················································································································································· 201 Configuring intrusion protection ························································································································ 201 Enabling port security traps ································································································································ 202 Configuring secure MAC addresses ·························································································································· 202 Configuration prerequisites ································································································································ 203 Configuration procedure ···································································································································· 203 Ignoring authorization information ···························································································································· 204 Displaying and maintaining port security·················································································································· 204 Port security configuration examples ························································································································· 205 Configuring the autoLearn mode ······················································································································· 205 Configuring the userLoginWithOUI mode ········································································································ 207 Configuring the macAddressElseUserLoginSecure mode ················································································ 212 Troubleshooting port security ······································································································································ 214 Cannot set the port security mode ····················································································································· 214 Cannot configure secure MAC addresses ········································································································ 215 Cannot change port security mode when a user is online·············································································· 215 Configuring a user profile ······································································································································ 217 Overview······································································································································································· 217 User profile configuration task list ······························································································································ 217 Creating a user profile ················································································································································ 217 Applying a QoS policy ··············································································································································· 218 Enabling a user profile ················································································································································ 218 Displaying and maintaining user profiles ·················································································································· 219 Configuring password control ································································································································ 220 Overview······································································································································································· 220 FIPS compliance ··························································································································································· 222 Password control configuration task list ····················································································································· 223 Configuring password control ···································································································································· 223 Enabling password control ································································································································· 223 Setting global password control parameters ···································································································· 224 Setting user group password control parameters ···························································································· 225 Setting local user password control parameters ······························································································ 226 Setting super password control parameters ····································································································· 227 Setting a local user password in interactive mode ·························································································· 227 Displaying and maintaining password control ········································································································· 227 Password control configuration example ·················································································································· 228 Configuring HABP ··················································································································································· 231 Overview······································································································································································· 231 Configuring HABP ························································································································································ 232 v
Configuring the HABP server ····························································································································· 232 Configuring an HABP client ······························································································································· 232 Displaying and maintaining HABP····························································································································· 233 HABP configuration example ······································································································································ 233 Managing public keys ············································································································································ 236 Overview······································································································································································· 236 FIPS compliance ··························································································································································· 236 Configuration task list ·················································································································································· 237 Creating a local asymmetric key pair ························································································································ 237 Displaying or exporting the local host public key ···································································································· 238 Destroying a local asymmetric key pair ···················································································································· 239 Specifying the peer public key on the local device·································································································· 239 Displaying and maintaining public keys ··················································································································· 240 Public key configuration examples ····························································································································· 241 Manually specifying the peer public key on the local device ········································································ 241 Importing a peer public key from a public key file·························································································· 243 Configuring PKI ······················································································································································· 246 Overview······································································································································································· 246 PKI terms ······························································································································································· 246 PKI architecture ···················································································································································· 247 PKI operation ······················································································································································· 247 PKI applications ··················································································································································· 248 PKI configuration task list ············································································································································ 248 Configuring an entity DN ············································································································································ 249 Configuring a PKI domain··········································································································································· 250 Configuration guidelines ···································································································································· 251 Configuration procedure ···································································································································· 251 Submitting a PKI certificate request ···························································································································· 251 Submitting a certificate request in auto mode ·································································································· 252 Submitting a certificate request in manual mode ····························································································· 252 Retrieving a certificate manually ································································································································ 253 Configuration guidelines ···································································································································· 253 Configuration procedure ···································································································································· 254 Configuring PKI certificate verification ······················································································································ 254 Configuration guidelines ···································································································································· 254 Configuring CRL-checking-enabled PKI certificate verification ······································································· 254 Configuring CRL-checking-disabled PKI certificate verification ······································································ 255 Destroying a local RSA key pair ································································································································ 255 Deleting a certificate ···················································································································································· 256 Configuring an access control policy ························································································································ 256 Displaying and maintaining PKI ································································································································· 256 PKI configuration examples ········································································································································· 257 Certificate request from an RSA Keon CA server ···························································································· 257 Certificate request from a Windows 2003 CA server ···················································································· 260 Certificate attribute access control policy configuration example ································································· 263 Troubleshooting PKI ····················································································································································· 265 Failed to retrieve a CA certificate······················································································································ 265 Failed to request a local certificate ··················································································································· 265 Failed to retrieve CRLs ········································································································································ 266 Configuring IPsec ···················································································································································· 267 Overview······································································································································································· 267 Basic concepts ····················································································································································· 267 IPsec for IPv6 routing protocols ·························································································································· 270 vi
Protocols and standards ····································································································································· 270 FIPS compliance ··························································································································································· 270 Configuring IPsec ························································································································································· 270 Implementing ACL-based IPsec ··································································································································· 270 Feature Restrictions ·············································································································································· 270 ACL-based IPsec configuration task list ············································································································· 271 Configuring ACLs ················································································································································ 271 Configuring an IPsec proposal ·························································································································· 273 Configuring an IPsec policy ······························································································································· 274 Applying an IPsec policy group to an interface ······························································································· 278 Configuring the IPsec session idle timeout ········································································································ 278 Enabling ACL checking of de-encapsulated IPsec packets ············································································· 279 Configuring the IPsec anti-replay function ········································································································ 279 Configuring packet information pre-extraction ································································································ 280 Configuring IPsec for IPv6 routing protocols ············································································································· 280 Displaying and maintaining IPsec ······························································································································ 281 IPsec configuration examples······································································································································ 281 IKE-based IPsec tunnel for IPv4 packets configuration example ····································································· 281 IPsec for RIPng configuration example ·············································································································· 284 Configuring IKE ······················································································································································· 288 FIPS compliance ··························································································································································· 288 Overview······································································································································································· 288 IKE security mechanism······································································································································· 288 IKE operation ······················································································································································· 289 IKE functions ························································································································································· 289 Relationship between IKE and IPsec ·················································································································· 290 Protocols and standards ····································································································································· 290 IKE configuration task list ············································································································································ 290 Configuring a name for the local security gateway ································································································· 291 Configuring an IKE proposal ······································································································································ 291 Configuring an IKE peer·············································································································································· 292 Setting keepalive timers ··············································································································································· 294 Setting the NAT keepalive timer ································································································································· 294 Configuring a DPD detector ········································································································································ 295 Disabling next payload field checking ······················································································································ 295 Displaying and maintaining IKE ································································································································· 296 IKE configuration example ·········································································································································· 296 Troubleshooting IKE ····················································································································································· 299 Invalid user ID ······················································································································································ 299 Proposal mismatch ·············································································································································· 299 Failing to establish an IPsec tunnel ···················································································································· 300 ACL configuration error ······································································································································ 300 Configuring SSH2.0 ··············································································································································· 301 Overview······································································································································································· 301 SSH operation ····················································································································································· 301 SSH connection across VPNs ····························································································································· 303 FIPS compliance ··························································································································································· 304 Configuring the switch as an SSH server ·················································································································· 304 SSH server configuration task list ······················································································································ 304 Generating DSA or RSA key pairs ···················································································································· 304 Enabling the SSH server function······················································································································· 305 Configuring the user interfaces for SSH clients ································································································ 305 Configuring a client public key ·························································································································· 306 vii
Configuring an SSH user ···································································································································· 307 Setting the SSH management parameters ········································································································ 308 Setting the DSCP value for packets sent by the SSH server ············································································ 309 Configuring the switch as an SSH client ··················································································································· 309 SSH client configuration task list ························································································································ 309 Specifying a source IP address/interface for the SSH client ·········································································· 310 Configuring whether first-time authentication is supported ············································································· 310 Establishing a connection between the SSH client and server ······································································· 311 Setting the DSCP value for packets sent by the SSH client ············································································· 312 Displaying and maintaining SSH ······························································································································· 312 SSH server configuration examples ··························································································································· 313 When the switch acts as a server for password authentication ····································································· 313 When the switch acts as a server for publickey authentication ····································································· 315 SSH client configuration examples····························································································································· 320 When switch acts as client for password authentication ················································································ 320 When switch acts as client for publickey authentication ················································································ 323 Configuring SFTP····················································································································································· 326 Overview······································································································································································· 326 FIPS compliance ··························································································································································· 326 Configuring the switch as an SFTP server ················································································································· 326 Enabling the SFTP server ···································································································································· 326 Configuring the SFTP connection idle timeout period ····················································································· 327 Configuring the switch as an SFTP client ··················································································································· 327 Specifying a source IP address or interface for the SFTP client ······································································ 327 Establishing a connection to the SFTP server ···································································································· 327 Working with SFTP directories ··························································································································· 328 Working with SFTP files ······································································································································ 329 Displaying help information ······························································································································· 330 Terminating the connection to the remote SFTP server ···················································································· 330 Setting the DSCP value for packets sent by the SFTP client ············································································ 330 SFTP client configuration example ····························································································································· 331 SFTP server configuration example ···························································································································· 334 Configuring SCP······················································································································································ 337 Overview······································································································································································· 337 FIPS compliance ··························································································································································· 337 Configuring the switch as an SCP server ·················································································································· 337 Configuring the switch as the SCP client ··················································································································· 338 SCP client configuration example ······················································································································ 339 SCP server configuration example ···················································································································· 340 Configuring SSL ······················································································································································· 342 Overview······································································································································································· 342 SSL security mechanism ······································································································································ 342 SSL protocol stack ··············································································································································· 342 FIPS compliance ··························································································································································· 343 Configuration task list ·················································································································································· 343 Configuring an SSL server policy ······························································································································· 343 SSL server policy configuration example ·········································································································· 345 Configuring an SSL client policy ································································································································ 347 Displaying and maintaining SSL································································································································· 347 Troubleshooting SSL ····················································································································································· 348 Configuring TCP attack protection ························································································································· 349 Overview······································································································································································· 349 viii
Enabling the SYN Cookie feature ······························································································································ 349 Displaying and maintaining TCP attack protection ·································································································· 349 Configuring IP source guard ·································································································································· 351 Overview······································································································································································· 351 Static IP source guard entries ····························································································································· 351 Dynamic IP source guard binding entries ········································································································· 352 Configuration task list ·················································································································································· 352 Configuring the IPv4 source guard function ·············································································································· 353 Configuring IPv4 source guard on a port ········································································································· 353 Configuring a static IPv4 source guard entry ··································································································· 354 Setting the maximum number of IPv4 source guard binding entries ····························································· 355 Configuring the IPv6 source guard function ·············································································································· 356 Configuring IPv6 source guard on a port ········································································································· 356 Configuring a static IPv6 source guard entry ··································································································· 357 Setting the maximum number of IPv6 source guard entries ············································································ 358 Displaying and maintaining IP source guard ············································································································ 358 IP source guard configuration examples ··················································································································· 359 Static IPv4 source guard configuration example ····························································································· 359 Dynamic IPv4 source guard using DHCP snooping configuration example ················································· 361 Dynamic IPv4 source guard using DHCP relay configuration example ························································ 362 Static IPv6 source guard configuration example ····························································································· 363 Dynamic IPv6 source guard using DHCPv6 snooping configuration example············································· 364 Dynamic IPv6 source guard using ND snooping configuration example ····················································· 365 Global static IP source guard configuration example ····················································································· 366 Troubleshooting IP source guard ································································································································ 368 Configuring ARP attack protection························································································································· 369 Overview······································································································································································· 369 ARP attack protection configuration task list ············································································································· 369 Configuring ARP defense against IP packet attacks ································································································· 370 Configuring ARP source suppression ················································································································ 370 Enabling ARP black hole routing ······················································································································· 371 Displaying and maintaining ARP defense against IP packet attacks ····························································· 371 Configuration example ······································································································································· 371 Configuring ARP packet rate limit ······························································································································ 372 Introduction ·························································································································································· 372 Configuration procedure ···································································································································· 372 Configuring source MAC address based ARP attack detection ············································································· 373 Configuration procedure ···································································································································· 373 Displaying and maintaining source MAC address based ARP attack detection ·········································· 374 Configuration example ······································································································································· 374 Configuring ARP packet source MAC address consistency check ········································································· 376 Introduction ·························································································································································· 376 Configuration procedure ···································································································································· 376 Configuring ARP active acknowledgement ··············································································································· 376 Introduction ·························································································································································· 376 Configuration procedure ···································································································································· 376 Configuring ARP detection ·········································································································································· 377 Introduction ·························································································································································· 377 Configuring user validity check ························································································································· 377 Configuring ARP packet validity check ············································································································· 378 Configuring ARP restricted forwarding ············································································································· 379 Configuring the ARP detection logging function ······························································································ 379 Displaying and maintaining ARP detection ······································································································ 380 ix
User validity check configuration example ······································································································· 380 User validity check and ARP packet validity check configuration example ·················································· 381 ARP restricted forwarding configuration example ··························································································· 383 Configuring ARP automatic scanning and fixed ARP······························································································· 384 Configuration guidelines ···································································································································· 385 Configuration procedure ···································································································································· 385 Configuring ARP gateway protection ························································································································ 385 Configuration guidelines ···································································································································· 385 Configuration procedure ···································································································································· 386 Configuration example ······································································································································· 386 Configuring ARP filtering ············································································································································· 387 Configuration guidelines ···································································································································· 387 Configuration procedure ···································································································································· 387 Configuration example ······································································································································· 387 Configuring ND attack defense ····························································································································· 389 Overview······································································································································································· 389 Enabling source MAC consistency check for ND packets ······················································································· 390 Configuring the ND detection function ······················································································································ 390 Introduction to ND detection ······························································································································ 390 Configuration guidelines ···································································································································· 391 Configuration procedure ···································································································································· 391 Displaying and maintaining ND detection ······································································································· 391 ND detection configuration example ························································································································· 392 Network requirements ········································································································································· 392 Configuration procedure ···································································································································· 392 Configuring URPF ···················································································································································· 394 Overview······································································································································································· 394 URPF check modes ·············································································································································· 394 How URPF works ················································································································································· 394 Network application ··········································································································································· 397 Configuring URPF ························································································································································· 397 URPF configuration example ······································································································································· 397 Configuring MFF ····················································································································································· 399 Overview······································································································································································· 399 Basic concepts ····················································································································································· 400 Operation modes ················································································································································ 400 Working mechanism ··········································································································································· 401 Protocols and standards ····································································································································· 401 Configuring MFF ·························································································································································· 401 Configuration prerequisites ································································································································ 401 Enabling MFF ······················································································································································· 402 Configuring a network port ································································································································ 402 Enabling periodic gateway probe ···················································································································· 402 Specifying the IP addresses of servers ·············································································································· 402 Displaying and maintaining MFF ······························································································································· 403 MFF configuration examples ······································································································································· 403 Auto-mode MFF configuration example in a tree network ·············································································· 403 Auto-mode MFF configuration example in a ring network ············································································· 405 Manual-mode MFF configuration example in a tree network········································································· 407 Manual-mode MFF configuration example in a ring network ········································································ 408 Configuring SAVI ···················································································································································· 410 Overview······································································································································································· 410 x
Configuring global SAVI ············································································································································· 410 SAVI configuration in DHCPv6-only address assignment scenario ········································································ 411 Network requirements ········································································································································· 411 Configuration considerations ····························································································································· 411 Packet check principles ······································································································································· 412 Configuration procedure ···································································································································· 412 SAVI configuration in SLAAC-only address assignment scenario ··········································································· 413 Network requirements ········································································································································· 413 Configuration considerations ····························································································································· 413 Packet check principles ······································································································································· 414 Configuration procedure ···································································································································· 414 SAVI configuration in DHCPv6+SLAAC address assignment scenario ·································································· 415 Network requirements ········································································································································· 415 Configuration considerations ····························································································································· 415 Packet check principles ······································································································································· 416 Configuration procedure ···································································································································· 416 Configuring blacklist ··············································································································································· 418 Overview······································································································································································· 418 Configuring the blacklist feature································································································································· 418 Displaying and maintaining the blacklist ·················································································································· 418 Blacklist configuration example ·································································································································· 419 Network requirements ········································································································································· 419 Configuration procedure ···································································································································· 419 Verifying the configuration ································································································································· 419 Configuring FIPS······················································································································································ 421 Overview······································································································································································· 421 FIPS self-tests ································································································································································· 421 Power-up self-test ················································································································································· 421 Conditional self-tests ············································································································································ 421 Triggering a self-test ············································································································································ 421 Configuration procedure ············································································································································· 422 Enabling the FIPS mode ······································································································································ 422 Triggering a self-test ············································································································································ 423 Displaying and maintaining FIPS ······························································································································· 423 FIPS configuration example········································································································································· 423 Network requirements ········································································································································· 423 Configuration procedure ···································································································································· 423 Verifying the configuration ································································································································· 424 Support and other resources ·································································································································· 426 Contacting HP ······························································································································································ 426 Subscription service ············································································································································ 426 Related information ······················································································································································ 426 Documents ···························································································································································· 426 Websites······························································································································································· 426 Conventions ·································································································································································· 427 Index ········································································································································································ 429 xi
Configuring AAA
AAA overview
Authentication, Authorization, and Accounting (AAA) provides a uniform framework for implementing
network access management. It can provide the following security functions:
•
Authentication—Identifies users and determines whether a user is valid.
•
Authorization—Grants different users different rights and controls their access to resources and
services. For example, a user who has successfully logged in to the switch can be granted read and
print permissions to the files on the switch.
•
Accounting—Records all user network service usage information, including the service type, start
time, and traffic. The accounting function not only provides the information required for charging,
but also allows for network security surveillance.
AAA usually uses a client/server model. The client runs on the network access server (NAS), which is
also referred to as the access device. The server maintains user information centrally. In an AAA network,
a NAS is a server for users but a client for the AAA servers. See Figure 1.
Figure 1 Network diagram
When a user tries to log in to the NAS, use network resources, or access other networks, the NAS
authenticates the user. The NAS can transparently pass the user’s authentication, authorization, and
accounting information to the servers. The RADIUS and HWTACACS protocols define how a NAS and
a remote server exchange user information between them.
In the network shown in Figure 1, there is a RADIUS server and an HWTACACS server. You can choose
different servers for different security functions. For example, you can use the HWTACACS server for
authentication and authorization, and the RADIUS server for accounting.
You can choose the three security functions provided by AAA as needed. For example, if your company
only 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 switch supports using RADIUS and
HWTACACS. RADIUS is often used in practice.
1
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 where both high security and remote user access are required.
RADIUS uses UDP as the transport protocol. It 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, such as Ethernet and ADSL. RADIUS
provides access authentication and authorization services, and its accounting function collects and
records network resource usage information.
Client/server model
The RADIUS client runs on the NASs located throughout the network. It passes user information to
designated RADIUS servers and acts on the responses (for example, rejects or accepts user access
requests).
The RADIUS server runs on the computer or workstation at the network center and maintains information
related to user authentication and network service access. It listens to connection requests, authenticates
users, and returns user access control information (for example, rejecting or accepting the user access
request) to the clients.
In general, the RADIUS server maintains the following databases: Users, Clients, and Dictionary.
Figure 2 RADIUS server components
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
A RADIUS client and the RADIUS server use the shared key to authenticate RADIUS packets and encrypt
user passwords that are exchanged between them. The keys are never transmitted over the network. This
security mechanism improves the security of RADIUS communication and prevents user passwords from
being intercepted on insecure networks.
A RADIUS server supports multiple user authentication methods. 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.
2
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 by using the
Message-Digest 5 (MD5) algorithm and the shared key.
3.
The RADIUS server authenticates the username and password. If the authentication succeeds, the
server sends back 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 a start-accounting response (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 a stop-accounting response (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 series of mechanisms, including the timer management mechanism,
the retransmission mechanism, and the backup server mechanism. Figure 4 shows the RADIUS packet
format.
3
Figure 4 RADIUS packet format
Descriptions of the fields are as follows:
The Code field (1 byte long) indicates the type of the RADIUS packet. Table 1 gives the possible
values and their meanings.
•
Table 1 Main values of the Code field
Code
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 the 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.
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.
Accounting-Response
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.
4
5
•
The Identifier field (1 byte long) is used to match request 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 Attribute 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 of 20 to 4096.
•
The Authenticator field (16 bytes long) is used to authenticate replies from the RADIUS server and to
encrypt user passwords. There are two types of authenticators: request authenticator and response
authenticator.
4
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 shows a list
of the attributes. For more information about commonly used standard RADIUS attributes, see
"Commonly used standard RADIUS attributes."
Length—(1 byte long) Length of the attribute in bytes, including the Type, Length, and Value
fields.
Value—(Up to 253 bytes) Value of the attribute. Its format and content depend on the Type and
Length 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
5
No.
Attribute
No.
Attribute
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
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
The RADIUS protocol features excellent extensibility. Attribute 26 (Vendor-Specific), an attribute defined
by 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 in the type-length-value (TLV) format in RADIUS packets
for extension of applications. As shown in Figure 5, a sub-attribute encapsulated in Attribute 26 consists
of the following parts:
•
Vendor-ID—Indicates the ID of the vendor. Its most significant byte is 0, and the other three bytes
contains a code that is compliant to RFC 1700. For more information about the proprietary RADIUS
sub-attributes of HP, see "HP proprietary RADIUS sub-attributes."
•
Vendor-Type—Indicates the type of the sub-attribute.
•
Vendor-Length—Indicates the length of the sub-attribute.
•
Vendor-Data—Indicates the contents of the sub-attribute.
6
Figure 5 Segment of a RADIUS packet containing an extended attribute
0
7
Type
23
15
Length
31
Vendor-ID
Vendor-ID (continued)
Vendor-Type
Vendor-Length
Vendor-Data
(Specified attribute value……)
……
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.
HWTACACS typically provides AAA services for Point-to-Point Protocol (PPP) users, Virtual Private Dial-up
Network (VPDN) users, and terminal users. In a typical HWTACACS scenario, some terminal users log
in to the NAS for operations. Working as the HWTACACS client, the NAS sends the usernames and
passwords of the users to the HWTACACS sever for authentication. After passing authentication and
being authorized, the users log in to the switch and performs operations, and the HWTACACS server
records the operations that each user performs.
Differences between HWTACACS and RADIUS
HWTACACS and RADIUS both provide authentication, authorization, and accounting services. They
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 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.
Which commands a user can use depends on both the
user level and the 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. Which commands a user can use solely
depends 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.
7
Figure 6 Basic HWTACACS message exchange process for a Telnet user
Host
HWTACACS client
HWTACACS server
1) The user logs in
2) Start-authentication packet
3) Authentication response requesting the username
4) Request for username
5) The user inputs the username
6) Authentication continuance packet with the
username
7) Authentication response requesting the login
password
8) Request for password
9) The user inputs the password
10) Authentication continuance packet with the
login password
11) Authentication response indicating successful
authentication
12) User authorization request packet
13) Authorization response indicating successful
authorization
14) The user logs in successfully
15) Start-accounting request
16) Accounting response indicating the start of
accounting
17) The user logs off
18) Stop-accounting request
19) Stop-accounting response
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.
8
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 an 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 configuration interface
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 Internet service provider (ISP) domains. On a NAS, each user belongs
to one ISP domain. A NAS determines the ISP domain a user belongs to 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
NAS
A user enters the username in
the form of
userid@domain-name
or userid
Username contains
@domain-name?
Yes
Use the AAA methods and
attributes of domain
domain-name for the user
No
Use the AAA methods and attributes
of the default domain for the user
The authentication, authorization, and accounting of a user depends on the AAA methods configured for
the domain to which the user belongs. 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 switch, including SSH users, Telnet users, Web users,
FTP users, and terminal users.
9
•
Portal users—Users who must pass portal authentication to access the network.
In addition, AAA provides the following services for login users to enhance switch security:
•
Command authorization—Enables the NAS to defer to the authorization server to determine
whether a command entered by a login user is permitted for the user, making sure that login users
execute only commands they are authorized to execute. For more information about command
authorization, see Fundamentals Configuration Guide.
•
Command accounting—Allows the accounting server to record all commands executed on the
switch 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 authentication, authorization, and accounting methods for different types of
users in a domain. See "Configuring AAA methods for ISP domains."
RADIUS server feature of the switch
Generally, the RADIUS server runs on a computer or workstation, and the RADIUS client runs on a NAS.
A network device that supports the RADIUS server feature can also serve as the RADIUS server, working
with RADIUS clients to implement user authentication, authorization, and accounting. As shown in Figure
8, the RADIUS server and client can reside on the same switch or different switches.
Using a network device as the RADIUS server simplifies networking and reduces deployment costs. This
implementation is usually deployed on networks by using the clustering feature. In such a scenario,
configure the RADIUS server feature on a management device at the distribution layer, so that the device
functions as a RADIUS server to cooperate with cluster member switches at the access layer to provide
user authentication and authorization services.
Figure 8 Devices functioning as a RADIUS server
IP network
IP network
RADIUS server
NAS/ RADIUS server
NAS
The switch can serve as a RADIUS server to provide the following functions:
•
User information management:
You can create, modify, and delete user information, including the username, password, authority,
lifetime, and user description.
•
RADIUS client information management:
10
You can create and delete RADIUS clients, which are identified by IP addresses and configured
with attributes such as a shared key. With a managed client range configured, the RADIUS server
processes only the RADIUS packets from the clients within the management range. A shared key
is used to ensure secure communication between a RADIUS client and the RADIUS server.
•
RADIUS authentication and authorization
With the RADIUS server enabled, the switch checks whether or not the client of an incoming RADIUS
packet is under its management. If yes, it verifies the packet validity by using the shared key, checks
whether there is an account with the username, whether the password is correct, and whether the user
attributes meet the requirements defined on the RADIUS server (for example, whether the account has
expired). Then, the RADIUS server assigns the corresponding authority to the client if the authentication
succeeds, or denies the client if the authentication fails.
NOTE:
A RADIUS server running the standard RADIUS protocol listens on UDP port 1812 for authentication
requests, but an HP switch listens on UDP port 1645 instead when acting as the RADIUS server. Be sure to
specify 1645 as the authentication port number on the RADIUS client when you use an HP switch as the
RADIUS server.
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 RADIUS and HWTACACS packets across MPLS VPNs. With the
AAA across VPNs 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 9. Authentication packets of private users in different
VPNs do not affect each other.
Figure 9 Network diagram
VPN 1
CE
VPN 3
NAS
RADIUS
server
MPLS backbone
Host
PE
PE
VPN 2
Host
CE
P
HWTACACS
server
CE
NOTE:
This feature can also help an MCE to implement portal authentication for VPNs. For more information
about MCE, see MPLS Configuration Guide.
Protocols and standards
The following protocols and standards are related to AAA, RADIUS, and HWTACACS:
11
•
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
RADIUS attributes
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, present only in Access-Request packets in
PAP authentication mode.
3
CHAP-Password
Digest of the user password for CHAP authentication, present only in
Access-Request packets in CHAP authentication mode.
4
NAS-IP-Address
IP address for the server to identify a client. Usually, a client is identified by the IP
address of the access interface on the NAS, namely the NAS IP address. This
attribute is present in only 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
Maximum transmission unit (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 duration of service to be provided to 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 HP device, this attribute carries the MAC address of the user in
the format HHHH-HHHH-HHHH.
32
NAS-Identifier
Identification that the NAS uses for indicating itself.
12
No.
Attribute
Description
Type of the Accounting-Request packet. Possible values are as follows:
40
Acct-Status-Type
•
•
•
•
•
1—Start.
2—Stop.
3—Interim-Update.
4—Reset-Charge.
7—Accounting-On. (Defined in 3GPP, the 3rd Generation Partnership
Project.)
• 8—Accounting-Off. (Defined in 3GPP.)
• 9 to 14—Reserved for tunnel accounting.
• 15—Reserved for failed.
Authentication method used by the user. Possible values are as follows:
45
Acct-Authentic
60
CHAP-Challenge
• 1—RADIUS.
• 2—Local.
• 3—Remote.
CHAP challenge generated by the NAS for MD5 calculation during CHAP
authentication.
Type of the physical port of the NAS that is authenticating the user. Possible
values are as follows:
61
NAS-Port-Type
•
•
•
•
•
•
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 for encapsulating EAP packets to allow the NAS to authenticate dial-in
users via EAP without having to understand the EAP protocol.
80
Message-Authentic
ator
Used for authentication and checking of authentication packets to prevent
spoofing Access-Requests. This attribute is used when RADIUS supports EAP
authentication.
87
NAS-Port-Id
String for describing the port of the NAS that is authenticating the user.
HP proprietary RADIUS sub-attributes
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.
13
No.
Sub-attribute
Description
15
Remanent_Volume
Remaining, available total traffic of the connection, in different units for
different server types.
Operation for the session, used for session control. It can be:
20
24
Command
Control_Identifier
•
•
•
•
•
1—Trigger-Request.
2—Terminate-Request.
3—SetPolicy.
4—Result.
5—PortalClear.
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 the attribute must be the same.
For Accounting-Request packets of the start, stop, and interim update
types, the Control-Identifier attribute is ineffective.
25
Result_Code
Result of the Trigger-Request or SetPolicy operation. A value of zero
means the operation succeeded. Any other value means the operation
failed.
26
Connect_ID
Index of the user connection.
28
Ftp_Directory
For an FTP user, when the RADIUS client acts as the FTP server, this
attribute is used to set the FTP directory on the RADIUS client.
29
Exec_Privilege
Priority of the EXEC user.
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 to be sent from the server to the client transparently.
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 device and
is used for verifying the handshake messages from the 802.1X user. This
attribute exists in only Access-Accept and Accounting-Request packets.
140
User_Group
User groups assigned after the SSL VPN user passes authentication. A
user may belong to more than one user group. In this case, the user
groups are delimited by semi-colons. This attribute is used for
cooperation with the SSL VPN device.
141
Security_Level
Security level assigned after the SSL VPN user passes security
authentication.
201
Input-Interval-Octets
Bytes input within a real-time accounting interval.
202
Output-Interval-Octets
Bytes output within a real-time accounting interval.
203
Input-Interval-Packets
Packets input within an accounting interval, in the unit set on the device.
204
Output-Interval-Packets
Packets output within an accounting interval, in the unit set on the device.
205
Input-Interval-Gigawords
Result of bytes input within an accounting interval divided by 4G bytes.
Working directory of the FTP user.
62
14
No.
Sub-attribute
Description
206
Output-Interval-Gigawords
Result of bytes output within an accounting interval divided by 4G bytes.
207
Backup-NAS-IP
Backup source IP address for sending RADIUS packets.
255
Product_ID
Product name.
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.
AAA configuration considerations and task list
To configure AAA, you must complete these tasks on the NAS:
1.
Configure the required AAA schemes.
{
{
2.
Local authentication—Configure local users and the related attributes, including the usernames
and passwords of 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 users’ ISP domains.
{
{
{
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)
Figure 10 AAA configuration diagram
Local AAA
Configure AAA methods
Configure local users and related
attributes
None
Authentication method
No AAA
+
Create an ISP domain
and enter its view
Authorization method
local (the default)
scheme
None
local (the default)
scheme
+
Accounting method
Configure the RADIUS and
HWTACACS schemes
None
local (the default)
scheme
Remote AAA
15
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 AAA authentication methods for
an ISP domain
Configuring AAA authorization methods for an
ISP domain
Required.
Complete at least one task.
Configuring AAA accounting methods for an
ISP domain
Tearing down user connections
Optional.
Configuring a NAS ID-VLAN binding
Optional.
Specifying the device ID used in stateful failover mode
Optional.
Configuring a switch as a RADIUS server
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 about the configuration command, see
Fundamentals Command Reference.
Configuring AAA schemes
Configuring local users
To implement local user authentication, authorization, and accounting, you must create local users and
configure user attributes on the switch. The local users and attributes are stored in the local user database
on the switch. A local user is uniquely identified by a username. Configurable local user attributes are as
follows:
•
Service type.
Types of 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 FTP, LAN access, portal, SSH, Telnet, terminal, and Web.
•
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.
16
•
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. For temporary network access requirements, 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."
•
Binding attributes.
Binding attributes are used to control 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 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. For more information
about binding attributes, see "Configuring local user attributes." Be cautious when deciding which
binding attributes to configure for a local user.
•
Authorization attributes.
Authorization attributes indicate the rights that a user has after passing local authentication.
Authorization attributes include the ACL, 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.
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 only for 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:
17
•
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 (set by 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 a user profile."
•
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
No local user exists by default.
Optional.
• In non-FIPS mode:
3.
Configure a password for the
local user.
password [ [ hash ] { cipher |
simple } password ]
• In FIPS mode:
password
A local user with no password
configured passes authentication
after providing the valid local
username and attributes. To
enhance security, configure a
password for each local user.
If none of the parameters is
specified, you enter the interactive
mode to set a plaintext password.
This interactive mode is available
only on switches that support the
password control feature.
• In non-FIPS mode:
4.
Specify the service types for
the local user.
service-type { ftp | lan-access |
{ ssh | telnet | terminal } * |
portal | web }
• In FIPS mode:
By default, no service is authorized
to a local user.
service-type { lan-access | { ssh
| terminal } * | portal | web }
Optional.
5.
Place the local user to the
state of active or blocked.
state { active | block }
18
When created, a local user is in
active state by default, and the user
can request network services.
Step
Command
Remarks
Optional.
6.
Set the maximum number of
concurrent users of the local
user account.
access-limit max-user-number
The limit is effective only for local
accounting, and is not effective for
FTP users.
• Set the password aging time:
password-control aging
aging-time
7.
Configure the password
control attributes for the local
user.
• 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 ]
8.
Configure the binding
attributes for the local user.
By default, there is no limit to the
maximum number of concurrent
users of a local user account.
bind-attribute { ip ip-address |
location port slot-number
subslot-number port-number | mac
mac-address | vlan vlan-id } *
Optional.
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.
For more information about
password control configuration
commands, see Security
Command Reference.
Optional.
By default, no binding attribute is
configured for a local user.
Optional.
By default, no authorization
attribute is configured for a local
user.
9.
Configure the authorization
attributes for the local user.
authorization-attribute { acl
acl-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 LAN and portal users, only acl,
idle-cut, user-profile, and vlan are
supported.
For SSH, terminal, and Web 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
binding 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.
Optional.
Not set by default.
Optional.
Not set by default.
Optional.
group group-name
19
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 consists of 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 system default user group system and bears all
attributes of the group. To change the user group to which a local user belongs, 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
• Set the password aging time:
password-control aging
aging-time
• Set the minimum password
3.
Configure password control
attributes for the user group.
length:
password-control length length
• Configure the password
composition policy:
password-control composition
type-number type-number
[ type-length type-length ]
4.
Configure the authorization
attributes for the user group.
authorization-attribute { acl
acl-number | idle-cut minute | level
level | user-profile profile-name |
vlan vlan-id | work-directory
directory-name } *
Optional.
By default, the user group uses
global password control attribute
settings.
For more information about
password control attributes
configuration commands, see
Security Command Reference.
Optional.
By default, no authorization
attribute is configured for a user
group.
Optional.
5.
Set the guest attribute for the
user group.
group-attribute allow-guest
By default, the guest attribute is not
set for a user group, and guest
users created by a guest manager
through the Web interface cannot
join the group.
Displaying and maintaining local users and local user groups
Task
Command
Remarks
Display local user information
display local-user [ idle-cut { disable |
enable } | service-type { ftp |
lan-access | portal | ssh | telnet |
terminal | web } | state { active |
block } | user-name user-name | vlan
vlan-id ] [ slot slot-number ] [ | { begin |
exclude | include } regular-expression ]
Available in any view
20
Task
Command
Remarks
Display the user group configuration
information.
display user-group [ group-name ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any view
Configuring RADIUS schemes
A RADIUS scheme specifies the RADIUS servers that the switch can cooperate with and defines a set of
parameters that the switch uses to exchange information with the RADIUS servers. There may 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 the VPN to which the servers belong
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
Specifying a backup source IP address for outgoing RADIUS packets
Optional
Setting timers for controlling communication with RADIUS servers
Optional
Configuring RADIUS accounting-on
Optional
Configuring the IP address of the security policy server
Optional
Configuring interpretation of RADIUS class attribute as CAR parameters
Optional
Enabling the trap function for RADIUS
Optional
Enabling the RADIUS client service
Optional
Setting the DSCP value for RADIUS packets
Optional
Displaying and maintaining RADIUS
Optional
Creating a RADIUS scheme
Before performing other RADIUS configurations, follow these steps to create a RADIUS scheme and enter
RADIUS scheme view:
21
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a RADIUS scheme and
enter RADIUS scheme view.
radius scheme
radius-scheme-name
No RADIUS scheme exists by
default.
NOTE:
A RADIUS scheme can be referenced by multiple ISP domains at the same time.
Specifying the RADIUS authentication/authorization servers
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.
In RADIUS, user authorization information is piggybacked in authentication responses sent to RADIUS
clients. There is no separate RADIUS authorization server.
You can enable the server status detection feature. With the feature, the switch periodically sends an
authentication request to check whether or not the target RADIUS authentication/authorization server is
reachable. If yes, the switch sets the status of the server to active. If not, the switch 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 switch
can trigger 802.1X authentication for users in the critical VLAN immediately on detection of a reachable
RADIUS authentication/authorization server.
Follow these guidelines when you specify RADIUS authentication/authorization servers:
•
The IP addresses of the primary and secondary authentication/authorization servers for a scheme
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.
•
You can specify a RADIUS authentication/authorization server as the primary
authentication/authorization server for one scheme and as the secondary
authentication/authorization server for another scheme at the same time.
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
22
Step
Command
Remarks
• Specify the primary RADIUS
Specify RADIUS
authentication/authorization
servers.
3.
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 ] *
Configure at least one
command.
No
authentication/authorizat
ion server is specified by
default.
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.
By setting the maximum number of real-time accounting attempts for a scheme, you make the switch
disconnect users for whom no accounting response is received before the number of accounting attempts
reaches the limit.
When the switch receives a connection teardown request from a host or a connection teardown
notification 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 switch 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 switch discards the packet.
Follow these guidelines when you specify RADIUS accounting servers:
•
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 accountings, primary or secondary, must use IP
addresses of the same IP version.
•
If you delete an accounting server that is serving users, the switch can no longer send real-time
accounting requests and stop-accounting requests for the users to that server, or buffer the
stop-accounting requests.
•
You can specify a RADIUS accounting server as the primary accounting server for one scheme and
as the secondary accounting server for another scheme at the same time.
•
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
23
Step
Command
Remarks
• Specify the primary RADIUS accounting
3.
Specify RADIUS accounting
servers.
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 ] *
4.
5.
6.
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
Configure at least one
command.
No accounting server is
specified by default.
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 to authenticate packets exchanged
between them and use shared keys for packet authentication and user passwords encryption. They must
use the same key for the same type of communication.
A shared key configured in this task is for all servers of the same type (accounting or authentication) in
the scheme, and has a lower priority than a shared key configured individually for a RADIUS server.
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
3.
Specify a shared key for secure RADIUS
authentication/authorization or
accounting communication.
key { accounting |
authentication [ cipher |
simple ] } key
No shared key is specified by
default.
NOTE:
A shared key configured on the switch must be the same as that configured on the RADIUS server.
Specifying the VPN to which the servers belong
After you specify a VPN for a RADIUS scheme, all the authentication/authorization/accounting servers
specified for the scheme belong to the VPN. However, if you also specify a VPN when specifying a server
for the scheme, the server belongs to the specific VPN.
24
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 of userid@isp-name, where isp-name represents the name of the ISP
domain the user belongs to and is used by the switch to determine which users belong to which ISP
domains. However, some earlier RADIUS servers cannot recognize usernames that contain an ISP
domain name. In this case, the switch must remove the domain name of each username before sending
the username. You can set the username format on the switch for this purpose.
The switch periodically sends accounting updates to RADIUS accounting servers to report the traffic
statistics of online users. For normal and accurate traffic statistics, make sure the unit for data flows and
that for packets on the switch are consistent with those on the RADIUS server.
Follow these guidelines when you set the username format and the traffic statistics units for a RADIUS
scheme:
•
If a RADIUS scheme defines that the username is sent without the ISP domain name, do not apply
the RADIUS scheme to more than one ISP domain. Otherwise, users using the same username but
in different ISP domains are considered the same user.
•
For level switching authentication, the user-name-format keep-original and user-name-format
without-domain commands produce the same results. They make sure usernames sent to the
RADIUS server carry no ISP domain name.
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 }
4.
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 } }*
Optional.
By default, the ISP domain name is
included in a username.
Optional.
The default unit is byte for data
flows and is one-packet for data
packets.
Setting the supported RADIUS server type
The supported RADIUS server type determines the type of the RADIUS protocol that the switch 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 HP.
25
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 switch
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
Set the RADIUS server type.
server-type { extended |
standard }
3.
Optional.
The default RADIUS server type is
standard.
NOTE:
Changing the RADIUS server type restores 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
Because RADIUS uses UDP packets to transfer data, the communication process is not reliable. RADIUS
uses a retransmission mechanism to improve the reliability. If a NAS sends a RADIUS request to a
RADIUS server but receives no response after 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."
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
Optional.
The default setting is 3.
NOTE:
• 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 period, see "Setting timers for
controlling communication with RADIUS servers."
Setting the status of RADIUS servers
By setting the status of RADIUS servers to blocked or active, you can control which servers the switch
communicates with for authentication, authorization, and accounting or turn to when the current servers
26
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. Generally,
the switch chooses servers based on these rules:
•
When the primary server is in active state, the switch communicates with the primary server. If the
primary server fails, the switch changes the server’s status to blocked and starts a quiet timer for the
server, and then turns to a secondary server in active state (a secondary server configured earlier
has a higher priority). If the secondary server is unreachable, the switch 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 switch 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 switch does not check the server again during the
authentication or accounting process. If no server is found reachable during one search process,
the switch considers the authentication or accounting attempt a failure.
•
Once the accounting process of a user starts, the switch 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 switch with
the server soon times out, and the switch looks for a server in active state from scratch by checking
any primary server first and then secondary servers in the order they are configured.
•
When the primary server and secondary servers are all in blocked state, the switch 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 switch 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 switch 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 timers for
controlling communication with HWTACACS servers."
By default, the switch sets the status of all RADIUS servers to active. In cases such as a server failure, you
can change the status of the server to blocked to avoid communication with 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
27
Step
Command
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 RADIUS server
status.
3.
• Set the status of a secondary RADIUS
authentication/authorization server:
state secondary authentication [ ip
ipv4-address | ipv6 ipv6-address ] { active |
block }
Optional.
By default, all servers in
the RADIUS scheme are
in active state.
• Set the status of a secondary RADIUS
accounting server:
state secondary accounting [ ip ipv4-address
| ipv6 ipv6-address ] { active | block }
NOTE:
• The server status set by the state command cannot be saved to the configuration file. After the switch
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.
Usually, the source address of outgoing RADIUS packets can be the IP address of the NAS’s any
interface that can communicate with the RADIUS server. In some special scenarios, however, you must
change the source IP address. 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 VRRP group to which the uplink
belongs.
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 the same VPN. Before
sending a RADIUS packet, a NAS selects a source IP address in the following order:
•
Source IP address specified for the RADIUS scheme.
•
Source IP address specified in system view for the VPN.
•
IP address of the outbound interface specified by the route.
To specify a source IP address for all RADIUS schemes:
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.
28
To specify a source IP address for a specific 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.
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.
Specifying a backup source IP address for outgoing RADIUS packets
In a stateful failover scenario, the active switch authenticates portal users by interacting with the RADIUS
server, and synchronizes its online portal user information to the standby switch through the backup link
established between them. The standby switch only receives and processes synchronization messages
from the active switch. However, when the active switch fails, the RADIUS server does not send RADIUS
packets to the standby switch because it does not know the IP address of the standby switch. To solve this
problem, configure the source IP address for outgoing RADIUS packets on each switch as the backup
source IP address for outgoing RADIUS packets on the other switch. With such configuration, the active
switch sends the source IP address for outgoing RADIUS packets that is configured on the standby switch
to the RADIUS server, so that the RADIUS server can send unsolicited RADIUS packets to the standby
switch.
You can specify a backup 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 the same VPN. Before
sending a RADIUS packet, a NAS selects a backup source IP address in the following order:
•
Backup source IP address specified for the RADIUS scheme.
•
Backup source IP address specified in system view for the VPN.
If no backup source IP address is specified in the views, the NAS sends no backup source IP address to
the server.
To specify a backup source IP address for all RADIUS schemes:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Specify a backup source IP
address for outgoing RADIUS
packets.
radius nas-backup-ip ip-address
[ vpn-instance vpn-instance-name ]
Not specified by default.
To specify a backup source IP address 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.
Specify a backup source IP
address for outgoing RADIUS
packets.
nas-backup-ip ip-address
Not specified by default.
29
NOTE:
The backup source IP address specified for outgoing RADIUS packets takes effect only when stateful
failover is configured, and it must be the source IP address for outgoing RADIUS packets that is configured
on the standby switch.
Setting timers for controlling communication with RADIUS servers
The switch 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
switch starts this timer. If the switch receives no response from the RADIUS server before this timer
expires, it resends the request.
•
Server quiet timer (quiet)—Defines the duration to keep an unreachable server in blocked state. If
a server is not reachable, the switch changes the server’s status to blocked, starts this timer for the
server, and tries to communicate with another server in active state. After this timer expires, the
switch changes the status of the server back to active.
•
Real-time accounting timer (realtime-accounting)—Defines the interval at which the switch sends
real-time accounting packets to the RADIUS accounting server for online users. To implement
real-time accounting, the switch must periodically send real-time accounting packets to the
accounting server for online users.
To set timers for controlling communication with RADIUS servers:
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
response timeout timer.
timer response-timeout seconds
4.
Set the quiet timer for the
servers.
timer quiet minutes
Set the real-time accounting
timer.
timer realtime-accounting minutes
Optional.
5.
The default RADIUS server
response timeout timer is 3
seconds.
Optional.
The quiet timer is 5 minutes.
Optional.
The default real-time accounting
timer is 12 minutes.
•
For a 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 must not 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 period, be sure to take the number of secondary servers into
account. If the retransmission process takes too much time, the client connection in the access
module may be timed out while the switch is trying to find an available server.
30
•
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 may
succeed because the switch has set the state of the unreachable servers to blocked and the time for
finding a reachable server is shortened.
•
Be sure to set the server quiet timer properly. Too short a quiet timer may result in frequent
authentication or accounting failures because the switch has to repeatedly attempt to communicate
with an unreachable server that is in active state.
•
For more information about the maximum number of RADIUS packet transmission attempts, see
"Setting the maximum number of RADIUS request transmission attempts."
Configuring RADIUS accounting-on
The accounting-on feature enables a switch to send accounting-on packets to the RADIUS server after it
reboots, making the server log out users who logged in through the switch before the reboot. Without this
feature, users who were online before the reboot cannot re-log in after the reboot, because the RADIUS
server considers they are already online.
If a switch sends an accounting-on packet to the RADIUS server but receives no response, it resends the
packet to the server at a particular interval for a specified number of times.
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.
NOTE:
The accounting-on feature requires the cooperation of the HP IMC network management system.
Configuring the IP address of the security policy server
The core of the HP EAD solution is integration and cooperation, and the security policy server is the
management and control center. 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 that of the IMC Platform on the NAS.
To configure the IP address of the security policy server for a scheme:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
31
Step
Command
Remarks
2.
Enter RADIUS scheme
view.
radius scheme radius-scheme-name
N/A
3.
Specify a security policy
server.
security-policy-server ip-address
No security policy server is
specified by default.
Configuring interpretation of RADIUS class attribute as CAR parameters
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. Some RADIUS servers use
the class attribute to deliver the assigned committed access rate (CAR) parameters. In this case, the
switch must interpret the attribute as the CAR parameters to implement user-based traffic monitoring and
controlling.
To configure the switch 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.
NOTE:
Whether interpretation of RADIUS class attribute as CAR parameters is supported depends on two factors:
• Whether the switch supports CAR parameters assignment.
• Whether the RADIUS server supports assigning CAR parameters through the class attribute.
Enabling the trap function for RADIUS
With the trap function, a NAS sends a trap message when either of the following events occurs:
•
The status of a RADIUS server changes. If a 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 generally 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:
32
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.
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
N/A
1.
Enter system view.
system-view
2.
Enable the RADIUS client
service.
radius client enable
Optional.
Enabled by default.
Setting the DSCP value for RADIUS packets
Step
Command
Remarks
N/A
1.
Enter system view.
system-view
2.
Set the DSCP value for IPv4
RADIUS packets.
radius dscp dscp-value
Set the DSCP value for IPv6
RADIUS packets.
radius ipv6 dscp dscp-value
3.
Optional.
The default DSCP value is 0.
Optional.
The default DSCP value is 0.
Displaying and maintaining RADIUS
Task
Command
Remarks
Display the configuration information
of RADIUS schemes.
display radius scheme
[ radius-scheme-name ] [ slot
slot-number ] [ | { begin | exclude |
include } regular-expression ]
Available in any view
Display the statistics for RADIUS
packets.
display radius statistics [ 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.
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
Clear RADIUS statistics.
reset radius statistics [ slot slot-number ]
Available in user view
33
Task
Command
Remarks
Clear the buffered stop-accounting
requests for which no responses have
been receive.
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
Configuring HWTACACS schemes
NOTE:
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 the VPN to which the servers belong
Optional
Setting the username format and traffic statistics units
Optional
Specifying a source IP address for outgoing HWTACACS packets
Optional
Setting timers for controlling communication with HWTACACS servers
Optional
Displaying and maintaining HWTACACS
Optional
Creating an HWTACACS scheme
The HWTACACS protocol is configured on a per scheme basis. Before performing other HWTACACS
configurations, follow these steps 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.
NOTE:
• Up to 16 HWTACACS schemes can be configured.
• A scheme can be deleted only when it is not referenced.
34
Specifying the HWTACACS authentication servers
For versions earlier than Release 5206, 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.
For Release 5206 and later versions, you can specify one primary authentication server and up to 16
secondary authentication servers for an HWTACACS scheme. When the primary server is not available,
the device tries to communicate with the secondary servers in the order they are configured. Once a
secondary server in active state is found, the device immediately uses it for HWTACACS authentication.
If redundancy is not required, specify only the primary server.
Follow these guidelines when you specify HWTACACS authentication servers:
•
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.
•
The IP addresses of the primary and secondary authentication servers cannot be the same.
Otherwise, the configuration fails.
•
You can remove an authentication server only when no active TCP connection for sending
authentication packets is using it.
To specify HWTACACS authentication 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
• Specify the primary HWTACACS
3.
Specify HWTACACS
authentication servers.
authentication server:
primary authentication ip-address
[ port-number | key [ cipher | simple ]
key | vpn-instance
vpn-instance-name ] *
• Specify the secondary HWTACACS
authentication server:
secondary authentication ip-address
[ port-number | key [ cipher | simple ]
key | vpn-instance
vpn-instance-name ] *
Configure at least one
command.
No authentication server is
specified by default.
The key [ cipher | simple ] key
option is available in Release
5206 and later versions.
Specifying the HWTACACS authorization servers
For versions earlier than Release 5206, 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.
For Release 5206 and later versions, you can specify one primary authorization server and up to 16
secondary authorization servers for an HWTACACS scheme. When the primary server is not available,
the device tries to communicate with the secondary servers in the order they are configured. Once a
secondary server in active state is found, the device immediately uses it for HWTACACS authorization.
If redundancy is not required, specify only the primary server.
Follow these guidelines when you specify HWTACACS authorization servers:
35
•
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.
•
The IP addresses of the primary and secondary authorization servers cannot be the same.
Otherwise, the configuration fails.
•
You can remove an authorization server only when no active TCP connection for sending
authorization packets is using it.
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
• Specify the primary HWTACACS
3.
Specify HWTACACS
authorization servers.
authorization server:
primary authorization ip-address
[ port-number | key [ cipher |
simple ] key | vpn-instance
vpn-instance-name ] *
• Specify the secondary HWTACACS
authorization server:
secondary authorization ip-address
[ port-number | key [ cipher |
simple ] key | vpn-instance
vpn-instance-name ] *
Configure at least one command.
No authorization server is
specified by default.
The key [ cipher | simple ] key
option is available in Release
5206 and later versions.
Specifying the HWTACACS accounting servers and the relevant parameters
For versions earlier than Release 5206, 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.
For Release 5206 and later versions, you can specify one primary accounting server and up to 16
secondary accounting servers for an HWTACACS scheme. When the primary server is not available, the
device tries to communicate with the secondary servers in the order they are configured. Once a
secondary server in active state is found, the device immediately uses it for HWTACACS accounting.
If redundancy is not required, specify only the primary server
When the switch 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 switch 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 switch discards the packet.
Follow these guidelines when you specify HWTACACS accounting servers:
•
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.
•
The IP addresses of the primary and secondary accounting servers cannot be the same. Otherwise,
the configuration fails.
•
You can remove an accounting server only when no active TCP connection for sending accounting
packets is using it.
36
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
• Specify the primary HWTACACS
3.
Specify HWTACACS
accounting servers.
accounting server:
primary accounting ip-address
[ port-number | key [ cipher |
simple ] key | vpn-instance
vpn-instance-name ] *
• Specify the secondary
HWTACACS accounting server:
secondary accounting ip-address
[ port-number | key [ cipher |
simple ] key | vpn-instance
vpn-instance-name ] *
4.
5.
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.
The key [ cipher | simple ] key
option is available in Release
5206 and later versions.
Optional.
Enabled by default.
Optional.
The default setting is 100.
Specifying the shared keys for secure HWTACACS communication
The HWTACACS client and HWTACACS server use the MD5 algorithm to authenticate packets
exchanged between them and use shared keys for packet authentication and user passwords encryption.
They must use the same key for the same type of communication.
To specify a shared key for secure HWTACACS communication:
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 shared key for
secure HWTACACS
authentication, authorization,
or accounting
communication.
key { accounting | authentication |
authorization } [ cipher | simple ] key
No shared key is specified by
default.
NOTE:
A shared key configured on the switch must be the same as that configured on the HWTACACS server.
37
Specifying the VPN to which the servers belong
After you specify a VPN for an HWTACACS scheme, all the authentication, authorization, and
accounting servers specified for the scheme belong to the VPN. However, if you also specify a VPN when
specifying a server for the scheme, the server belongs to the specific VPN.
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 of userid@isp-name, where isp-name represents the name of the ISP
domain the user belongs to and is used by the switch to determine which users belong to which ISP
domains. However, some HWTACACS servers cannot recognize usernames that contain an ISP domain
name. In this case, the switch must remove the domain name of each username before sending the
username. You can set the username format on the switch for this purpose.
The switch periodically sends accounting updates to HWTACACS accounting servers to report the traffic
statistics of online users. For normal and accurate traffic statistics, make sure the unit for data flows and
that for packets on the switch are consistent with those configured on the HWTACACS servers.
Follow these guidelines when you set the username format and the traffic statistics units for an
HWTACACS scheme:
•
If an HWTACACS server does not support a username that carries the domain name, configure the
switch to remove the domain name before sending the username to the server.
•
For level switching authentication, the user-name-format keep-original and user-name-format
without-domain commands produce the same results. They make sure usernames sent to the
HWTACACS server carry no ISP domain name.
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 for 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.
38
Optional.
By default, the ISP domain name
is included in a username.
Optional.
The default unit is byte for data
flows and is one-packet for data
packets.
Specifying a 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.
Usually, the source address of outgoing HWTACACS packets can be the IP address of the NAS’s any
interface that can communicate with the HWTACACS server. In some special scenarios, however, you
must change the source IP address. If the NAS is configured with the Virtual Router Redundancy Protocol
(VRRP) for stateful failover, the source IP address of HWTACACS packets can be the virtual IP address of
the VRRP group to which the uplink belongs.
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 the
same VPN.
Before sending an HWTACACS packet, a NAS selects a source IP address in the following order:
•
Source IP address specified for the HWTACACS scheme.
•
Source IP address specified in system view for the VPN.
•
IP address of the outbound interface specified by the route.
To specify a source IP address for all HWTACACS schemes:
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 timers for controlling communication with HWTACACS servers
The switch 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 switch starts this timer. If the switch receives no response from the server
before this timer expires, it resends the request.
•
Server quiet timer (quiet)—Defines the duration to keep an unreachable server in blocked state. If
a server is not reachable, the switch changes the server’s status to blocked, starts this timer for the
39
server, and tries to communicate with another server in active state. After this timer expires, the
switch changes the status of the server back to active.
Real-time accounting timer (realtime-accounting)—Defines the interval at which the switch sends
real-time accounting updates to the HWTACACS accounting server for online users. To implement
real-time accounting, the switch must send real-time accounting packets to the accounting server for
online users periodically.
•
To set timers for controlling communication with HWTACACS servers:
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.
4.
Set the quiet timer for the
primary server.
timer quiet minutes
5.
Set the real-time accounting
interval.
timer realtime-accounting minutes
Optional.
timer response-timeout seconds
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.
NOTE:
Consider the performance of the NAS and the HWTACACS server when you set the real-time accounting
interval. A shorter interval requires higher performance. A shorter interval requires higher performance.
Displaying and maintaining HWTACACS
Task
Command
Remarks
Display the configuration information
or statistics of HWTACACS schemes.
display hwtacacs
[ hwtacacs-server-name [ statistics ] ]
[ 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.
display stop-accounting-buffer
hwtacacs-scheme
hwtacacs-scheme-name [ slot
slot-number ] [ | { begin | exclude |
include } regular-expression ]
Available in any view
Clear HWTACACS statistics.
reset hwtacacs statistics { accounting |
all | authentication | authorization }
[ slot slot-number ]
Available in user view
Clear buffered stop-accounting
requests that get no responses.
reset stop-accounting-buffer
hwtacacs-scheme
hwtacacs-scheme-name [ slot
slot-number ]
Available in user view
40
Configuring AAA methods for ISP domains
You configure AAA methods for an ISP domain by referencing configured AAA schemes in ISP domain
view. Each ISP domain has a set of default AAA methods, which are local authentication, local
authorization, and local accounting by default and can be customized. If you do not configure any AAA
methods for an ISP domain, the switch uses the system default AAA methods for authentication,
authorization, and accounting of the users in the domain.
Configuration prerequisites
To use local authentication for users in an ISP domain, configure local user accounts (see "Configuring
local user attributes") on the switch.
To use remote authentication, authorization, and accounting, create the required RADIUS, and
HWTACACS, schemes as described in "Configuring RADIUS schemes," "Configuring HWTACACS
schemes".
Creating an ISP domain
In a networking scenario with multiple ISPs, the switch may connect users of different ISPs, and users of
different ISPs may have different user attributes, such as different username and password structures,
different service types, and different rights. To distinguish the users of different ISPs, configure ISP
domains, and configure different AAA methods and domain attributes for the ISP domains.
The switch can accommodate up to 16 ISP domains, including the system-defined ISP domain system.
You can specify one of the ISP domains as the default domain.
On the switch, each user belongs to an ISP domain. If a user provides no ISP domain name at login, the
switch considers the user belongs to the default ISP domain.
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
4.
Specify the default ISP
domain.
domain default enable
isp-name
Optional.
By default, the default ISP domain is the
system-defined ISP domain system.
NOTE:
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:
41
•
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 switch controls the number of online users in a domain to
ensure the system performance and service reliability.
•
Idle cut—This function enables the switch 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—By using the information defined in this attribute, users can access the
self-service server to manage their own accounts and passwords. A self-service RADIUS server, such
as IMC, is required for the self-service server location function to work.
•
Default authorization user profile—If a user passes authentication but is authorized with no user
profile, the switch 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 a
user profile."
•
DSCP value—The switch sets the specified DSCP value in IP packets from authenticated users in the
ISP domain, which is identified in the login username userid@domain-name. Policy-based routing
routes IP packets to different destinations based on the DSCP value. This attribute applies only to ISP
domains that use the same scheme for Layer 3 portal authentication. For more information about
policy-based routing, see Layer 3—IP Routing Configuration Guide. For more information about
Layer 3 portal authentication, see "Configuring portal authentication."
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
state of active or blocked.
state { active | block }
By default, an ISP domain is in active
state, and users in the domain can
request network services.
4.
Specify the maximum number
of online users in the ISP
domain.
access-limit enable
max-user-number
Optional.
No limit by default.
Optional.
5.
Configure the idle cut function.
idle-cut enable minute [ flow ]
6.
Enable the self-service server
location function and specify
the URL of the self-service
server.
self-service-url enable url-string
7.
Specify the default
authorization user profile.
authorization-attribute
user-profile profile-name
8.
Set a DSCP value for the ISP
domain.
dscp dscp-value
Disabled by default.
This command is effective for only
LAN users and portal users.
Optional.
Disabled by default.
Optional.
By default, an ISP domain has no
default authorization user profile.
Optional.
42
By default, no DSCP value is specified
for an ISP domain.
Configuring AAA 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 does not send authorization information to a supplicant or
trigger accounting.
AAA supports the following authentication methods:
•
No authentication (none)—All users are trusted and no authentication is performed. Generally, do
not use this method.
•
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 is used when the remote
server is not available. No authentication 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.
Before configuring authentication methods, complete the following tasks:
1.
For RADIUS or HWTACACS authentication, configure the RADIUS or HWTACACS scheme to be
referenced first. The local and none authentication methods do not require a scheme.
2.
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, limiting the authentication protocols
that can be used for access.
3.
Determine whether to configure an authentication method for all access types or service types.
Follow these guidelines when you configure AAA authentication methods for an ISP domain:
•
The authentication method specified with the authentication default command is for all types of
users and has a priority lower than that for a specific access type.
•
With an authentication method that references 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 authentication process ignores the information.
•
If you specify the radius-scheme radius-scheme-name local, hwtacacs-scheme
hwtacacs-scheme-name local option when you configure an authentication method, local
authentication is the backup method and is used only when the remote server is not available.
•
If you specify only the local or none keyword in an authentication method configuration command,
the switch has no backup authentication method and performs only local authentication or does not
perform any authentication.
•
If the method for level switching authentication references an HWTACACS scheme, the switch uses
the login username of a user for level switching authentication of the user by default. 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 of $enablevel$, where level specifies the privilege level to which the user wants to switch.
43
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.
To configure AAA 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 LAN users.
authentication lan-access { local | none |
radius-scheme radius-scheme-name [ local |
none ] }
Optional.
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 ] }
Specify the
authentication method
for privilege level
switching.
authentication super { hwtacacs-scheme
hwtacacs-scheme-name | radius-scheme
radius-scheme-name }
5.
6.
7.
The default authentication
method is local for all types of
users.
The default authentication
method is used by default.
The default authentication
method is used by default.
Optional.
The default authentication
method is used by default.
Optional.
The default authentication
method is used by default.
Configuring AAA 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 only the rights of Level 0 (visiting).
•
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, which is used when the remote server is not available.
44
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, limiting the authorization protocols
that can be used for access.
3.
Determine whether to configure an authorization method for all access types or service types.
Follow these guidelines when you configure AAA authorization methods for an ISP domain:
•
The authorization method specified with the authorization default command is for all types of users
and has a priority lower than that for a specific access type.
•
If you configure an authentication method and an authorization method that use RADIUS schemes
for an ISP domain, the RADIUS scheme for authorization must be the same as that for authentication.
If the RADIUS authorization configuration is invalid or RADIUS authorization fails, the RADIUS
authentication also fails. Whenever RADIUS authorization fails, an error message is sent to the NAS,
indicating that the server is not responding.
•
If you specify the radius-scheme radius-scheme-name local, hwtacacs-scheme
hwtacacs-scheme-name [ local | none ] option when you configure an authorization method, local
authorization or no authorization is the backup method and is used only when the remote server is
not available.
•
If you specify only the local or none keyword in an authorization method configuration command,
the switch has no backup authorization method and performs only local authorization or does not
perform any authorization.
To configure AAA 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 LAN users.
authorization lan-access { local | none |
radius-scheme radius-scheme-name [ local |
none ] }
Optional.
6.
Specify the authorization
method for login users.
authorization login { hwtacacs-scheme
hwtacacs-scheme-name [ local ] | local |
none | radius-scheme radius-scheme-name
[ local ] }
Optional.
7.
Specify the authorization
method for portal users.
authorization portal { local | none |
radius-scheme radius-scheme-name
[ local ] }
Optional.
45
The 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.
The default authorization
method is used by default.
The default authorization
method is used by default.
Configuring AAA 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 system 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. It does not provide statistics for
charging. 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 is used when
the remote server is not available.
By default, an ISP domain uses the local accounting method.
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, limiting the accounting protocols that
can be used for access.
3.
Determine whether to configure an accounting method for all access types or service types.
Follow these guidelines when you configure AAA accounting methods for an ISP domain:
•
If you configure the accounting optional command, the limit on the number of local user
connections is not effective.
•
The accounting method specified with the accounting default command is for all types of users and
has a priority lower than that for a specific access type.
•
If you specify the radius-scheme radius-scheme-name local or hwtacacs-scheme
hwtacacs-scheme-name local option when you configure an accounting method, local accounting
is the backup method and is used only when the remote server is not available.
•
If you specify only the local or none keyword in an accounting method configuration command, the
switch has no backup accounting method and performs only local accounting or does not perform
any accounting.
•
Accounting is not supported for FTP services.
To configure AAA 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
46
Step
Command
Remarks
Optional.
Disabled by default.
With the accounting optional
feature, a switch 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 ] }
Optional.
5.
Specify the command
accounting method.
accounting command
hwtacacs-scheme
hwtacacs-scheme-name
Optional.
6.
Specify the accounting
method for LAN users.
accounting lan-access { local | none |
radius-scheme radius-scheme-name
[ local | none ] }
Optional.
7.
Specify the accounting
method for login users.
accounting login { hwtacacs-scheme
hwtacacs-scheme-name [ local ] | local
| none | radius-scheme
radius-scheme-name [ local ] }
Optional.
8.
Specify the accounting
method for portal users.
accounting portal { local | none |
radius-scheme radius-scheme-name
[ local ] }
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.
The default accounting method
is used by default.
The default accounting method
is used by default.
Tearing down user connections
Step
1.
2.
Command
Remarks
Enter system view.
system-view
N/A
Tear down AAA user
connections.
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 | vlan vlan-id } [ slot slot-number ]
The command applies
only to LAN and
portal 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 switch. Then,
when a user gets online, the switch 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:
47
Step
Command
Remarks
system-view
N/A
1.
Enter system view.
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
authentication."
3.
Configure a NAS ID-VLAN
binding.
nas-id nas-identifier bind vlan
vlan-id
By default, no NAS ID-VLAN
binding exists.
Specifying the device ID used in stateful failover
mode
Two switches working in stateful failover mode for portal services are uniquely identified by their device
IDs. A device ID can only be 1 or 2. For more information about the stateful failover mode for portal
services, see "Configuring portal authentication."
Follow these guidelines when you specify the device ID used in stateful failover mode:
•
Configuring or changing the device ID of a switch logs out all online users of the switch.
•
HP recommends to save the configuration and reboot the switch after configuring or changing the
device ID.
•
The device ID is the symbol for stateful failover mode. Do not configure any device ID for a switch
working in stand-alone mode.
To specify the device ID used in stateful failover mode:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Specify the device ID used
in stateful failover mode.
nas device-id device-id
By default, a switch works in standalone
mode and has no device ID.
Configuring a switch as a RADIUS server
RADIUS server functions configuration task list
Task
Remarks
Configuring a RADIUS user
Required
Specifying a RADIUS client
Required
Configuring a RADIUS user
This task is to create a RADIUS user and configure a set of attributes for the user on a switch that serves
as the RADIUS server. The user attributes include the password, authorization attribute, expiration time,
48
and user description. After completing this task, the specified RADIUS user can use the username and
password for RADIUS authentication on the switch.
You can use the authorization-attribute command to specify an authorization ACL and authorized VLAN,
which is assigned by the RADIUS server to the RADIUS client (the NAS) after the RADIUS user passes
authentication. The NAS then uses the assigned ACL and VLAN to control user access. If the assigned
ACL does not exist on the NAS, ACL assignment fails and the NAS forcibly logs out the RADIUS user. If
the assigned VLAN does not exist on the NAS, the NAS creates the VLAN and adds the RADIUS user or
the access port to the VLAN.
To configure a RADIUS user:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a RADIUS user and
enter RADIUS server user
view.
radius-server user user-name
No RADIUS user exists by default.
3.
Configure a password for the
RADIUS user.
password [ cipher | simple ]
password
4.
Configure the authorization
attribute for the RADIUS user.
authorization-attribute { acl
acl-number | vlan vlan-id } *
Optional.
By default, no password is
specified.
Optional.
Not configured by default.
Optional.
5.
Set the expiration time for the
RADIUS user.
expiration-date time
6.
Configure a description for
the RADIUS user.
description text
By default, no expiration time is
set, and the system does not check
users’ expiration time.
Optional.
Not configured by default.
Specifying a RADIUS client
This task is to specify the IP address of a client to be managed by the RADIUS server and configure the
shared key. The RADIUS server processes only the RADIUS packets sent from the specified clients.
To specify a RADIUS client
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Specify a RADIUS client.
radius-server client-ip ip-address [ key
[ cipher | simple ] string ]
No RADIUS client is
specified by default.
NOTE:
• The IP address of a RADIUS client specified on the RADIUS server must be consistent with the source IP
address of outgoing RADIUS packets configured on the RADIUS client.
• The shared key configured on the RADIUS server must be consistent with that configured on the RADIUS
client.
49
Displaying and maintaining AAA
Task
Command
Remarks
Display the configuration
information of ISP domains.
display domain [ isp-name ] [ | { begin |
exclude | include } regular-expression ]
Available in any view
Display information about user
connections.
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 | vlan vlan-id ] [ slot
slot-number ] [ | { begin | exclude | include }
regular-expression ]
Available in any view
AAA configuration examples
Unless otherwise noted, devices in the configuration examples are operating in non-FIPS mode.
AAA for Telnet users by an HWTACACS server
Network requirements
As shown in Figure 11, configure the switch to use the HWTACACS server to provide authentication,
authorization, and accounting services for Telnet users.
Set the shared keys for secure communication with the HWTACACS server to expert. Configure the
switch to remove the domain name from a username before sending the username to the HWTACACS
server.
Figure 11 Network diagram
Configuration procedure
1.
Configure the switch:
# Assign IP addresses to the interfaces. (Details not shown.)
# Enable the Telnet server on the switch.
<Switch> system-view
[Switch] telnet server enable
50
# Configure the switch to use AAA for Telnet users.
[Switch] user-interface vty 0 4
[Switch-ui-vty0-4] authentication-mode scheme
[Switch-ui-vty0-4] quit
# Create HWTACACS scheme hwtac.
[Switch] hwtacacs scheme hwtac
# Specify the primary authentication server.
[Switch-hwtacacs-hwtac] primary authentication 10.1.1.1 49
# Specify the primary authorization server.
[Switch-hwtacacs-hwtac] primary authorization 10.1.1.1 49
# Specify the primary accounting server.
[Switch-hwtacacs-hwtac] primary accounting 10.1.1.1 49
# Set the shared keys for secure authentication, authorization, and accounting communication to
expert.
[Switch-hwtacacs-hwtac] key authentication simple expert
[Switch-hwtacacs-hwtac] key authorization simple expert
[Switch-hwtacacs-hwtac] key accounting simple expert
# Configure the scheme to remove the domain name from a username before sending the
username to the HWTACACS server.
[Switch-hwtacacs-hwtac] user-name-format without-domain
[Switch-hwtacacs-hwtac] quit
# Configure the AAA methods for the domain.
[Switch] domain bbb
[Switch-isp-bbb] authentication login hwtacacs-scheme hwtac
[Switch-isp-bbb] authorization login hwtacacs-scheme hwtac
[Switch-isp-bbb] accounting login hwtacacs-scheme hwtac
[Switch-isp-bbb] quit
2.
Verify the configuration:
Telnet to the switch as a user and enter the correct username and password. You pass
authentication and log in to the switch. Issuing the display connection command on the switch, you
can see information about the user connection.
AAA for Telnet users by separate servers
Network requirements
As shown in Figure 12, configure the switch to provide local authentication, HWTACACS authorization,
and RADIUS accounting services for Telnet users. Set the shared keys for secure communication with the
HWTACACS server and the RADIUS server to expert. Configure the switch to remove the domain name
from a username before sending the username to the servers.
51
Figure 12 Network diagram
Configuration procedure
1.
Configure the switch:
# Assign IP addresses to interfaces. (Details not shown.)
# Enable the Telnet server on the switch.
<Switch> system-view
[Switch] telnet server enable
# Configure the switch to use AAA for Telnet users.
[Switch] user-interface vty 0 4
[Switch-ui-vty0-4] authentication-mode scheme
[Switch-ui-vty0-4] quit
# Configure the HWTACACS scheme.
[Switch] hwtacacs scheme hwtac
[Switch-hwtacacs-hwtac] primary authorization 10.1.1.2 49
[Switch-hwtacacs-hwtac] key authorization expert
[Switch-hwtacacs-hwtac] user-name-format without-domain
[Switch-hwtacacs-hwtac] quit
# Configure the RADIUS scheme.
[Switch] radius scheme rd
[Switch-radius-rd] primary accounting 10.1.1.1 1813
[Switch-radius-rd] key accounting expert
[Switch-radius-rd] server-type extended
[Switch-radius-rd] user-name-format without-domain
[Switch-radius-rd] quit
# Create a local user named hello.
[Switch] local-user hello
[Switch-luser-hello] service-type telnet
[Switch-luser-hello] password simple hello
[Switch-luser-hello] quit
# Configure the AAA methods for the ISP domain.
[Switch] domain bbb
[Switch-isp-bbb] authentication login local
[Switch-isp-bbb] authorization login hwtacacs-scheme hwtac
[Switch-isp-bbb] accounting login radius-scheme rd
[Switch-isp-bbb] quit
52
2.
Verify the configuration:
Telnet to the switch as a user and enter the username hello@bbb and the correct password. You
pass authentication and log in to the switch. Issuing the display connection command on the switch,
you can see information about the user connection.
Authentication/authorization for SSH/Telnet users by a
RADIUS server
The configuration of authentication and authorization for SSH users is similar to that for Telnet users. The
following example describes the configuration for SSH users.
Network requirements
As shown in Figure 13, configure the switch to use the RADIUS server for SSH user authentication and
authorization, and to include the domain name in a username sent to the RADIUS server.
Configure IMC to act as the RADIUS server, add an account with the username hello@bbb on the
RADIUS server, and configure the RADIUS server to assign the privilege level of 3 to the user after the
user passes authentication.
Set the shared keys for secure RADIUS communication to expert.
Figure 13 Network diagram
Configuring the RADIUS server
This example assumes that the RADIUS server runs on IMC PLAT 5.0 (E0101) and IMC UAM 5.0 (E0101).
1.
Add the switch to IMC as an access device:
a. Log in to IMC, click the Service tab, and select User Access Manager > Access Device from the
navigation tree.
b. Click Add.
c. Configure the following parameters:
Set the shared key for secure authentication and accounting communication to expert.
Specify the ports for authentication and accounting as 1812 and 1813, respectively.
Select Device Management Service as the service type.
Select HP(A-Series) as the access device type.
Select the switch from the device list or manually add the switch with the IP address of
10.1.1.2.
d. Click OK.
53
NOTE:
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 switch, which is the IP address of the outbound interface by default, or otherwise the
IP address specified with the nas-ip or radius nas-ip command on the switch.
Figure 14 Adding the switch to IMC as an access device
2.
Add a user for device management:
a. Click the User tab, and select Device Management User from the navigation tree.
b. Click Add.
c. Configure the following parameters:
Enter hello@bbb as the username and set the password.
Select SSH as the service type.
Set the EXEC privilege level to 3. This value identifies the privilege level of the SSH user after
login and defaults to 0.
Specify the IP address range of the hosts to be managed as 10.1.1.0 through 10.1.1.255.
d. Click OK.
54
Figure 15 Adding an account for device management
Configuring the switch
# Configure the IP address of VLAN interface 2, through which the SSH user accesses the switch.
<Switch> system-view
[Switch] interface vlan-interface 2
[Switch-Vlan-interface2] ip address 192.168.1.70 255.255.255.0
[Switch-Vlan-interface2] quit
# Configure the IP address of VLAN-interface 3, through which the switch access the server.
[Switch] interface vlan-interface 3
[Switch-Vlan-interface3] ip address 10.1.1.2 255.255.255.0
[Switch-Vlan-interface3] quit
# Generate RSA and DSA key pairs and enable the SSH server.
[Switch] public-key local create rsa
[Switch] public-key local create dsa
[Switch] ssh server enable
# Configure the switch to use AAA for SSH users.
[Switch] user-interface vty 0 4
[Switch-ui-vty0-4] authentication-mode scheme
# Configure the user interfaces to support SSH.
[Switch-ui-vty0-4] protocol inbound ssh
[Switch-ui-vty0-4] quit
55
# Create RADIUS scheme rad.
[Switch] radius scheme rad
# Specify the primary authentication server.
[Switch-radius-rad] primary authentication 10.1.1.1 1812
# Set the shared key for secure authentication communication to expert.
[Switch-radius-rad] key authentication expert
# Configure the scheme to include the domain names in usernames to be sent to the RADIUS server.
[Switch-radius-rad] user-name-format with-domain
# Specify the service type for the RADIUS server, which must be extended when the RADIUS server runs
on IMC.
[Switch-radius-rad] server-type extended
[Switch-radius-rad] quit
# Configure the AAA methods for the domain.
[Switch] domain bbb
[Switch-isp-bbb] authentication login radius-scheme rad
[Switch-isp-bbb] authorization login radius-scheme rad
[Switch-isp-bbb] quit
Verifying the configuration
After you complete the configuration, the SSH user should be able to use the configured account to
access the user interface of the switch and can access the demands of level 0 through level 3. .
# Use the display connection command to view the connection information on the switch.
[Switch] display connection
Index=1
,Username=hello@bbb
IP=192.168.1.58
IPv6=N/A
Total 1 connection(s) matched.
Level switching authentication for Telnet users by an
HWTACACS server
Network requirements
As shown in Figure 16, configure the switch to:
•
Use local authentication for the Telnet user and assign the privilege level of 0 to the user after the
user passes authentication.
•
Use the HWTACACS server for level switching authentication of the Telnet user, and use local
authentication as the backup.
56
Figure 16 Network diagram
Configuration considerations
1.
2.
Configure the switch 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 user privilege level.
On the switch, configure the authentication method for user privilege level switching:
{
{
{
3.
Specify to use HWTACACS authentication and, if HWTACACS authentication is not available,
use local authentication for user level switching authentication.
Configure HWTACACS scheme hwtac and assign an IP address to the HWTACACS server. Set
the shared keys for message exchange and specify that usernames sent to the HWTACACS
server carry no domain name. Configure the domain to use the HWTACACS scheme hwtac for
user privilege level switching authentication.
Configure the password for local privilege level switching authentication.
On the HWTACACS server, add the username and password for user privilege level switching
authentication.
Configuration procedure
1.
Configure the switch:
# Configure the IP address of VLAN-interface 2, through which the Telnet user accesses the switch.
<Switch> system-view
[Switch] interface vlan-interface 2
[Switch-Vlan-interface2] ip address 192.168.1.70 255.255.255.0
[Switch-Vlan-interface2] quit
# Configure the IP address of VLAN-interface 3, through which the switch communicates with the
server.
[Switch] interface vlan-interface 3
[Switch-Vlan-interface3] ip address 10.1.1.2 255.255.255.0
[Switch-Vlan-interface3] quit
# Enable the switch to provide Telnet service.
[Switch] telnet server enable
# Configure the switch to use AAA for Telnet users.
[Switch] user-interface vty 0 4
[Switch-ui-vty0-4] authentication-mode scheme
[Switch-ui-vty0-4] quit
57
# Use HWTACACS authentication for user level switching authentication and, if HWTACACS
authentication is not available, use local authentication.
[Switch] super authentication-mode scheme local
# Create an HWTACACS scheme named hwtac.
[Switch] hwtacacs scheme hwtac
# Specify the IP address for the primary authentication server as 10.1.1.1 and the port for
authentication as 49.
[Switch-hwtacacs-hwtac] primary authentication 10.1.1.1 49
# Set the shared key for secure authentication communication to expert.
[Switch-hwtacacs-hwtac] key authentication simple expert
# Configure the scheme to remove the domain name from a username before sending the
username to the HWTACACS server.
[Switch-hwtacacs-hwtac] user-name-format without-domain
[Switch-hwtacacs-hwtac] quit
# Create ISP domain bbb.
[Switch] domain bbb
# Configure the ISP domain to use local authentication for Telnet users.
[Switch-isp-bbb] authentication login local
# Configure to use HWTACACS scheme hwtac for privilege level switching authentication.
[Switch-isp-bbb] authentication super hwtacacs-scheme hwtac
[Switch-isp-bbb] quit
# Create a local Telnet user named test.
[Switch] local-user test
[Switch-luser-test] service-type telnet
[Switch-luser-test] password simple aabbcc
# Configure the user level of the Telnet user to 0 after user login.
[Switch-luser-test] authorization-attribute level 0
[Switch-luser-test] quit
# Configure the password for local privilege level switching authentication to 654321.
[Switch] super password simple 654321
[Switch] quit
2.
Configure the HWTACACS server:
NOTE:
The HWTACACS server in this example runs ACSv4.0.
Add a user named test on the HWTACACS server and configure advanced attributes for the user
as shown in Figure 17:
{
{
Select Max Privilege for any AAA Client and set the privilege level to level 3. This setting
requires the user to enter the password when switching to level 1, level 2, or level 3.
Select Use separate password and specify the password as enabpass.
58
Figure 17 Configuring advanced attributes for the Telnet user
3.
Verify the configuration:
After you complete the configuration, the Telnet user should be able to telnet to the switch and use
username test@bbb and password aabbcc to enter the user interface of the switch, and access all
level 0 commands.
<Switch> telnet 192.168.1.70
Trying 192.168.1.70 ...
Press CTRL+K to abort
Connected to 192.168.1.70 ...
******************************************************************************
* Copyright (c) 2010-2014 Hewlett-Packard Development Company, L.P.
*
* Without the owner's prior written consent,
*
* no decompiling or reverse-engineering shall be allowed.
*
******************************************************************************
Login authentication
Username:test@bbb
Password:
<Switch> ?
User view commands:
display
Display current system information
ping
Ping function
quit
Exit from current command view
ssh2
Establish a secure shell client connection
59
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 enabpass
as prompted.
<Switch> 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 HWTACACS server is not available, the Telnet user needs to enter password 654321 as
prompted for local authentication.
<Switch> super 3
Password: Å Enter the password for HWTACACS privilege level switch 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 switch 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
RADIUS authentication and authorization for Telnet users by a
switch
Network requirements
As shown in Figure 18, configure Switch B to act as a RADIUS server to provide authentication and
authorization for the Telnet user on port 1645.
Configure Switch A to use the RADIUS server for Telnet user authentication and authorization, and to
remove the domain name in a username sent to the server.
Set the shared keys for secure communication between the NAS and the RADIUS server to abc.
Figure 18 Network diagram
NAS
Telnet user
192.168.1.2
RADIUS server
Vlan-int2
10.1.1.1/24
Vlan-int3
192.168.1.1/24
Vlan-int2
10.1.1.2/24
Switch A
Switch B
Configuration procedure
1.
Assign an IP address to each interface as shown in Figure 18. (Details not shown.)
2.
Configure the NAS:
# Enable the Telnet server on Switch A.
<SwitchA> system-view
[SwitchA] telnet server enable
# Configure Switch A to use AAA for Telnet users.
[SwitchA] user-interface vty 0 4
60
[SwitchA-ui-vty0-4] authentication-mode scheme
[SwitchA-ui-vty0-4] quit
# Create RADIUS scheme rad.
[SwitchA] radius scheme rad
# Specify the IP address for the primary authentication server as 10.1.1.2, the port for
authentication as 1645, and the shared key for secure authentication communication as abc.
[SwitchA-radius-rad] primary authentication 10.1.1.2 1645 key abc
# Configure the scheme to remove the domain name from a username before sending the
username to the RADIUS server.
[SwitchA-radius-rad] user-name-format without-domain
# Set the source IP address for RADIUS packets as 10.1.1.1.
[SwitchA-radius-rad] nas-ip 10.1.1.1
[SwitchA-radius-rad] quit
# Create ISP domain bbb.
[SwitchA] domain bbb
# Specify the authentication method for Telnet users as rad.
[SwitchA-isp-bbb] authentication login radius-scheme rad
# Specify the authorization method for Telnet users as rad.
[SwitchA-isp-bbb] authorization login radius-scheme rad
# Specify the accounting method for Telnet users as none.
[SwitchA-isp-bbb] accounting login none
# Configure the RADIUS server type as standard. When a switch is configured to serve as a
RADIUS server, the server type must be set to standard.
[SwitchA-isp-bbb] server-type standard
[SwitchA-isp-bbb] quit
# Configure bbb as the default ISP domain. Then, if a user enters a username without any ISP
domain at login, the authentication and accounting methods of the default domain is used for the
user.
[SwitchA] domain default enable bbb
3.
Configure the RADIUS server:
# Create RADIUS user aaa and enter its view.
<SwitchB> system-view
[SwitchB] radius-server user aaa
# Configure plaintext password aabbcc for user aaa.
[SwitchB-rdsuser-aaa] password simple aabbcc
[SwitchB-rdsuser-aaa] quit
# Specify the IP address of the RADIUS client as 10.1.1.1 and the plaintext shared key as abc.
[SwitchB] radius-server client-ip 10.1.1.1 key simple abc
4.
Verify the configuration:
After entering username aaa@bbb or aaa and password aabbcc, user aaa can telnet to Switch A.
Use the display connection command to view the connection information on Switch A.
<SwitchA> display connection
Index=1
,Username=aaa@bbb
IP=192.168.1.2
61
IPv6=N/A
Total 1 connection(s) matched.
Troubleshooting AAA
Troubleshooting RADIUS
Symptom 1
User authentication/authorization always fails.
Analysis
1.
A communication failure exists between the NAS and the RADIUS server.
2.
The username is not in the format of userid@isp-name or the ISP domain for the user authentication
is not correctly configured on the NAS.
3.
The user is not configured on the RADIUS server.
4.
The password entered by the user is incorrect.
5.
The RADIUS server and the NAS are configured with different shared key.
Solution
Check that:
1.
The NAS and the RADIUS server can ping each other.
2.
The username is in the userid@isp-name format and the ISP domain for the user authentication is
correctly configured on the NAS.
3.
The user is configured on the RADIUS server.
4.
The correct password is entered.
5.
The same shared key is configured on both the RADIUS server and the NAS.
Symptom 2
RADIUS packets cannot reach the RADIUS server.
Analysis
1.
The NAS and the RADIUS server cannot communicate with each other.
2.
The NAS is not configured with the IP address of the RADIUS server.
3.
The UDP ports for authentication/authorization and accounting are not correct.
4.
The port numbers of the RADIUS server for authentication, authorization and accounting are being
used by other applications.
Solution
Check that:
1.
The communication links between the NAS and the RADIUS server work well at both physical and
link layers.
2.
The IP address of the RADIUS server is correctly configured on the NAS.
3.
UDP ports for authentication/authorization/accounting configured on the NAS are the same as
those configured on the RADIUS server.
62
4.
The port numbers of the RADIUS server for authentication, authorization and accounting are
available.
Symptom 3
A user is authenticated and authorized, but accounting for the user is not normal.
Analysis
1.
The accounting port number is not correct.
2.
Configuration of the authentication/authorization server and the accounting server are not correct
on the NAS. For example, one server is configured on the NAS to provide all the services of
authentication/authorization and accounting, but in fact the services are provided by different
servers.
Solution
Check that:
1.
The accounting port number is correctly set.
2.
The authentication/authorization server and the accounting server are correctly configured on the
NAS.
Troubleshooting HWTACACS
Similar to RADIUS troubleshooting. See "Troubleshooting RADIUS."
63
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 19 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. It
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 20. 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—Is always open to receive and transmit EAPOL frames.
64
Figure 20 Authorization state of a controlled port
Authenticator system 1
Controlled port
Authenticator system 2
Uncontrolled port
Controlled port
Uncontrolled port
Port authorized
Port unauthorized
LAN
LAN
In the 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 HP 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 21 shows the EAP packet format.
65
Figure 21 EAP packet format
•
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 EAP packet 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
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 22 shows the EAPOL packet format.
Figure 22 EAPOL packet format
•
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 5 lists the types of EAPOL packets supported by HP
implementation of 802.1X.
Table 5 EAPOL packet types
•
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.
66
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 23. 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.
Figure 23 EAP-Message attribute format
7
0
Type=79
15
N
Length
Value
EAP packets
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 than the Message-Authenticator attribute value. The Message-Authenticator prevents EAP
authentication packets from being tampered with during EAP authentication.
Figure 24 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, you must use an 802.1X client, the HP
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, the 802.1X client available with Windows XP for
example, cannot send EAPOL-Start packets.
The access device supports the following modes:
67
•
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 authentication has two approaches: 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
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 25.
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 execute the dot1x authentication-method eap command to
enable EAP relay.
Figure 25 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 26.
Figure 26 EAP termination
A comparison of EAP relay and EAP termination
Packet exchange method
Benefits
Limitations
• Supports various EAP
The RADIUS server must support the
EAP-Message and
Message-Authenticator attributes,
and the EAP authentication method
used by the client.
authentication methods.
EAP relay
• The configuration and processing is
simple on the network access
device
68
Packet exchange method
Benefits
Limitations
• Supports only MD5-Challenge
EAP termination
Works with any RADIUS server that
supports PAP or CHAP authentication.
EAP authentication and the
"username + password" EAP
authentication initiated by an HP
iNode 802.1X client.
• The processing is complex on the
network access device.
EAP relay
Figure 27 shows the basic 802.1X authentication procedure in EAP relay mode, assuming that EAP-MD5
is used.
Figure 27 802.1X authentication procedure in EAP relay mode
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.
69
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.
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.
Then
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 28 shows the basic 802.1X authentication procedure in EAP termination mode, assuming that
CHAP authentication is used.
70
Figure 28 802.1X authentication procedure in EAP termination mode
In EAP termination mode, it is 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 MD5
challenge together with the username and encrypted password in a standard RADIUS packet to the
RADIUS server.
71
Configuring 802.1X
This chapter describes how to configure 802.1X on an HP 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. It is described in "Port
security configuration."
HP implementation of 802.1X
Access control methods
HP 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
The device can work with a RADIUS server to assign VLANs to 802.1X users. The device accepts
untagged VLANs that are assigned through the RFC 3580-compliant Tunnel attributes and tagged
VLANs that are assigned through the RFC 4675-compliant Egress-VLANID or Egress-VLAN-Name
attribute.
NOTE:
• Access ports do not support RFC 4675-compliant assignment of VLANs.
• Trunk and hybrid ports support RFC 4675-compliant assignment of only tagged VLANs.
Table 6 and Table 7 describes how the device handles VLANs assigned through a RADIUS server
Table 6 VLAN assignment in port-based access control mode
Link type
VLAN assignment
Sets the VLAN ID assigned through the Tunnel attributes as the PVID on the port.
Access port
Trunk/hybrid port
All subsequent users can access the network, regardless of their VLANs.
When the authenticated user logs off, the previous PVID restores, and all users
attached to the port cannot access the network.
• Sets the VLAN ID assigned through the Tunnel attributes as the PVID on the port.
• Assigns the port to the VLANs assigned through the Egress-VLANID or
Egress-VLAN-Name attribute, and sets the VLANs as tagged VLANs.
72
Table 7 VLAN assignment in MAC-based access control mode
Link type
VLAN assignment
Sets the VLAN ID assigned through the Tunnel attributes to the first authenticated
user as the PVID on the port.
Access
Trunk
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 that are attached to an access port.
• Sets the VLAN assigned through the Tunnel attributes as the PVID on the port.
• Assigns the port to VLANs assigned through the Egress-VLANID or
Egress-VLAN-Name attribute.
• If MAC-based VLAN is disabled, the VLAN assignment actions are the same as
on a trunk port.
• If MAC-based VLAN is enabled, the device does the following actions:
{
Hybrid
{
Maps the user's MAC address to the VLAN assigned through the Tunnel
attributes, and sets the VLAN as an untagged VLAN.
Maps the user's MAC address to the VLAN assigned through the
Egress-VLANID or Egress-VLAN-Name attribute, and sets the VLAN as a
tagged VLAN.
When a user logs off, the MAC-to-VLAN mapping for the user is removed.
If MAC-based VLAN is enabled, the device does not replace the PVID on the port
with a server assigned VLAN, regardless of whether the assignment is through
Tunnel attributes or the Egress-VLANID attribute.
On a periodic online user re-authentication enabled port, if a user has been online before you enable the
MAC-based VLAN function, the 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.
VLAN group assignment
Use VLAN group assignment to balance users across several VLANs.
VLAN group assignment allows the authentication server to assign a VLAN group to the access device
for an 802.1X user. From this VLAN group, the device picks a VLAN for the 802.1X user in the following
order:
1.
Selects the VLAN that has the fewest number of online 802.1X users.
If a port performs port-based access control, all 802.1X users attached to the port are counted as
one user.
2.
If two VLANs have the same number of 802.1X users, the device selects the VLAN with the lower
ID.
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. After a user in the guest VLAN passes 802.1X
authentication, it is removed from the guest VLAN and can access authorized network resources. The
way that the network access device handles VLANs on the port differs by 802.1X access control mode.
73
For more information about VLAN configuration and MAC-based VLAN, see Layer 2—LAN Switching
Configuration Guide.
1.
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.
• Assigns the VLAN specified for the user to the port as the PVID, and
A user in the 802.1X guest
VLAN passes 802.1X
authentication
2.
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 PVID remains
unchanged.
On a port that performs MAC-based access control
To use the 802.1X guest VLAN function on a port that performs MAC-based access control, make sure
that the port is a hybrid port, and enable MAC-based VLAN on the port.
Authentication status
VLAN manipulation
A user has not passed 802.1X
authentication yet
Creates a mapping between the MAC address of the user and the 802.1X
guest VLAN. The user can access resources in the guest VLAN.
A user in the 802.1X guest
VLAN fails 802.1X
authentication
A user in the 802.1X guest
VLAN passes 802.1X
authentication
If an 802.1X Auth-Fail VLAN is available, re-maps the MAC address of the
user to the Auth-Fail VLAN. The user can access only resources in the Auth-Fail
VLAN.
If no 802.1X Auth-Fail VLAN is configured, the user is still in the 802.1X guest
VLAN.
Re-maps the MAC address of the user to the VLAN specified for the user.
If the authentication server assigns no VLAN, re-maps the MAC address of the
user to the initial PVID on the port.
NOTE:
The network device assigns a hybrid port to an 802.1X guest VLAN as an untagged member.
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.
74
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.
For more information about VLAN configuration and MAC-based VLAN, see Layer 2—LAN Switching
Configuration Guide.
1.
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.
• 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.
A user passes 802.1X authentication
• 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.
2.
On a port that performs MAC-based access control
To perform the 802.1X Auth-Fail 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.
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.
NOTE:
The network device assigns a hybrid port to an 802.1X Auth-Fail VLAN as an untagged member.
75
Critical VLAN
You 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 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."
For more information about VLAN configuration and MAC-based VLAN, see Layer 2—LAN Switching
Configuration Guide.
The way that the network access device handles VLANs on an 802.1X-enabled port differs by 802.1X
access control mode.
1.
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.
• 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.
A user in the critical VLAN passes 802.1X
authentication.
• If the authentication server assigns no VLAN, the default or
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.
2.
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.
On a port that performs MAC-based access control
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.
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.
76
Authentication status
VLAN manipulation
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.
A user in the critical 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 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.
NOTE:
The network device assigns a hybrid port to an 802.1X critical VLAN as an untagged member.
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 added to the ISP domain and the server is reachable.
•
A response from a RADIUS authentication server is received.
•
The RADIUS server probing function detects that a RADIUS authentication server is reachable.
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.
77
•
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
Configuring the authentication trigger function
Optional
Specifying a mandatory authentication domain on a port
Optional
Configuring the quiet timer
Optional
Enabling the periodic online user re-authentication function
Optional
Configuring a port to send EAPOL frames untagged
Optional
Setting the maximum number of 802.1X authentication attempts for MAC
authentication users
Optional
Configuring a VLAN group
Optional
Configuring an 802.1X guest VLAN
Optional
Configuring an 802.1X Auth-Fail VLAN
Optional
Configuring an 802.1X critical VLAN
Optional
Specifying supported domain name delimiters
Optional
Enabling 802.1X
Configuration guidelines
•
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.
•
Do not use the BPDU drop feature on an 802.1X-enabled port. The BPDU drop feature discards
802.1X packets arrived on the port.
78
Configuration procedure
To enable 802.1X on a port:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable 802.1X globally.
dot1x
By default, 802.1X is
disabled globally.
• In system view:
dot1x interface interface-list
Enable 802.1X on a
port.
3.
Use either method.
• In Ethernet interface view:
By default, 802.1X is
disabled on a port.
a. interface interface-type
interface-number
b. dot1x
Enabling EAP relay or EAP termination
When you configure 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 HP 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:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
Optional.
2.
Configure EAP relay or
EAP termination.
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.
79
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 Ethernet interface view, or for multiple ports in system view.
If different authorization state is set for a port in system view and Ethernet 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
• In system view:
2.
Set the port
authorization state.
dot1x port-control { authorized-force | auto
| unauthorized-force } [ interface
interface-list ]
• In Ethernet interface view:
a. interface interface-type
interface-number
Optional.
Use either method.
By default, auto applies.
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 Ethernet interface view, or for multiple ports in
system view. If different access control methods are specified for a port in system view and Ethernet
interface view, the one specified later takes effect.
To use both 802.1X and portal authentication on a port, you must specify MAC-based access control. For
information about portal authentication, see "Configuring portal authentication."
To specify the access control method:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
80
Step
Command
Remarks
• In system view:
dot1x port-method { macbased |
portbased } [ interface interface-list ]
2.
Specify an access
control method.
Optional.
• In Ethernet interface view:
Use either method.
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 Ethernet 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
1.
Enter system view.
Command
Remarks
system-view
N/A
• In system view:
2.
Set the maximum
number of concurrent
802.1X users on a
port.
Optional.
dot1x max-user user-number [ interface
interface-list ]
Use either method.
• In Ethernet interface view:
a. interface interface-type interface-number
b. dot1x max-user user-number [ interface
interface-list ]
The default maximum
number of concurrent
802.1X users on a port is
2048.
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
1.
Enter system view.
Command
Remarks
system-view
N/A
81
Step
Command
Set the maximum number of
attempts for sending an
authentication request.
2.
Remarks
Optional.
dot1x retry max-retry-value
The default setting is 2.
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
Optional.
Set the server timeout
timer.
dot1x timer server-timeout
server-timeout-value
Optional.
3.
The default is 30 seconds.
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. HP recommends that you use the iNode client software and IMC server to guarantee the
normal operation of the online user handshake security function.
82
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.
•
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
Enable the online handshake
security function.
dot1x handshake secure
5.
The default is 15 seconds.
N/A
Optional.
By default, the function is enabled.
Optional.
By default, the function is disabled.
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.
83
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.
Enter Ethernet interface view.
interface interface-type
interface-number
3.
4.
Enable an authentication
trigger.
dot1x { multicast-trigger |
unicast-trigger }
The default 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.
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:
84
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 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.
Configuration guidelines
•
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 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.
Configuration procedure
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
Optional.
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.
85
The default is 3600 seconds.
Configuring a port to send EAPOL frames untagged
EAPOL frames exchanged between the 802.1X client and the network access device must not contain
VLAN tags. If any 802.1X user attached to a port is assigned a tagged VLAN, you must enable the port
to send EAPOL frames untagged to 802.1X clients.
To configure a port to send EAPOL packets untagged to 802.1X clients:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter Layer 2 Ethernet
interface view.
interface interface-type
interface-number
N/A
3.
Configure the port to send
802.1X EAPOL frames
untagged.
dot1x eapol untag
By default, whether the port sends
EAPOL packets with a VLAN tag
depends on the VLAN settings on
the port.
Setting the maximum number of 802.1X
authentication attempts for MAC authentication
users
If both MAC authentication and 802.1X authentication are enabled on a port, the device allows an
authenticated MAC authentication user to initiate an 802.1X authentication. If the user passes 802.1X
authentication, the user goes online as an 802.1X user. If the user fails 802.1X authentication, the user
can retry authentication until the maximum number of authentication attempts is reached.
To set the maximum number of 802.1X authentication attempts for MAC authentication users:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter Layer 2 Ethernet interface
view.
interface interface-type
interface-number
N/A
dot1x attempts max-fail
unsuccessful-attempts
By default, an authenticated MAC
authentication user can retry
802.1X authentication until the
maximum number of authentication
attempts configured on the 802.1X
client is reached.
3.
Set the maximum number of
802.1X authentication attempts
for MAC authentication users.
Configuring a VLAN group
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
86
Step
2.
Create a VLAN group and
enter its view.
Command
Remarks
vlan-group group-name
By default, no VLAN group exists.
By default, a VLAN group does not
contain VLANs.
3.
Add VLANs to the group.
vlan-list vlan-list
You can repeat this step to add VLANs.
Do not add a super VLAN to a VLAN
group. The device does not assign
super VLANs to 802.1X users.
Configuring an 802.1X guest VLAN
Configuration guidelines
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.
•
With 802.1X authentication, a hybrid port is always assigned to a VLAN as an untagged member.
After the assignment, do not reconfigure the port as a tagged member in the VLAN.
•
If 802.1X clients in your network cannot trigger an immediate DHCP-assigned IP address renewal
in response to a VLAN change, the 802.1X users cannot access authorized network resources
immediately after an 802.1X authentication is complete. As a solution, remind the 802.1X users to
release their IP addresses or repair their network connections for a DHCP reassignment after
802.1X authentication is complete. The HP iNode client does not have this problem.
•
Use Table 8 when configuring multiple security features on a port.
Table 8 Relationships of the 802.1X guest VLAN and other security features
Feature
Relationship description
Reference
Super VLAN
You cannot specify a VLAN as both a super
VLAN and an 802.1X guest VLAN.
See Layer 2—LAN
Switching Configuration
Guide
MAC authentication guest VLAN
on a port that performs
MAC-based access control
Only the 802.1X guest VLAN take effect. A
user that fails MAC authentication will not
be assigned to the MAC authentication
guest VLAN.
See "Configuring MAC
authentication"
802.1X Auth-Fail VLAN on a port
that performs MAC-based access
control
The 802.1X Auth-Fail VLAN has a higher
priority
See "Using 802.1X
authentication with other
features"
Port intrusion protection on a port
that performs MAC-based access
control
The 802.1X guest 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"
87
Configuration prerequisites
•
Create the VLAN to be specified as the 802.1X guest 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 802.1X guest VLAN as an
untagged member. For more information about the MAC-based VLAN function, see Layer 2—LAN
Switching Configuration Guide.
Configuration procedure
To configure an 802.1X guest VLAN:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• In system view:
2.
Configure an 802.1X
guest VLAN for one
or more ports.
dot1x guest-vlan guest-vlan-id [ interface
interface-list ]
• In Ethernet interface view:
a. interface interface-type interface-number
Use either method.
By default, no 802.1X guest
VLAN is configured on any
port.
b. dot1x guest-vlan guest-vlan-id
Configuring an 802.1X Auth-Fail VLAN
Configuration guidelines
Follow these guidelines when configuring an 802.1X Auth-Fail VLAN:
•
Assign different IDs to the voice VLAN, 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.
•
If 802.1X clients in your network cannot trigger an immediate DHCP-assigned IP address renewal
in response to a VLAN change, the 802.1X users cannot access authorized network resources
immediately after an 802.1X authentication is complete. As a solution, remind the 802.1X users to
release their IP addresses or repair their network connections for a DHCP reassignment after
802.1X authentication is complete. The HP iNode client does not have this problem.
•
Use Table 9 when configuring multiple security features on a port.
Table 9 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
88
Feature
Relationship description
Reference
MAC authentication guest VLAN
on a port that performs
MAC-based access control
The 802.1X Auth-Fail VLAN has a high
priority.
See "Configuring MAC
authentication"
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"
Configuration prerequisites
•
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
(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.
Configuration procedure
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
Configuration guidelines
•
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.
•
If 802.1X clients in your network cannot trigger an immediate DHCP-assigned IP address renewal
in response to a VLAN change, the 802.1X users cannot access authorized network resources
immediately after an 802.1X authentication is complete. As a solution, remind the 802.1X users to
89
release their IP addresses or repair their network connections for a DHCP reassignment after
802.1X authentication is complete. The HP iNode client does not have this problem.
Configuration prerequisites
•
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.
Configuration procedure
To configure an 802.1X critical VLAN:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
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 \.
Follow the steps to specify a set of domain name delimiters:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
90
Step
2.
Command
Specify a set of domain name
delimiters for 802.1X users.
Remarks
Optional.
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
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 29, the access device performs 802.1X authentication for users that connect to port
GigabitEthernet 1/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 access device. If RADIUS accounting
fails, the access device 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 access device and the authentication server,
and the shared key as money for packets between the access device and the accounting server.
91
Figure 29 Network diagram
Configuration procedure
1.
Configure the 802.1X client. If HP 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. For information about
the RADIUS commands used on the access device in this example, see Security Command
Reference. (Details not shown.)
3.
Assign an IP address to each interface on the access device. (Details not shown.)
4.
Configure user accounts for the 802.1X users on the access device:
# 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.)
<Device> system-view
[Device] local-user localuser
[Device-luser-localuser] service-type lan-access
[Device-luser-localuser] password simple localpass
# Configure the idle cut function to log off any online user that has been idled for 20 minutes.
[Device-luser-localuser] authorization-attribute idle-cut 20
[Device-luser-localuser] quit
5.
Configure a RADIUS scheme:
# Create the RADIUS scheme radius1 and enter its view.
[Device] radius scheme radius1
# Specify the IP addresses of the primary authentication and accounting RADIUS servers.
[Device-radius-radius1] primary authentication 10.1.1.1
[Device-radius-radius1] primary accounting 10.1.1.1
# Configure the IP addresses of the secondary authentication and accounting RADIUS servers.
[Device-radius-radius1] secondary authentication 10.1.1.2
[Device-radius-radius1] secondary accounting 10.1.1.2
# Specify the shared key between the access device and the authentication server.
[Device-radius-radius1] key authentication name
# Specify the shared key between the access device and the accounting server.
[Device-radius-radius1] key accounting money
# Exclude the ISP domain name from the username sent to the RADIUS servers.
92
[Device-radius-radius1] user-name-format without-domain
[Device-radius-radius1] quit
NOTE:
The access device 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 access device.
6.
Configure the ISP domain:
# Create the ISP domain aabbcc.net and enter its view.
[Device] domain aabbcc.net
# Apply the RADIUS scheme radius1 to the ISP domain, and specify local authentication as the
secondary authentication method.
[Device-isp-aabbcc.net] authentication lan-access radius-scheme radius1 local
[Device-isp-aabbcc.net] authorization lan-access radius-scheme radius1 local
[Device-isp-aabbcc.net] accounting lan-access radius-scheme radius1 local
# Set the maximum number of concurrent users in the domain to 30.
[Device-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.
[Device-isp-aabbcc.net] idle-cut enable 20
[Device-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.
[Device] domain default enable aabbcc.net
7.
Configure 802.1X:
# Enable 802.1X globally.
[Device] dot1x
# Enable 802.1X on port GigabitEthernet 1/0/1.
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] dot1x
[Device-GigabitEthernet1/0/1] quit
# Enable MAC-based access control on the port. (Optional. MAC-based access control is the
default setting.)
[Device] dot1x port-method macbased interface gigabitethernet 1/0/1
Verifying the configuration
Use the display dot1x interface gigabitethernet 1/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.
93
802.1X with guest VLAN and VLAN assignment
configuration example
Network requirements
As shown in Figure 30:
•
A host is connected to port GigabitEthernet 1/0/2 of the device and must pass 802.1X
authentication to access the Internet. GigabitEthernet 1/0/2 is in VLAN 1.
•
GigabitEthernet 1/0/2 implements port-based access control.
•
GigabitEthernet 1/0/3 is in VLAN 5 and is for accessing the Internet.
•
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 1/0/2 within a period of time, the device
adds GigabitEthernet 1/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 access device assigns the host to VLAN 5 where
GigabitEthernet 1/0/3 is. The host can access the Internet.
Figure 30 Network diagram
94
Configuration procedure
The following configuration procedure covers most AAA/RADIUS configuration commands on the
device. 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.
<Device> system-view
[Device] vlan 1
[Device-vlan1] port gigabitethernet 1/0/2
[Device-vlan1] quit
[Device] vlan 10
[Device-vlan10] port gigabitethernet 1/0/1
[Device-vlan10] quit
[Device] vlan 2
[Device-vlan2] port gigabitethernet 1/0/4
[Device-vlan2] quit
[Device] vlan 5
[Device-vlan5] port gigabitethernet 1/0/3
[Device-vlan5] quit
4.
Configure a RADIUS scheme:
# Configure RADIUS scheme 2000 and enter its view.
<Device> system-view
[Device] radius scheme 2000
# Specify primary and secondary authentication and accounting servers. Set the shared key to abc
for authentication and accounting packets.
[Device-radius-2000] primary authentication 10.11.1.1 1812
[Device-radius-2000] primary accounting 10.11.1.1 1813
[Device-radius-2000] key authentication abc
[Device-radius-2000] key accounting abc
# Exclude the ISP domain name from the username sent to the RADIUS server.
[Device-radius-2000] user-name-format without-domain
[Device-radius-2000] quit
5.
Configure an ISP domain:
# Create ISP domain bbb and enter its view.
[Device] domaim bbb
# Apply RADIUS scheme 2000 to the ISP domain for authentication, authorization, and
accounting.
[Device-isp-bbb] authentication lan-access radius-scheme 2000
[Device-isp-bbb] authorization lan-access radius-scheme 2000
[Device-isp-bbb] accounting lan-access radius-scheme 2000
[Device-isp-bbb] quit
6.
Configure 802.1X:
95
# Enable 802.1X globally.
[Device] dot1x
# Enable 802.1X for port GigabitEthernet 1/0/2.
[Device] interface gigabitethernet 1/0/2
[Device-GigabitEthernet1/0/2] dot1x
# Implement port-based access control on the port.
[Device-GigabitEthernet1/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.
[Device-GigabitEthernet1/0/2] dot1x port-control auto
[Device-GigabitEthernet1/0/2] quit
# Set VLAN 10 as the 802.1X guest VLAN for port GigabitEthernet 1/0/2.
[Device] dot1x guest-vlan 10 interface gigabitethernet 1/0/2
Verifying the configuration
Use the display dot1x interface gigabitethernet 1/0/2 command to verify the 802.1X guest VLAN
configuration on GigabitEthernet 1/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 1/0/2 is assigned
to VLAN 10.
After a user passes authentication, you can use the display interface gigabitethernet 1/0/2 command to
verity that port GigabitEthernet 1/0/2 has been added to VLAN 5.
802.1X with ACL assignment configuration
example
Network requirements
As shown in Figure 31, the host at 192.168.1.10 connects to port GigabitEthernet 1/0/1 of the network
access device.
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 1/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 31 Network diagram
RADIUS server cluster
Auth: 10.1.1.1
Acct: 10.1.1.2
GE1/0/2
Host
GE1/0/1
Vlan-int2
192.168.1.1/24
GE1/0/3
Internet
Device
FTP server
192.168.1.10/24
10.0.0.1/24
96
Configuration procedure
The following configuration procedure provides the major AAA and RADIUS configuration on the access
device. 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 access device:
# Assign IP addresses to interfaces. (Details not shown.)
# Configure the RADIUS scheme.
<Device> system-view
[Device] radius scheme 2000
[Device-radius-2000] primary authentication 10.1.1.1 1812
[Device-radius-2000] primary accounting 10.1.1.2 1813
[Device-radius-2000] key authentication abc
[Device-radius-2000] key accounting abc
[Device-radius-2000] user-name-format without-domain
[Device-radius-2000] quit
# Create an ISP domain and specify the RADIUS scheme 2000 as the default AAA schemes for the
domain.
[Device] domain 2000
[Device-isp-2000] authentication default radius-scheme 2000
[Device-isp-2000] authorization default radius-scheme 2000
[Device-isp-2000] accounting default radius-scheme 2000
[Device-isp-2000] quit
# Configure a time range ftp for the weekdays from 8:00 to 18:00.
[Device] 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.
[Device] acl number 3000
[Device-acl-adv-3000] rule 0 deny ip destination 10.0.0.1 0 time-range ftp
[Device-acl-adv-3000] quit
# Enable 802.1X globally.
[Device] dot1x
# Enable 802.1X on port GigabitEthernet 1/0/1.
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/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
97
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 HP integrated endpoint access control solution, which enables
the security client, security policy server, access device, 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 access device 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.
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 download EAD
client, obtain a dynamic IP address from a DHCP server, or perform some other tasks to be compliant
with the network security strategy.
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
Follow these guidelines when you configure 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
Follow these guidelines when you configure the redirect URL:
•
The redirect URL must be on the free IP subnet.
•
When Layer-2 portal is configured, the redirect URL does not take effect.
To configure a 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.
Setting the EAD rule timer
EAD fast deployment automatically creates an ACL rule, or an EAD rule, to open access to the redirect
URL for each redirected user seeking to access the network. 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
Optional.
The default timer is 30 minutes.
Displaying and maintaining EAD fast deployment
100
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
EAD fast deployment configuration example
Network requirements
As shown in Figure 32, the hosts on the intranet 192.168.1.0/24 are attached to port GigabitEthernet
1/0/1 of the network access device, 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 32 Network diagram
In addition to the configuration on the access device, 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.
101
•
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.
<Device> system-view
[Device] dhcp enable
# Configure a DHCP server for a DHCP server group.
[Device] dhcp relay server-group 1 ip 192.168.2.2
# Enable the relay agent on VLAN interface 2.
[Device] interface vlan-interface 2
[Device-Vlan-interface2] dhcp select relay
# Correlate VLAN interface 2 to the DHCP server group.
[Device-Vlan-interface2] dhcp relay server-select 1
[Device-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.
[Device] dot1x free-ip 192.168.2.0 24
# Configure the redirect URL for client software download.
[Device] dot1x url http://192.168.2.3
# Enable 802.1X globally.
[Device] dot1x
# Enable 802.1X on the port.
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/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
102
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.
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.
1.
Enter a dotted decimal IP address that is not in any free IP segment.
2.
Make sure that the network access device and the server are correctly configured.
Solution
103
Configuring MAC authentication
Overview
MAC authentication controls network access by authenticating source MAC addresses on a port. It does
not require client software. A user does not need to input 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. This 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 the MAC address 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 approaches
You can perform MAC authentication on the access device (local authentication) or through a Remote
Authentication Dial-In User Service (RADIUS) server.
Suppose a source MAC unknown packet arrives at a MAC authentication enabled port.
In the local authentication approach:
•
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.
In the RADIUS authentication approach:
•
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.
104
For more information about configuring local authentication and RADIUS authentication, see
"Configuring AAA."
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 the account's
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.
Guest VLAN
You can configure a guest VLAN to accommodate MAC authentication users that have failed MAC
authentication on the port. Users in the MAC authentication guest VLAN can access a limited set of
network resources, such as a software server, to download anti-virus software and system patches. If no
MAC authentication guest VLAN is configured, the user that fails MAC authentication cannot access any
network resources.
105
If a user in the guest VLAN passes MAC authentication, that user is removed from the guest VLAN and
can access all authorized network resources. If not, the user is still in the MAC authentication guest
VLAN.
A hybrid port is always assigned to a guest VLAN as an untagged member. After the assignment, do not
re-configure the port as a tagged member in the VLAN.
Critical VLAN
You can configure a MAC authentication critical VLAN on a port to accommodate users that fail MAC
authentication because no RADIUS authentication server is reachable. Users in a MAC authentication
critical VLAN can access a limit set of network resources depending on your configuration.
The critical VLAN feature takes effect when MAC authentication is performed only through RADIUS
servers. If a MAC authentication 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."
Any of the following RADIUS authentication server changes in the ISP domain for MAC authentication
users on a port can cause users to be removed from the critical VLAN:
•
An authentication server is added to the ISP domain and the server is reachable.
•
A response from a RADIUS authentication server is received.
•
The RADIUS server probing function detects that a RADIUS authentication server is reachable.
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
Configuring a MAC authentication guest VLAN
Optional
Configuring a MAC authentication critical VLAN
Optional
Configuring MAC authentication delay
Optional
Enabling MAC authentication multi-VLAN mode
Optional
Basic configuration for MAC authentication
•
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 that the username and password for each account is
the same as the MAC address of the MAC authentication users.
106
MAC authentication can take effect on a port only when it is enabled globally and on the port.
Configuring 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 }
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 ] ] }
3.
4.
Optional.
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 in lower case
without hyphens.
NOTE:
When global MAC authentication is enabled, the EAD fast deployment function cannot take effect.
Configuring MAC authentication on a port
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• In system view:
mac-authentication interface
interface-list
2.
Enable MAC authentication.
• In interface view:
a. interface interface-type
interface-number
Disabled by default.
Enable MAC authentication for
ports in bulk in system view or an
individual port in Ethernet
interface view.
b. mac-authentication
3.
Set the maximum number of
concurrent MAC authentication
users allowed on a port.
Optional.
mac-authentication max-user
user-number
By default, the maximum number
of concurrent MAC
authentication users is 2048.
NOTE:
You cannot add a MAC authentication enabled port in to a link aggregation group or service loopback
group, or enable MAC authentication on a port already in a link aggregation group or service loopback
group.
107
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 Ethernet interface view.
MAC authentication chooses an authentication domain for users on a port in this order: the
interface-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
1.
Enter system view.
Command
Remarks
system-view
N/A
• In system view:
2.
Specify an authentication
domain for MAC
authentication users.
mac-authentication domain
domain-name
• In interface view:
a. interface interface-type
interface-number
Use either method.
By default, the system default
authentication domain is used for
MAC authentication users.
b. mac-authentication domain
domain-name
Configuring a MAC authentication guest VLAN
Follow the guidelines in Table 10 when configuring a MAC authentication guest VLAN on a port.
Table 10 Relationships of the MAC authentication guest VLAN with other security features
Feature
Relationship description
Reference
Quiet function of MAC
authentication
The MAC authentication guest VLAN
function has higher priority. A user can
access any resources in the guest VLAN.
See "MAC authentication timers"
Super VLAN
You cannot specify a VLAN as both a super
VLAN and a MAC authentication guest
VLAN.
See Layer 2—LAN Switching
Configuration Guide
Port intrusion protection
The MAC authentication guest VLAN
function has higher priority than the block
MAC action but lower priority than the
shutdown port action of the port intrusion
protection feature.
See "Configuring port security"
802.1X guest VLAN on a
port that performs
MAC-based access
control
The MAC authentication guest VLAN has a
lower priority.
See "Configuring 802.1X"
108
If MAC authentication clients in your network cannot trigger an immediate DHCP-assigned IP address
renewal in response to a VLAN change, the MAC authentication users cannot access authorized network
resources immediately after a MAC authentication is complete. As a solution, remind the MAC
authentication users to release their IP addresses or repair their network connections for a DHCP
reassignment after MAC authentication is complete.
Before you configure a MAC authentication guest VLAN on a port, complete the following tasks:
•
Enable MAC authentication.
•
Enable MAC-based VLAN on the port.
•
Create the VLAN to be specified as the MAC authentication guest VLAN.
To configure a MAC authentication guest VLAN:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter Ethernet port view.
interface interface-type
interface-number
N/A
3.
Specify a MAC
authentication guest
VLAN.
mac-authentication guest-vlan
guest-vlan-id
By default, no MAC authentication
guest VLAN is configured.
You can configure only one MAC
authentication guest VLAN on a
port.
Configuring a MAC authentication critical VLAN
Follow the guidelines in Table 11 when you configure a MAC authentication critical VLAN on a port.
Table 11 Relationships of the MAC authentication critical VLAN with other security features
Feature
Relationship description
Reference
The MAC authentication critical VLAN
function has higher priority.
Quiet function of MAC
authentication
When a user fails MAC authentication
because no RADIUS authentication server is
reachable, the user can access the resources
in the critical VLAN, and the user's MAC
address is not marked as a silent MAC
address.
See "MAC authentication timers"
Super VLAN
You cannot specify a VLAN as both a super
VLAN and a MAC authentication critical
VLAN.
See Layer 2—LAN Switching
Configuration Guide
Port intrusion protection
The MAC authentication critical VLAN
function has higher priority than the block
MAC action but lower priority than the
shutdown port action of the port intrusion
protection feature.
See "Configuring port security"
If MAC authentication clients in your network cannot trigger an immediate DHCP-assigned IP address
renewal in response to a VLAN change, the MAC authentication users cannot access authorized network
109
resources immediately after a MAC authentication is complete. As a solution, remind the MAC
authentication users to release their IP addresses or repair their network connections for a DHCP
reassignment after MAC authentication is complete.
Before you configure a MAC authentication critical VLAN on a port, complete the following tasks:
•
Enable MAC authentication.
•
Enable MAC-based VLAN on the port.
•
Create the VLAN to be specified as the MAC authentication critical VLAN.
To configure a MAC authentication critical VLAN:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter Layer 2 Ethernet
port view.
interface interface-type
interface-number
N/A
3.
Specify a MAC
authentication critical
VLAN.
mac-authentication critical vlan
critical-vlan-id
By default, no MAC authentication
critical VLAN is configured.
You can configure only one MAC
authentication critical VLAN on a
port.
Configuring MAC authentication delay
When both 802.1X authentication and MAC authentication are enabled on a port, you can delay MAC
authentication, so that 802.1X authentication is preferentially triggered.
To configure MAC authentication delay:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter Layer 2 Ethernet
interface view.
interface interface-type
interface-number
N/A
3.
Enable MAC authentication
delay and set the delay time.
mac-authentication timer
auth-delay time
By default, MAC authentication is
not delayed.
Enabling MAC authentication multi-VLAN mode
By default, a port saves the MAC-VLAN mapping entry for a MAC authenticated user, and forwards
packets that match the entry. If the user sends packets with a different VLAN, the port re-authenticates the
user and updates the MAC-VLAN mapping entry on the port. For a user that sends various types of traffic
(for example, data, video, and audio) in multiple VLANs with the same MAC address, frequent MAC
re-authentication downgrades the system performance and affects data transmission quality.
The MAC authentication multi-VLAN mode enables a port to forward packets for the authenticated user
in up to five VLANs without re-authentication. When the port receives a packet sourced from the
authenticated MAC address in a different VLAN, the device does not authenticate the user or update the
original MAC-VLAN mapping entry on the port. It adds a new MAC-VLAN mapping entry for the MAC
address.
110
For example, a MAC authentication-enabled port connects to an IP phone that can send tagged and
untagged frames. The port receives tagged frames in VLAN 2 and untagged frames in VLAN 1. Before
you enable the multi-VLAN mode, the port must re-authenticate the IP phone every time it receives a frame
from a VLAN that is different from the recorded MAC-VLAN entry. After you enable the multi-VLAN mode,
the port can receive tagged and untagged frames from the IP phone without triggering a MAC
re-authentication. The multi-VLAN mode improves the transmission quality of data that is vulnerable to
delay and interference.
To enable MAC authentication multi-VLAN mode:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter Layer 2 Ethernet
interface view.
interface interface-type
interface-number
N/A
Enable MAC authentication
multi-VLAN mode.
3.
mac-authentication host-mode
multi-vlan
By default, a MAC
authentication-enabled port
forwards packets for an
authenticated user only in the
VLAN where the user's MAC
address was authenticated.
This command is available only in
Release 5206 and later.
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
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 33, perform local MAC authentication on port GigabitEthernet 1/0/1 to control
Internet access. Make sure that:
•
All users belong to domain aabbcc.net.
•
Local users use their MAC address as the username and password for MAC authentication. The
MAC addresses are hyphen separated and in lower case.
•
The access device detects whether a user has gone offline every 180 seconds. When a user fails
authentication, the device does not authenticate the user within 180 seconds.
111
Figure 33 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.
<Device> system-view
[Device] local-user 00-e0-fc-12-34-56
[Device-luser-00-e0-fc-12-34-56] password simple 00-e0-fc-12-34-56
[Device-luser-00-e0-fc-12-34-56] service-type lan-access
[Device-luser-00-e0-fc-12-34-56] quit
# Configure ISP domain aabbcc.net to perform local authentication for LAN access users.
[Device] domain aabbcc.net
[Device-isp-aabbcc.net] authentication lan-access local
[Device-isp-aabbcc.net] quit
# Enable MAC authentication globally.
[Device] mac-authentication
# Enable MAC authentication on port GigabitEthernet 1/0/1.
[Device] mac-authentication interface gigabitethernet 1/0/1
# Specify the ISP domain for MAC authentication.
[Device] mac-authentication domain aabbcc.net
# Set the MAC authentication timers.
[Device] mac-authentication timer offline-detect 180
[Device] mac-authentication timer quiet 180
# Configure MAC authentication to use MAC-based accounts. The MAC address usernames and
passwords are hyphenated and in lowercase.
[Device] mac-authentication user-name-format mac-address with-hyphen lowercase
Verifying the configuration
# Display MAC authentication settings and statistics.
<Device> 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:
112
MAC Addr
From Port
Port Index
Gigabitethernet1/0/1 is link-up
MAC address authentication is enabled
Authenticate success: 1, failed: 0
Max number of on-line users is 2048
Current online user number is 1
MAC Addr
Authenticate state
00e0-fc12-3456
MAC_AUTHENTICATOR_SUCCESS
Auth Index
29
# After the user passes authentication, use the display connection command to display the online user
information.
<Device> display connection
Slot:
1
Index=29
,Username=00-e0-fc-12-34-56@aabbcc.net
IP=N/A
IPv6=N/A
MAC=00e0-fc12-3456
Total 1 connection(s) matched on slot 1.
Total 1 connection(s) matched.
RADIUS-based MAC authentication configuration example
Network requirements
As shown in Figure 34, a host connects to port GigabitEthernet 1/0/1 on the access device. The device
uses RADIUS servers for authentication, authorization, and accounting.
Perform MAC authentication on port GigabitEthernet 1/0/1 to control Internet access. Make sure that:
•
The device detects whether a user has gone offline every 180 seconds. If a user fails authentication,
the device 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.
Figure 34 Network diagram
RADIUS servers
Auth:10.1.1.1
Acct:10.1.1.2
GE1/0/1
Host
IP network
Device
Configuration procedure
1.
Make sure the RADIUS server and the access device 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.
3.
Configure the device:
113
# Configure a RADIUS scheme.
<Device> system-view
[Device] radius scheme 2000
[Device-radius-2000] primary authentication 10.1.1.1 1812
[Device-radius-2000] primary accounting 10.1.1.2 1813
[Device-radius-2000] key authentication abc
[Device-radius-2000] key accounting abc
[Device-radius-2000] user-name-format without-domain
[Device-radius-2000] quit
# Apply the RADIUS scheme to ISP domain 2000 for authentication, authorization, and
accounting.
[Device] domain 2000
[Device-isp-2000] authentication default radius-scheme 2000
[Device-isp-2000] authorization default radius-scheme 2000
[Device-isp-2000] accounting default radius-scheme 2000
[Device-isp-2000] quit
# Enable MAC authentication globally.
[Device] mac-authentication
# Enable MAC authentication on port GigabitEthernet 1/0/1.
[Device] mac-authentication interface gigabitethernet 1/0/1
# Specify the ISP domain for MAC authentication.
[Device] mac-authentication domain 2000
# Set the MAC authentication timers.
[Device] mac-authentication timer offline-detect 180
[Device] mac-authentication timer quiet 180
# Specify username aaa and plaintext password 123456 for the account shared by MAC
authentication users.
[Device] mac-authentication user-name-format fixed account aaa password simple 123456
Verifying the configuration
# Display MAC authentication settings and statistics.
<Device> 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
Gigabitethernet1/0/1 is link-up
MAC address authentication is enabled
Authenticate success: 1, failed: 0
114
Port Index
Max number of on-line users is 2048
Current online user number is 1
MAC ADDR
Authenticate state
00e0-fc12-3456
MAC_AUTHENTICATOR_SUCCESS
Auth Index
29
# After a user passes MAC authentication, use the display connection command to display online user
information.
<Device> display connection
Slot:
1
Index=29
,Username=aaa@2000
IP=N/A
IPv6=N/A
MAC=00e0-fc12-3456
Total 1 connection(s) matched on slot 1.
Total 1 connection(s) matched.
ACL assignment configuration example
Network requirements
As shown in Figure 35, a host connects to the device's port GigabitEthernet 1/0/1, and the device uses
RADIUS servers to perform authentication, authorization, and accounting.
Perform MAC authentication on port GigabitEthernet 1/0/1 to control Internet access. Make sure that an
authenticated user can access the Internet but 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.
Figure 35 Network diagram
Configuration procedure
1.
Make sure the RADIUS server and the access device can reach each other.
2.
Configure the ACL assignment:
# 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
115
3.
Configure RADIUS-based MAC authentication on the device:
# 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 1/0/1.
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] mac-authentication
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, perform the display connection command on the device to view
online user information.
[Sysname-GigabitEthernet1/0/1] display connection
Slot:
1
Index=9
, 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 1.
Total 1 connection(s) matched.
Ping the FTP server from the host to verify that the ACL 3000 has been assigned to port GigabitEthernet
1/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:
116
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),
117
Configuring portal authentication
Overview
Portal authentication helps control access to the Internet. It 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; but 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
Hypertext Transfer Protocol (HTTP) to log on to a portal website for authentication.
The portal feature provides the flexibility for Internet service providers (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.
118
Figure 36 Portal system components
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 a portal client software for portal authentication.
Client security check is implemented through communications between the client and the security policy
server.
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.
NOTE:
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.
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.
119
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 in the following procedure:
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, which 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:
To implement security check, the client must be the HP iNode client.
Portal authentication supports NAT traversal whether it is initiated by a Web client or an HP iNode client.
When the portal authentication client is on a private network, but the portal server is on a public network
and the access device is enabled with NAT, network address translations performed on the access
device do not affect portal authentication. However, in such a case, HP recommends using an interface’s
public IP address as the source address of outgoing portal packets.
Portal system using the local portal server
System components
In addition to use a separate device as the portal server, a portal system can also use the local portal
server function of the access device to authenticate Web users directly. A portal system using the local
portal server does not support extended portal functions. No security policy server is needed for local
portal service. In this case, the portal system consists of only three components: authentication client,
access device, and authentication/accounting server, as shown in Figure 37.
Figure 37 Portal system using the local portal server
NOTE:
The local portal server function of the access device implements only some simple portal server functions.
It only allows users to log on and log off through the Web interface. It cannot take the place of an
independent portal server.
120
Protocols used for interaction between the client and local portal server
HTTP and Hypertext Transfer Protocol Secure (HTTPS) can be used for interaction between an
authentication client and an access device providing the local portal server function. If HTTP is used,
there are potential security problems because HTTP packets are transferred in plain text; if HTTPS is used,
secure data transmission is ensured because HTTPS packets are transferred in cipher text based on SSL.
Authentication page customization support
The local portal server function allows you to customize authentication pages. You can customize
authentication pages by editing the corresponding HTML files and then compress and save the files to the
storage medium of the device. A set of customized authentication pages consists of six authentication
pages—the logon page, the logon success page, the online page, the logoff success page, the logon
failure page, and the system busy page. A local portal server will push a corresponding authentication
page at each authentication phase. If you do not customize the authentication pages, the local portal
server will push the default authentication pages.
For the rules of customizing authentication pages, see "Customizing authentication pages."
Portal authentication modes
Portal authentication may work at Layer 2 or Layer 3 of the OSI model.
Layer 2 portal authentication
You can enable Layer 2 portal authentication on an access device’s Layer 2 ports that connect
authentication clients, so that only clients whose MAC addresses pass authentication can access the
external network. Only the local portal server provided by the access device supports Layer 2 portal
authentication.
Layer 2 portal authentication allows the authentication server to assign different VLANs according to user
authentication results so that access devices can thereby control user access to resources. After a client
passes authentication, the authentication server can assign an authorized VLAN to allow the user to
access the resources in the VLAN. If a client fails authentication, the authentication server can assign an
Auth-Fail VLAN. Layer 3 portal authentication does not support VLAN assignment.
Layer 3 portal authentication
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 and can be
121
useful. 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.
IPv6 portal authentication does not support the re-DHCP authentication mode.
•
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 device
generates an access control list (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 enhance
the capability of controlling packet forwarding by also using the learned MAC addresses.
Portal support for EAP
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 38 Portal support for EAP working flow diagram
As shown in Figure 38, 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.
• Only Layer 3 portal authentication that uses a remote portal server supports EAP authentication.
122
Layer 2 portal authentication process
Figure 39 Local Layer 2 portal authentication process
Local Layer 2 portal authentication takes the following procedure:
1.
The portal authentication client sends an HTTP request. Upon receiving the HTTP request, the
access device redirects it to the listening IP address of the local portal server, which supports HTTP
and HTTPS requests. The local portal server pushes a Web authentication page to the
authentication client. The user enters the username and password on the Web authentication
page.
The listening IP address of the local portal server is the IP address of a Layer 3 interface on the
access device that can communicate with the portal client. Usually, it is a Loopback interface's IP
address.
2.
The access device and the RADIUS server exchange RADIUS packets to authenticate the user.
3.
If the user passes RADIUS authentication, the local portal server pushes a logon success page to
the authentication client.
Authorized VLAN
Layer 2 portal authentication supports VLAN assignment by the authentication server. After a user passes
portal authentication, if the authentication server is configured with an authorized VLAN for the user, the
authentication server assigns the authorized VLAN to the access device. Then, the access device adds the
user to the authorized VLAN and generates a MAC VLAN entry. If the authorized VLAN does not exist,
the access device first creates the VLAN.
By deploying the authorized VLAN assignment function, you can control which authenticated users can
access which network resources.
Auth-Fail VLAN
The Auth-Fail VLAN feature allows users failing authentication to access a VLAN that accommodates
network resources such as the patches server, virus definitions server, client software server, and anti-virus
software server, so that the users can upgrade their client software or other programs. Such a VLAN is
called an Auth-Fail VLAN.
Layer 2 portal authentication supports Auth-Fail VLAN on a port that performs MAC-based access control.
With an Auth-Fail VLAN configured on a port, if a user on the port fails authentication, the access devices
creates a MAC VLAN entry based on the MAC address of the user and adds the user to the Auth-Fail
VLAN. Then, the user can access the non-HTTP resources in the Auth-Fail VLAN, and all HTTP requests of
the user will be redirected to the authentication page. If the user passes authentication, the access device
adds the user to the assigned VLAN or return the user to the initial VLAN of the port, depending on
whether the authentication server assigns a VLAN. If the user fails the authentication, the access device
keeps the user in the Auth-Fail VLAN. If an access port receives no traffic from a user in the Auth-Fail
VLAN during a specified period of time (90 seconds by default), it removes the user from the Auth-Fail
VLAN and adds the user to the initial VLAN of the port.
123
NOTE:
After a user is added to the authorized VLAN or Auth-Fail VLAN, the IP address of the client needs to be
automatically or manually updated to make sure that the client can communicate with the hosts in the
VLAN.
Assignment of authorized ACLs
The device can use ACLs to control user access to network resources and limit user access rights. With
authorized ACLs specified on the authentication server, when a user passes authentication, the
authentication server assigns an authorized ACL for the user, and the device filters traffic from the user on
the access port according to the authorized ACL. You must configure the authorized ACLs on the access
device if you specify authorized ACLs on the authentication server. To change the access right of a user,
specify a different authorized ACL on the authentication server or change the rules of the corresponding
authorized ACL on the device.
Layer 3 portal authentication process
Direct authentication and cross-subnet authentication share the same authentication process, while
re-DHCP authentication has a different process because of the presence of two address allocation
procedures.
Direct authentication/cross-subnet authentication process (with CHAP/PAP authentication)
Figure 40 Direct authentication/cross-subnet authentication process
The direct authentication/cross-subnet authentication takes the following procedure:
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 Challenge Handshake Authentication Protocol
(CHAP) messages. For Password Authentication Protocol (PAP) authentication, this step is skipped.
124
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.
Re-DHCP authentication process (with CHAP/PAP authentication)
Figure 41 Re-DHCP authentication process
The re-DHCP authentication takes the following procedure:
The first steps are the same as those in the direct authentication/cross-subnet authentication process.
1.
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.
2.
The portal server notifies the access device that the authentication client has obtained a new public
IP address.
3.
Detecting the change of the IP address by examining ARP packets received, the access device
notifies the portal server of the change.
125
4.
The portal server notifies the authentication client of logon success.
5.
The portal server sends a user IP address change acknowledgment message to the access device.
With extended portal functions, the process includes additional steps:
6.
The security policy server exchanges security check information with the authentication client to
check whether the authentication client meets the security requirements.
7.
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.
Portal support for EAP authentication process
Figure 42 Portal support for EAP authentication process
Authentication
client
Access
device
Portal server
Authentication/
Accounting server
Security
policy server
1) EAP request
2) Authentication request
3) RADIUS
authentication
Timer
4) Certificate request
5) EAP response
…
6) EAP authentication
…
7) Authentication
success
8) Authentication reply
9) Login success
10) Authentication reply
ACK
Security check
Authorization
All portal authentication modes share the same EAP authentication steps. The following takes the direct
portal authentication as an example 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.
126
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.
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 stateful failover
Overview
The stateful failover feature supports hot backup of services on two devices. It can be configured on key
devices to avoid service interruptions caused by single point failures. When working normally, the two
devices synchronize the service information of each other. If one device fails, the other device takes over
the services.
To implement stateful failover, specify a dedicated VLAN (called the "backup VLAN") on each device for
stateful failover packets. If both a failover link and a backup VLAN are configured, add the physical ports
at the two ends of the failover link to the backup VLAN. For more information about the stateful failover
feature, see High Availability Configuration Guide.
127
Figure 43 Network diagram for portal stateful failover configuration
As shown in Figure 43, users have to pass portal authentication to access the Internet. To avoid portal
service interruption caused by single point failures, you can deploy two access devices (Gateway A and
Gateway B) and configure the portal stateful failover function on them, so that they back up the portal
online user information of each other through the failover link. When one of them (Gateway A or
Gateway B) fails, the other can guarantee the normal data communication of the online portal users and
perform portal authentication for new portal users.
Basic concepts
1.
Device states
•
Independence: A stable running status of a device when it does not establish the failover link with
the other device.
•
Synchronization: A stable running status of a device when it establishes the failover link with the
other device successfully and is ready for data backup.
2.
User modes
•
Stand-alone: Indicates that the user data is stored on the local device only. Currently, the local
device is in independence state or it is in synchronization state but has not synchronized the user
data to the peer device yet.
•
Primary: Indicates that the user logs in from the local device, and the user data is generated on the
local device. The local device is in synchronization state and ready for receiving and processing
packets from the server.
128
•
Secondary: Indicates that the user logs in from the peer device, and the user data is synchronized
from the peer device to the local device. The local device is in synchronization state. It only receives
and processes the synchronization messages and does not process packets from the server.
Portal authentication across VPNs
This feature is not applicable to VPNs with overlapping address spaces.
In a scenario where the 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, you can deploy
portal authentication across MPLS VPNs. As shown in Figure 44, 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 44 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
For information about AAA implementation across VPNs, see "Configuring AAA."
Portal configuration task list
Complete these tasks to configure Layer 2 portal authentication:
Task
Remarks
Specifying the local portal server for Layer 2 portal authentication
Required
Configuring the local portal server
Customizing authentication pages
Optional
Configuring the local portal server
Required
Enabling Layer 2 portal authentication
Required
Configuring a portal-free rule
Setting the maximum number of online portal users
Controlling access of portal
users
Specifying an authentication domain for portal
users
Configuring Layer 2 portal authentication to
support Web proxy
129
Optional
Task
Remarks
Enabling support for portal user moving
Specifying an Auth-Fail VLAN for portal authentication
Optional
Specifying an auto redirection URL for authenticated portal users
Optional
Configuring online Layer 2 portal user detection
Optional
Logging off portal users
Optional
Complete these tasks to configure Layer 3 portal authentication:
Task
Remarks
Specifying a portal server for Layer 3 portal authentication
Required
Enabling Layer 3 portal authentication
Required
Configuring a portal-free rule
Controlling access of portal
users
Configuring an authentication source subnet
Setting the maximum number of online portal users
Optional
Specifying an authentication domain for portal
users
Configuring RADIUS related
attributes
Specifying NAS-Port-Type for an interface
Specifying a NAS ID profile for an interface
Optional
Specifying a source IP address for outgoing portal packets
Optional
Configuring portal stateful failover
Optional
Specifying an auto redirection URL for authenticated portal users
Optional
Configuring portal detection
functions
Configuring the portal server detection function
Configuring portal user information
synchronization
Logging off portal users
Optional
Optional
Configuration prerequisites
The portal feature provides a solution for user identity authentication and security check. However, the
portal feature cannot implement this solution by itself. RADIUS authentication needs to 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.
130
•
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, respectively, on the security policy server.
You can modify the authorized ACLs on the access device. However, your changes take effect only for
portal users logging on after the modification.
For portal authentication to work normally, make sure that the system name of the access device is no
more than 16 characters.
Specifying the portal server
Specifying the local portal server for Layer 2 portal
authentication
Layer 2 portal authentication uses the local portal server. Specify the IP address of a Layer 3 interface on
the device that is routable to the portal client as the listening IP address of the local portal server. HP
recommends using the IP address of a loopback interface rather than a physical Layer 3 interface,
because:
•
The status of a loopback interface is stable. There will be no authentication page access failures
caused by interface failures.
•
A loopback interface does not forward received packets to any network, avoiding impact on system
performance when there are many network access requests.
To specify the local portal server for Layer 2 portal authentication:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Specify the listening IP
address of the local portal
server for Layer 2 portal
authentication.
portal local-server ip ip-address
By default, no listening IP address
is specified.
NOTE:
The specified listening IP address can be changed or deleted only if Layer 2 portal authentication is not
enabled on any port.
131
Specifying a portal server for Layer 3 portal authentication
This task allows you to specify the 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.
If the portal server is in an MPLS VPN, specify the VPN instance when specifying the portal server on the
device, so the device can send packets to the portal server.
To specify a portal server for Layer 3 authentication:
Step
1.
2.
Command
Remarks
Enter system view.
system-view
N/A
Specify a portal server and
configure related parameters.
portal server server-name { ip
ipv4-address [ key [ cipher |
simple ] key-string | port port-id |
url url-string | vpn-instance
vpn-instance-name ] * | ipv6
ipv6-address [ key [ cipher |
simple ] key-string | port port-id |
url url-string ] * }
By default, no portal server is
specified.
NOTE:
The specified parameters of a portal server can be modified or deleted only if the portal server is not
referenced on any interface.
Configuring the local portal server
Configuring a local portal server is required only for local portal authentication. During local portal
authentication, the local portal server pushes authentication pages to users. You can define the
authentication pages for users; otherwise, the default authentication pages will be used during the
authentication process.
Customizing authentication pages
Customized authentication pages exist in the form of HTML files. You can compress them and then save
them in the storage medium of the access device.
A set of authentication pages includes six main authentication pages and their page elements. The six
main authentication pages are the logon page, the logon success page, the logon failure page, the
online page, the system busy page, and the logoff success page. The page elements refer to the files that
the authentication pages reference, for example, back.jpg for page Logon.htm. Each main
authentication page can reference multiple page elements. If you define only some of the main
authentication pages, the system will use the default authentication pages for the undefined ones.
For the local portal server to operate normally and steadily, follow the following rules when customizing
authentication pages:
Rules on file names
The main authentication pages have predefined file names, which cannot be changed.
132
Table 12 Main authentication page file names
Main authentication page
File name
Logon page
logon.htm
Logon success page
logonSuccess.htm
Logon failure page
logonFail.htm
Online page
Pushed after the user gets online for online notification
online.htm
System busy page
Pushed when the system is busy or the user is in the
logon process
busy.htm
Logoff success page
logoffSuccess.htm
NOTE:
You can define the names of the files other than the main authentication page files. The file names and
directory names are case-insensitive.
Rules on page requests
The local portal server supports only Post and Get requests.
•
Get requests are used to get the static files in the authentication pages and allow no recursion. For
example, if file Logon.htm includes contents that perform Get action on file ca.htm, file ca.htm
cannot include any reference to file Logon.htm.
•
Post requests are used when users submit username and password pairs, log on the system, and log
off the system.
Rules on Post request attributes
1.
Observe the following requirements when editing a form of an authentication page:
{
{
{
2.
An authentication page can have multiple forms, but there must be one and only one form
whose action is logon.cgi. Otherwise, user information cannot be sent to the local portal server.
The username attribute is fixed as PtUser, and the password attribute is fixed as PtPwd.
Attribute PtButton is required to indicate the action that the user requests, which can be Logon
or Logoff.
{
A logon Post request must contain PtUser, PtPwd, and PtButton attributes.
{
A logoff Post request must contain the PtButton attribute.
Authentication pages logon.htm and logonFail.htm must contain the logon Post request.
The following example shows part of the script in page logon.htm.
<form action=logon.cgi method = post >
<p>User name:<input type="text" name = "PtUser" style="width:160px;height:22px"
maxlength=64>
<p>Password :<input type="password" name = "PtPwd" style="width:160px;height:22px"
maxlength=32>
<p><input type=SUBMIT value="Logon" name = "PtButton" style="width:60px;"
onclick="form.action=form.action+location.search;>
</form>
3.
Authentication pages logonSuccess.htm and online.htm must contain the logoff Post request.
133
The following example shows part of the script in page online.htm.
<form action=logon.cgi method = post >
<p><input type=SUBMIT value="Logoff" name="PtButton" style="width:60px;">
</form>
Rules on page file compression and saving
•
A set of authentication page files must be compressed into a standard zip file. The name of a zip
file can contain only letters, numerals, and underscores. The zip file of the default authentication
pages must be saved with name defaultfile.zip.
•
The set of authentication pages must be located in the root directory of the zip file.
•
Zip files can be transferred to the device through FTP or TFTP. The default authentication pages file
must be saved in the root directory of the device, and other authentication files can be saved in the
root directory or the portal directory under the root directory of the device.
Examples of zip files on the device:
<Sysname> dir
Directory of flash:/portal/
0
-rw-
1405
Feb 28 2011 15:53:31
ssid2.zip
1
-rw-
1405
Feb 28 2011 15:53:20
ssid1.zip
2
-rw-
1405
Feb 28 2011 15:53:39
ssid3.zip
3
-rw-
1405
Feb 28 2011 15:53:44
ssid4.zip
2540 KB total (1319 KB free)
Rules on file size and contents
For the system to push customized authentication pages smoothly, you need comply with the following
size and content requirements on authentication pages.
•
The size of the zip file of each set of authentication pages, including the main authentication pages
and the page elements, must be no more than 500 KB.
•
The size of a single page, including the main authentication page and its page elements, must be
no more than 50 KB before being compressed.
•
Page elements can contain only static contents such as HTML, JS, CSS, and pictures.
Logging off a user who closes the logon success or online page
After a user passes authentication, the system pushes the logon success page named logonSuccess.htm.
If the user initiates another authentication through the logon page, the system pushes the online page
named online.htm. You can configure the device to forcibly log off the user when the user closes either of
these two pages. To do so, add the following contents in logonSuccess.htm and online.htm:
1.
Reference to JS file pt_private.js.
2.
Function pt_unload(), which is used to trigger page unloading.
3.
Function pt_submit(), the event handler function for Form.
4.
Function pt_init(), which is for triggering page loading.
The following is a script example with the added contents highlighted in gray:
<html>
<head>
<script type="text/javascript" language="javascript" src="pt_private.js"></script>
</head>
<body onload="pt_init();" onbeforeunload="return pt_unload();">
... ...
134
<form action=logon.cgi method = post onsubmit="pt_submit()">
... ...
</body>
</html>
Redirecting authenticated users to a specified Web page
To make the device automatically redirect authenticated users to a specified Web page, do the following
in logon.htm and logonSuccess.htm:
1.
In logon.htm, set the target attribute of Form to blank.
See the contents in gray:
<form method=post action=logon.cgi target="blank">
2.
Add the function for page loading pt_init() to logonSucceess.htm.
See the contents in gray:
<html>
<head>
<title>LogonSuccessed</title>
<script type="text/javascript" language="javascript"
src="pt_private.js"></script>
</head>
<body onload="pt_init();" onbeforeunload="return pt_unload();">
... ...
</body>
</html>
HP recommends using Microsoft IE 6.0 or above on the authentication clients. Make sure the browser of
an authentication client permits pop-ups or permits pop-ups from the access device. Otherwise, the user
cannot log off by closing the logon success or online page and can only click Cancel to return back to
the logon success or online page.
If a user refreshes the logon success or online page, or jumps to another website from either of the pages,
the device also logs off the user.
Only Microsoft IE, Mozilla Firefox, and Apple Safari browsers support the device to log off the user when
the user closes the logon success or online page. Google Chrome, Opera, and other browsers do not
support this function.
Configuring the local portal server
To make the local portal server take effect, specify the protocol to be used for communication between
the portal client and local portal server.
Configuration prerequisites
To configure the local portal server to support HTTPS, complete these configurations at first:
•
Configure PKI policies, obtain the CA certificate, and apply for a local certificate. For more
information, see "Configuring PKI."
•
Configure the SSL server policy, and specify the PKI domain to be used, which is configured in the
above step. For more information, see "Configuring SSL."
When you specify the protocol for the local portal server to support, the local portal server will load the
default authentication page file, which is supposed to be saved in the root directory of the device.
135
Therefore, to make sure that the local portal server uses the user-defined default authentication pages,
you must edit and save them properly. Otherwise, the system default authentication pages are used.
Configuration procedure
To configure the local portal server:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Configure the protocol type
for the local portal server to
support and load the default
authentication page file.
portal local-server { http | https
server-policy policy-name }
By default, the local portal server
does not support any protocol.
Configure the welcome
banner of the default
authentication pages of the
local portal server.
portal server banner banner-string
3.
Optional.
No welcome banner by default.
Enabling portal authentication
Only after you enable portal authentication on an access interface, can the access interface perform
portal authentication for connected clients.
Enabling Layer 2 portal authentication
Before enabling Layer 2 portal authentication, make sure that:
•
The listening IP address of the local portal server is specified.
•
Layer 3 portal authentication is not enabled on any interface.
Follow these guidelines when you enable Layer 2 portal authentication:
•
To ensure normal operation of portal authentication on a Layer 2 port, do not enable port security,
guest VLAN of 802.1X, or EAD fast deployment of 802.1X on the port.
•
To support assignment of authorized VLANs, you must enable the MAC-based VLAN function on
the port.
To enable Layer 2 portal authentication:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter Layer 2 Ethernet port
view.
interface interface-type
interface-number
N/A
3.
Enable Layer 2 portal
authentication on the port.
portal local-server enable
Not enabled by default.
Enabling Layer 3 portal authentication
Before enabling Layer 3 portal authentication on an interface, make sure:
•
An IP address is configured for the interface.
136
•
The interface is not added to any port aggregation group.
•
The portal server referenced by the interface already exists.
•
Layer 2 portal authentication is not enabled on any ports.
Follow these guidelines when you enable Layer 3 portal authentication:
•
You cannot enable portal authentication on a Layer 3 interface in a port aggregation group. If an
interface is enabled with portal authentication, you cannot add it to a port aggregation group.
•
The destination port number that the 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.
•
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.
•
An IPv6 portal server does not support the re-DHCP portal authentication mode.
•
You can enable both an IPv4 portal server and an IPv6 portal server for Layer 3 portal
authentication on an interface, but you cannot enable two IPv4 or two IPv6 portal servers on the
interface.
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
N/A
3.
Enable Layer 3 portal
authentication on the
interface.
portal server server-name method
{ direct | layer3 | redhcp }
Not enabled by default.
NOTE:
The portal server and its parameters can be deleted or modified only when the portal server is not
referenced by any interface.
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 that users sending the packets can directly access the specified external
websites.
For Layer 2 portal authentication, you can configure only a portal-free rule that is from any source
address to any or a specified destination address. If you configure a portal-free rule that is from any
137
source address to a specified destination address, users can access the specified address directly,
without being redirected to the portal authentication page for portal authentication. Usually, you can
configure the IP address of a server that provides certain services (such as software upgrading service)
as the destination IP address of a portal-free rule, so that Layer 2 portal authentication users can access
the services without portal authentication.
Follow these guidelines when you configure a portal-free rule:
•
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.
•
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.
To configure a portal-free rule:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• To configure an IPv4 portal-free rule:
2.
Configure a portal-free rule.
portal free-rule rule-number
{ destination { any | ip { ip-address
mask { mask-length | netmask } | any }
[ tcp tcp-port-number | udp
udp-port-number ] } | source { any |
[ interface interface-type
interface-number | ip { ip-address mask
{ mask-length | mask } | any } [ tcp
tcp-port-number | udp
udp-port-number ] | mac mac-address |
vlan vlan-id ] * } } *
Configure at least one
command.
• To configure an IPv6 portal-free rule:
portal free-rule rule-number
{ destination { any | ipv6 { ipv6-address
prefix-length | any } } | source { any |
[ interface interface-type
interface-number | ipv6 { ipv6-address
prefix-length | any } | mac mac-address
| vlan vlan-id ] * } } *
NOTE:
Regardless of whether portal authentication is enabled or not, you can only add or remove a portal-free
rule. You cannot modify it.
Configuring an authentication source subnet
Only Layer 3 portal authentication supports this feature.
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.
138
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
{ ipv4-network-address
{ mask-length | mask } | ipv6
ipv6-network-address
prefix-length }
By default, the source IPv4 subnet
is 0.0.0.0/0, and the source IPv6
subnet is ::/0, meaning that users
from any IPv4 or IPv6 subnet must
pass portal authentication to
access network resources.
You can configure multiple
authentication source subnets by
executing the portal auth-network
command repeatedly.
NOTE:
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.
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 users to be 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
3000 by default.
NOTE:
The maximum number of online portal users the switch actually assigns depends on the ACL resources on
the switch.
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.
139
To specify an 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
3.
Specify an authentication
domain for portal users on the
interface.
portal domain [ ipv6 ]
domain-name
By default, no authentication
domain is specified for portal
users.
The switch 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 Layer 2 portal authentication to support Web
proxy
By default, proxied HTTP requests cannot trigger Layer 2 portal authentication but are silently dropped.
To allow such HTTP requests to trigger portal authentication, configure the port numbers of the Web
proxy servers on the switch.
If a user's browser uses the Web Proxy Auto-Discovery (WPAD) protocol to discover Web proxy servers,
add the port numbers of the Web proxy servers on the switch, and configure portal-free rules to allow
user packets destined for the IP address of the WPAD server to pass without authentication.
You must add the port numbers of the Web proxy servers on the switch and users must make sure their
browsers that use a Web proxy server do not use the proxy server for the listening IP address of the local
portal server. Thus, HTTP packets that the portal user sends to the local portal server are not sent to the
Web proxy server.
To configure Layer 2 portal authentication to support a Web proxy:
Step
1.
2.
Enter system view.
Add a Web proxy server
port number.
Command
Remarks
system-view
N/A
portal web-proxy port port-number
By default, no Web proxy
server port number is
configured and proxied HTTP
requests cannot trigger portal
authentication.
Enabling support for portal user moving
Only Layer 2 portal authentication supports this feature.
In scenarios where there are hubs, Layer 2 switches, or APs between users and the access devices, if an
authenticated user moves from the current access port to another Layer 2-portal-authentication-enabled
port of the device without logging off, the user cannot get online when the original port is still up. The
reason is that the original port is still maintaining the authentication information of the user and the
device does not permit such a user to get online from another port by default.
140
To solve the problem described above, enable support for portal user moving on the device. Then, when
a user moves from a port of the device to another, the device provides services in either of the following
ways:
•
If the original port is still up and the two ports belong to the same VLAN, the device allows the user
to continue to access the network without re-authentication, and uses the new port information for
user accounting.
•
If the original port is down or the two ports belong to different VLANs, the device removes the
authentication information of the user from the original port and authenticates the user on the new
port.
To enable support for portal user moving:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable support for portal
user moving.
portal move-mode auto
Disabled by default
For a user with authorization information (such as authorized VLAN) configured, after the user moves
from a port to another, the switch tries to assign the authorization information to the new port. If the
operation fails, the switch deletes the user's information from the original port and re-authenticates the
user on the new port.
Specifying an Auth-Fail VLAN for portal
authentication
Only Layer 2 portal authentication supports this feature.
This task sets the Auth-Fail VLAN to be assigned to users failing portal authentication. You can specify
different Auth-Fail VLANs for portal authentication on different ports. A port can be specified with only
one Auth-Fail VLAN for portal authentication.
Before specifying an Auth-Fail VLAN, be sure to create the VLAN.
To specify an Auth-Fail VLAN for portal authentication:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter Layer 2 Ethernet
interface view.
interface interface-type
interface-number
N/A
3.
Specify an Auth-Fail VLAN for
portal authentication on the
port.
portal auth-fail vlan authfail-vlan-id
Not specified by default
After you specify an Auth-Fail VLAN for portal authentication on a port, you must also enable the
MAC-based VLAN function on the port to make the specified Auth-Fail VLAN take effect. For information
about MAC VLAN, see Layer 2—LAN Switching Configuration Guide.
141
The MAC-VLAN entries generated in response to portal authentication failures do not overwrite the
MAC-VLAN entries already generated in other authentication modes.
Configuring RADIUS related attributes
Only Layer 3 portal authentication supports this feature.
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 (BAS, the portal
authentication access device) and a portal client, the BAS may not be able to obtain a user's correct
access port information. For example, for a wireless client using portal authentication, the access port
type obtained by the BAS may be the type of the wired port that authenticates the user. To make sure that
the BAS delivers the right access port information to the RADIUS server, specify the NAS-Port-Type
according to the practical access environment.
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
3.
Specify the NAS-Port-Type
value for the interface.
portal nas-port-type { ethernet |
wireless }
Not configured by default
Specifying a NAS ID profile for an interface
In some networks, users' access points are identified by their access VLANs. Network carriers need to
use NAS-identifiers to identify user access points. With a 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 that of the NAS-identifier attribute
in the RADIUS packets to be sent to the RADIUS server.
A 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,
the switch uses the device name as the interface NAS ID.
To configure a NAS ID profile for an interface:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
142
Step
Command
Remarks
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.
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 to be sent:
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 { ipv4-address | ipv6
ipv6-address }
By default, no source IP address is
specified for outgoing portal
packets and the IP address of the
user logon interface is used as the
source IP address of the outgoing
portal packets.
In NAT environments, HP
recommends specifying the
interface's public IP address as the
source IP address of outgoing
portal packets.
Configuring portal stateful failover
Only Layer 3 portal authentication supports this feature.
To implement stateful failover for portal, configure VRRP for traffic switchover, and perform the following
configurations for service backup on each of the two devices that back up each other:
143
•
Specify an interface for backing up portal services, which is called portal service backup interface
in this document, and enable portal on the portal service backup interface.
•
Specify the portal group to which the portal service backup interface belongs. Be sure to specify the
same portal group for the portal service backup interfaces that back up each other on the two
devices.
•
Specify the device ID. Make sure that the device ID of the local device is different from that of the
peer device.
•
Specify the backup source IP address for RADIUS packets to be sent as the source IP address for
RADIUS packets that is configured on the peer device, so that the peer device can receive packets
from the server. (This configuration is optional.)
•
Specify the backup VLAN, and enable stateful failover. For related configuration, see High
Availability Configuration Guide.
After the working state of the two devices changes from independence to synchronization and the portal
group takes effect, the two devices start to back up the data of online portal users for each other.
The AAA and portal configuration must be consistent on the two devices that back up each other. For
example, you must configure the same portal server on the two devices.
To configure stateful failover:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
3.
4.
5.
6.
By default, the portal service
backup interface does not belong
to any portal group.
Specify the portal group to
which the portal service
backup interface belongs.
portal backup-group group-id
The portal service backup
interfaces on the two devices for
stateful failover must belong to the
same portal group.
Return to system view.
quit
N/A
Specify the device ID in
stateful failover mode.
nas device-id device-id
Specify the backup source IP
radius nas-backup-ip ip-address
144
By default, the device operates in
stand-alone mode, and thus has no
device ID configured.
For more information about the
command, see Security Command
Reference.
Optional.
Step
Command
address for RADIUS packets
to be sent.
Remarks
Use either approach.
By default, no backup source IP
address is specified.
radius scheme
radius-scheme-name
nas-backup-ip ip-address
You do not need to specify the
backup source IP address if the
device uses the virtual IP address of
the VRRP group to which the uplink
belongs as the source IP address of
outgoing RADIUS packets.
For more information about the
command, see Security Command
Reference.
After you configure portal stateful failover for two devices, note the following issues:
•
In stateful failover mode, the device does not support re-DHCP portal authentication on the portal
service backup interface.
•
In stateful failover mode, if a user on either device is logged out, the information of the user on the
other device is deleted, too. You can log off a user on the device or on the portal server. For example,
you can use the cut connection and portal delete-user commands on the device to log off users.
•
Specifying or changing the device ID of a device will log off all online users on the device. Therefore,
perform the configuration only when necessary and, after the configuration, save the configuration
and restart the device.
•
Do not delete the configured backup source IP addresses. Otherwise, online users on the backup
device may not be able to receive packets from the server.
Specifying an auto redirection URL for
authenticated portal users
After a user passes portal authentication, if the access device is configured with an auto redirection URL,
it redirects the user to the URL after a specified period of time.
Follow these guidelines to specify an auto redirection URL for authenticated portal users:
•
To use this feature for remote Layer 3 portal authentication, the portal server must be the IMC portal
server that supports the page auto-redirection function.
•
The wait-time period option is effective to only local portal authentication.
•
When no auto redirection URL is specified for authenticated portal users, an authenticated user is
usually redirected to the URL the user typed in the address bar before portal authentication.
However, with local portal authentication, if the URL a user typed in the address bar before portal
authentication is more than 255 characters, the user cannot be redirected to the page of the URL
after passing portal authentication.
To specify an auto redirection URL for authenticated portal users:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
145
Step
Specify an auto redirection
URL for authenticated portal
users.
2.
Command
Remarks
portal redirect-url url-string [ wait-time
period ]
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 2 portal user detection
Only Layer 2 portal authentication supports this feature.
After a Layer 2 portal user gets online, the device starts a detection timer for the user, and checks whether
the user's MAC address entry has been aged out or the user's MAC address entry has been matched (a
match means a packet has been received from the user) at the interval. If the device finds no MAC
address entry for the user or receives no packets from the user during two successive detection intervals,
the device considers that the user has gone offline and clears the authentication information of the user.
To set the Layer 2 portal user detection interval:
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 Layer 2 portal user
detection interval.
portal offline-detect interval
offline-detect-interval
300 seconds by default
Configuring the portal server detection function
Only Layer 3 portal authentication supports this feature.
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 must be able to detect the reachability changes of the portal
server quickly and take corresponding actions to deal with the changes. For example, after the access
device detects that the portal server is unreachable, it 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.
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.
146
{
2.
Probe parameters
{
{
3.
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 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 network management server (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:
Step
1.
2.
Command
Remarks
Enter system view.
system-view
N/A
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
147
portal server heartbeat interval. HP recommends configuring the interval to be greater than the portal
server heartbeat interval configured on the portal server.
Configuring portal user information synchronization
Only Layer 3 portal authentication supports this feature.
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
1.
Enter system view.
Command
Remarks
system-view
N/A
Not configured by default.
2.
Configure the portal user
information synchronization
function.
portal server server-name user-sync
[ interval interval ] [ retry retries ]
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 the product of interval and retry is greater than or equal to the portal user
heartbeat interval. HP recommends that you configure 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.
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:
148
Step
Command
1.
Enter system view.
system-view
2.
Log off users.
portal delete-user { ipv4-address | all | interface
interface-type interface-number | ipv6 ipv6-address }
Displaying and maintaining portal
Task
Command
Remarks
Display the ACLs on an 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
an interface.
display portal interface
interface-type interface-number [ |
{ begin | exclude | include }
regular-expression ]
Available in any view
Display configuration information
about the local portal server.
display portal local-server [ |
{ 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
149
Task
Command
Remarks
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
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 45:
•
The host is directly connected to the switch and the switch is configured for direct authentication. The
host is assigned with a public network IP address either manually or through DHCP. Before passing
portal authentication, users can access only the portal server. After passing portal authentication,
users can access Internet resources.
•
A RADIUS server serves as the authentication, authorization, and accounting server.
Figure 45 Network diagram
Portal server
Vlan-int100
2.2.2.1/24
Host
Vlan-int2
192.168.0.100/24
192.168.0.111/24
Switch
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, switch, and servers as shown in Figure 45 and make sure they can
reach each other.
Configure the RADIUS server properly to provide authentication and accounting functions for users.
Configuring the portal server (IMC PLAT 5.0)
This example assumes that the portal server runs on IMC PLAT 5.0(E0101) and IMC UAM 5.0(E0101).
# Configure the portal server.
Log in to IMC and select the Service tab. Then, select User Access Manager > Portal Service
Management > Server from the navigation tree to enter the portal server configuration page, as shown
in Figure 46.
•
Configure the portal server parameters as needed. This example uses the default settings.
150
Figure 46 Portal server configuration
# Configure the IP address group.
Select User Access Manager > Portal Service Management > IP Group from the navigation tree to enter
the portal IP address group configuration page. Then, click Add to enter the page shown in Figure 47.
•
Enter the IP group name.
•
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.
•
Select a service group. By default, the group Ungrouped is used.
•
Select the IP group type Normal.
Figure 47 Adding an IP address group
# Add a portal device.
151
Select User Access Manager > Portal Service Management > Device from the navigation tree to enter the
portal device configuration page. Then, click Add to enter the page shown in Figure 48.
•
Enter the device name NAS.
•
Enter the IP address of the switch's interface connected to the user.
•
Enter the key, which must be the same as that configured on the switch.
•
Set whether to enable IP address reallocation. This example uses direct portal authentication, and
therefore select No from the Reallocate IP list.
•
Select whether to support sever heartbeat and user heartbeat functions. In this example, select No
for both Support Server Heartbeat and Support User Heartbeat.
Figure 48 Adding a portal device
# Associate the portal device with the IP address group.
As shown in Figure 49, click the icon in the Port Group Information Management column of device NAS
to enter the port group configuration page.
Figure 49 Device list
On the port group configuration page, click Add to enter the page shown in Figure 50. Perform the
following configurations:
•
Enter the port group name.
•
Select the configured IP address group. The IP address used by the user to access the network must
be within this IP address group.
•
Use the default settings for other parameters.
152
Figure 50 Adding a port group
# Select User Access Manager > Service Parameters > Validate System Configuration from the
navigation tree to validate the configurations.
Configuring the switch
1.
Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<Switch> system-view
[Switch] radius scheme rs1
# Set the server type for the RADIUS scheme. When using the IMC server, set the server type to
extended.
[Switch-radius-rs1] server-type extended
# Specify the primary authentication server and primary accounting server, and configure the keys
for communication with the servers.
[Switch-radius-rs1] primary authentication 192.168.0.112
[Switch-radius-rs1] primary accounting 192.168.0.112
[Switch-radius-rs1] key authentication simple radius
[Switch-radius-rs1] key accounting simple radius
# Specify that the ISP domain name should not be included in the username sent to the RADIUS
server.
[Switch-radius-rs1] user-name-format without-domain
[Switch-radius-rs1] quit
2.
Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[Switch] domain dm1
# Configure AAA methods for the ISP domain.
[Switch-isp-dm1] authentication portal radius-scheme rs1
[Switch-isp-dm1] authorization portal radius-scheme rs1
[Switch-isp-dm1] accounting portal radius-scheme rs1
[Switch-isp-dm1] quit
153
# Configure dm1 as the default ISP domain for all users. Then, if a user enters the username without
the ISP domain at logon, the authentication and accounting methods of the default domain are
used for the user.
[Switch] domain default enable dm1
3.
Configure portal authentication:
# Configure a portal server on the switch, making sure the IP address, port number and URL match
those of the actual portal server.
[Switch] 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.
[Switch] interface vlan-interface 100
[Switch–Vlan-interface100] portal server newpt method direct
[Switch–Vlan-interface100] quit
Configuring re-DHCP portal authentication
Network requirements
As shown in Figure 51:
•
The host is directly connected to the switch and the switch is configured for re-DHCP authentication.
The host is assigned with an IP address through the DHCP server. Before passing portal
authentication, the host uses an assigned private IP address. After passing portal authentication, the
host can get a public IP address and access Internet resources.
•
A RADIUS server serves as the authentication/accounting server.
Figure 51 Network diagram
Configuration procedure
When you configure re-DHCP portal authentication, follow these guidelines:
•
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)
•
The switch 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
154
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.
•
Configure IP addresses for the switch and servers as shown in Figure 51 and make sure that the host,
switch, and servers can reach each other.
•
Configure the RADIUS server properly to provide authentication and accounting functions for users.
Perform the following configuration to configure re-DHCP authentication on the switch:
1.
Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<Switch> system-view
[Switch] radius scheme rs1
# Set the server type for the RADIUS scheme. When using the IMC server, set the server type to
extended.
[Switch-radius-rs1] server-type extended
# Specify the primary authentication server and primary accounting server, and configure the keys
for communication with the servers.
[Switch-radius-rs1] primary authentication 192.168.0.113
[Switch-radius-rs1] primary accounting 192.168.0.113
[Switch-radius-rs1] key authentication simple radius
[Switch-radius-rs1] key accounting simple radius
# Specify that the ISP domain name should not be included in the username sent to the RADIUS
server.
[Switch-radius-rs1] user-name-format without-domain
[Switch-radius-rs1] quit
2.
Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[Switch] domain dm1
# Configure AAA methods for the ISP domain.
[Switch-isp-dm1] authentication portal radius-scheme rs1
[Switch-isp-dm1] authorization portal radius-scheme rs1
[Switch-isp-dm1] accounting portal radius-scheme rs1
[Switch-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 and accounting methods of the
default domain are used for the user.
[Switch] 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
155
{
Port number: 50100
{
URL: http://192.168.0.111:8080/portal
[Switch] portal server newpt ip 192.168.0.111 key simple portal port 50100 url
http://192.168.0.111:8080/portal
# Configure the switch as a DHCP relay agent, and enable the IP address check function.
[Switch] dhcp enable
[Switch] dhcp relay server-group 0 ip 192.168.0.112
[Switch] interface vlan-interface 100
[Switch–Vlan-interface100] ip address 20.20.20.1 255.255.255.0
[Switch–Vlan-interface100] ip address 10.0.0.1 255.255.255.0 sub
[Switch-Vlan-interface100] dhcp select relay
[Switch-Vlan-interface100] dhcp relay server-select 0
[Switch-Vlan-interface100] dhcp relay address-check enable
# Enable re-DHCP portal authentication on the interface connecting the host.
[Switch–Vlan-interface100] portal server newpt method redhcp
[Switch–Vlan-interface100] quit
Configuring cross-subnet portal authentication
Network requirements
As shown in Figure 52:
•
Switch A is configured for cross-subnet portal authentication. Before passing portal authentication,
the host can access only the portal server. After passing portal authentication, the host can access
Internet resources.
•
The host accesses Switch A through Switch B.
•
A RADIUS server serves as the authentication/accounting server.
Figure 52 Network diagram
Configuration procedure
When configuring cross-subnet portal authentication, follow these guidelines:
•
Configure IP addresses for the host, switches, and servers as shown in Figure 52 and make sure they
can reach each other.
•
Configure the RADIUS server properly to provide authentication and accounting functions for users.
156
•
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).
Perform the following configuration to configure cross-subnet portal authentication on Switch A:
1.
Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<SwitchA> system-view
[SwitchA] radius scheme rs1
# Set the server type for the RADIUS scheme. When using the IMC server, set it to extended.
[SwitchA-radius-rs1] server-type extended
# Specify the primary authentication server and primary accounting server, and configure the keys
for communication with the servers.
[SwitchA-radius-rs1] primary authentication 192.168.0.112
[SwitchA-radius-rs1] primary accounting 192.168.0.112
[SwitchA-radius-rs1] key authentication simple radius
[SwitchA-radius-rs1] key accounting simple radius
# Specify that the ISP domain name should not be included in the username sent to the RADIUS
server.
[SwitchA-radius-rs1] user-name-format without-domain
[SwitchA-radius-rs1] quit
2.
Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[SwitchA] domain dm1
# Configure AAA methods for the ISP domain.
[SwitchA-isp-dm1] authentication portal radius-scheme rs1
[SwitchA-isp-dm1] authorization portal radius-scheme rs1
[SwitchA-isp-dm1] accounting portal radius-scheme rs1
[SwitchA-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 and accounting methods of the
default domain are used for the user.
[SwitchA] 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
[SwitchA] 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 Switch B.
[SwitchA] interface vlan-interface 4
[SwitchA–Vlan-interface4] portal server newpt method layer3
[SwitchA–Vlan-interface4] quit
157
On Switch 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 53:
•
The host is directly connected to the switch and the switch is configured for direct extended portal
authentication. The host is assigned with a public network IP address either manually or through
DHCP. If the host fails security check after passing identity authentication, the host can access only
subnet 192.168.0.0/24. After passing security check, the host can access Internet resources.
•
A RADIUS server serves as the authentication/accounting server.
Figure 53 Network diagram
Configuration procedure
Configure IP addresses for the host, switch, and servers as shown in Figure 53 and make sure they can
reach each other.
Configure the RADIUS server properly to provide authentication and accounting functions for users.
Configure the switch:
1.
Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<Switch> system-view
[Switch] radius scheme rs1
# Set the server type for the RADIUS scheme. When using the IMC server, set the server type to
extended.
[Switch-radius-rs1] server-type extended
# Specify the primary authentication server and primary accounting server, and configure the keys
for communication with the servers.
[Switch-radius-rs1] primary authentication 192.168.0.112
[Switch-radius-rs1] primary accounting 192.168.0.112
[Switch-radius-rs1] key accounting simple radius
158
[Switch-radius-rs1] key authentication simple radius
[Switch-radius-rs1] user-name-format without-domain
# Configure the IP address of the security policy server.
[Switch-radius-rs1] security-policy-server 192.168.0.113
[Switch-radius-rs1] quit
2.
Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[Switch] domain dm1
# Configure AAA methods for the ISP domain.
[Switch-isp-dm1] authentication portal radius-scheme rs1
[Switch-isp-dm1] authorization portal radius-scheme rs1
[Switch-isp-dm1] accounting portal radius-scheme rs1
[Switch-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 and accounting methods of the
default domain are used for the user.
[Switch] 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:
[Switch] acl number 3000
[Switch-acl-adv-3000] rule permit ip destination 192.168.0.0 0.0.0.255
[Switch-acl-adv-3000] rule deny ip
[Switch-acl-adv-3000] quit
[Switch] acl number 3001
[Switch-acl-adv-3001] rule permit ip
[Switch-acl-adv-3001] quit
On the security policy server, specify ACL 3000 as the isolation ACL and ACL 3001 as the security
ACL.
4.
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
[Switch] 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.
[Switch] interface vlan-interface 100
[Switch–Vlan-interface100] portal server newpt method direct
[Switch–Vlan-interface100] quit
159
Configuring re-DHCP portal authentication with extended
functions
Network requirements
As shown in Figure 54:
•
The host is directly connected to the switch and the switch is configured for re-DHCP authentication.
The host is assigned with an IP address through the DHCP server. Before passing portal
authentication, the host uses an assigned private IP address. After passing portal authentication, the
host can get a public IP address.
•
If the host fails security check after passing identity authentication, the host can access only subnet
192.168.0.0/24. After passing the security check, the host can access Internet resources.
•
A RADIUS server serves as the authentication/accounting server.
Figure 54 Network diagram
Portal server
192.168.0.111/24
Vlan-int100
20.20.20.1/24
10.0.0.1/24 sub
Host
automatically obtains
an IP address
Vlan-int2
192.168.0.100/24
DHCP server
192.168.0.112/24
Switch
RADIUS server
192.168.0.113/24
Security policy server
192.168.0.114/24
Configuration procedure
When you configure re-DHCP portal authentication, follow these guidelines:
•
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 switch 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.
•
Configure IP addresses for the switch and servers as shown in Figure 54 and make sure that the host,
switch, and servers can reach each other.
•
Configure the RADIUS server properly to provide authentication and accounting functions for users.
160
Perform the following configuration to configure re-DHCP portal authentication with extended functions
on the switch:
1.
Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<Switch> system-view
[Switch] radius scheme rs1
# Set the server type for the RADIUS scheme. When using the IMC server, set the server type to
extended.
[Switch-radius-rs1] server-type extended
# Specify the primary authentication server and primary accounting server, and configure the keys
for communication with the servers.
[Switch-radius-rs1] primary authentication 192.168.0.113
[Switch-radius-rs1] primary accounting 192.168.0.113
[Switch-radius-rs1] key accounting simple radius
[Switch-radius-rs1] key authentication simple radius
[Switch-radius-rs1] user-name-format without-domain
# Configure the IP address of the security policy server.
[Switch-radius-rs1] security-policy-server 192.168.0.114
[Switch-radius-rs1] quit
2.
Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[Switch] domain dm1
# Configure AAA methods for the ISP domain.
[Switch-isp-dm1] authentication portal radius-scheme rs1
[Switch-isp-dm1] authorization portal radius-scheme rs1
[Switch-isp-dm1] accounting portal radius-scheme rs1
[Switch-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 and accounting methods of the
default domain are used for the user.
[Switch] 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:
[Switch] acl number 3000
[Switch-acl-adv-3000] rule permit ip destination 192.168.0.0 0.0.0.255
[Switch-acl-adv-3000] rule deny ip
[Switch-acl-adv-3000] quit
[Switch] acl number 3001
[Switch-acl-adv-3001] rule permit ip
[Switch-acl-adv-3001] quit
On the security policy server, specify ACL 3000 as the isolation ACL and ACL 3001 as the security
ACL.
4.
Configure portal authentication:
# Configure the portal server as follows:
{
Name: newpt
161
{
IP address: 192.168.0.111
{
Key: portal in plain text
{
Port number: 50100
{
URL: http://192.168.0.111:8080/portal
[Switch] portal server newpt ip 192.168.0.111 key simple portal port 50100
url http://192.168.0.111:8080/portal
# Configure the switch as a DHCP relay agent, and enable the IP address check function.
[Switch] dhcp enable
[Switch] dhcp relay server-group 0 ip 192.168.0.112
[Switch] interface vlan-interface 100
[Switch–Vlan-interface100] ip address 20.20.20.1 255.255.255.0
[Switch–Vlan-interface100] ip address 10.0.0.1 255.255.255.0 sub
[Switch-Vlan-interface100] dhcp select relay
[Switch-Vlan-interface100] dhcp relay server-select 0
[Switch-Vlan-interface100] dhcp relay address-check enable
# Enable re-DHCP portal authentication on the interface connecting the host.
[Switch–Vlan-interface100] portal server newpt method redhcp
[Switch–Vlan-interface100] quit
Configuring cross-subnet portal authentication with extended
functions
Network requirements
As shown in Figure 55:
•
Switch A is configured for cross-subnet extended portal authentication. If the host fails security check
after passing identity authentication, the host can access only subnet 192.168.0.0/24. After
passing security check, the host can access Internet resources.
•
The host accesses Switch A through Switch B.
•
A RADIUS server serves as the authentication/accounting server.
Figure 55 Network diagram
162
Configuration procedure
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).
Configure IP addresses for the host, switches, and servers as shown in Figure 55 and make sure that they
can reach each other.
Configure the RADIUS server properly to provide authentication and accounting functions for users.
Configure Switch A:
1.
Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<SwitchA> system-view
[SwitchA] radius scheme rs1
# Set the server type for the RADIUS scheme. When using the IMC server, set the server type to
extended.
[SwitchA-radius-rs1] server-type extended
# Specify the primary authentication server and primary accounting server, and configure the keys
for communication with the servers.
[SwitchA-radius-rs1] primary authentication 192.168.0.112
[SwitchA-radius-rs1] primary accounting 192.168.0.112
[SwitchA-radius-rs1] key accounting simple radius
[SwitchA-radius-rs1] key authentication simple radius
[SwitchA-radius-rs1] user-name-format without-domain
# Configure the IP address of the security policy server.
[SwitchA-radius-rs1] security-policy-server 192.168.0.113
[SwitchA-radius-rs1] quit
2.
Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[SwitchA] domain dm1
# Configure AAA methods for the ISP domain.
[SwitchA-isp-dm1] authentication portal radius-scheme rs1
[SwitchA-isp-dm1] authorization portal radius-scheme rs1
[SwitchA-isp-dm1] accounting portal radius-scheme rs1
[SwitchA-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 and accounting methods of the
default domain are used for the user.
[SwitchA] 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:
[SwitchA] acl number 3000
[SwitchA-acl-adv-3000] rule permit ip destination 192.168.0.0 0.0.0.255
[SwitchA-acl-adv-3000] rule deny ip
[SwitchA-acl-adv-3000] quit
[SwitchA] acl number 3001
[SwitchA-acl-adv-3001] rule permit ip
163
[SwitchA-acl-adv-3001] quit
On the security policy server, specify ACL 3000 as the isolation ACL and ACL 3001 as the security
ACL.
4.
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
[SwitchA] portal server newpt ip 192.168.0.111 key portal port 50100 url
http://192.168.0.111:8080/portal
# Enable portal authentication on the interface connecting Switch B.
[SwitchA] interface vlan-interface 4
[SwitchA–Vlan-interface4] portal server newpt method layer3
[SwitchA–Vlan-interface4] quit
On Switch 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 stateful failover
Network requirements
As shown in Figure 56, a failover link is present between Switch A and Switch B. Both Switch A and
Switch B support portal authentication. Configure stateful failover between Switch A and Switch B to
support portal service backup and use VRRP to implement traffic switchover between the switches. More
specifically,
•
When Switch A works normally, Host accesses Switch A for portal authentication before accessing
the Internet; when Switch A fails, Host accesses the Internet through Switch B. The VRRP
uplink/downlink detection mechanism is used to ensure non-stop traffic forwarding.
•
Use the RADIUS server as the authentication/accounting server. In this example, Server takes the
responsibilities of the portal server and the RADIUS server.
•
Switch A and Switch B use the failover link to transmit stateful failover related packets and specify
VLAN 8 on the switches as the VLAN dedicated for stateful failover related packets.
164
Figure 56 Network diagram
Configure IP addresses for the host, server, and switches as shown in Figure 56 and make sure that they
can reach to each other.
Make sure that Host can access the authentication server through Switch A and Switch B.
Configure VRRP group 1 and VRRP group 2 to implement backup for downstream and upstream links,
respectively. For more information about VRRP, see High Availability Configuration Guide.
For information about stateful failover configuration, see High Availability Configuration Guide.
Configuring the portal server (IMC PLAT 5.0)
This example assumes that the portal server runs on IMC PLAT 5.0(E0101) and IMC UAM 5.0(E0101).
# Configure the portal server.
Log in to IMC and select the Service tab. Then, select User Access Manager > Portal Service
Management > Server from the navigation tree to enter the portal server configuration page, as shown
in Figure 57.
Configure the portal server parameters as needed. This example uses the default settings.
165
Figure 57 Portal server configuration
# Configure the IP address group.
Select User Access Manager > Portal Service Management > IP Group from the navigation tree to enter
the portal IP address group configuration page. Then, click Add to enter the page shown in Figure 47.
•
Enter the IP group name.
•
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.
•
Select a service group. By default, the group Ungrouped is used.
•
Select the IP group type Normal.
Figure 58 Adding an IP address group
# Add a portal device.
Select User Access Manager > Portal Service Management > Device from the navigation tree to enter the
portal device configuration page. Then, click Add to enter the page shown in Figure 48.
166
•
Enter the device name NAS.
•
Enter the virtual IP address of the VRRP group that holds the portal-enabled interface.
•
Enter the key, which must be the same as that configured on the switch.
•
Set whether to enable IP address reallocation. This example uses direct portal authentication, and
therefore select No from the Reallocate IP list.
•
Select whether to support sever heartbeat and user heartbeat functions. In this example, select No
for both Support Server Heartbeat and Support User Heartbeat.
Figure 59 Adding a portal device
# Associate the portal device with the IP address group.
As shown in Figure 49, click the icon in the Port Group Information Management column of device NAS
to enter the port group configuration page.
Figure 60 Device list
On the port group configuration page, click Add to enter the page shown in Figure 50. Perform the
following configurations:
•
Enter the port group name.
•
Select the configured IP address group. The IP address used by the user to access the network must
be within this IP address group.
•
Use the default settings for other parameters.
167
Figure 61 Adding a port group
# Select User Access Manager > Service Parameters > Validate System Configuration from the
navigation tree to validate the configurations.
Configuring Switch A
1.
Configure VRRP:
# Create VRRP group 1, and configure the virtual IP address of the VRRP group 1 as 9.9.1.1.
<SwitchA> system-view
[SwitchA] interface vlan-interface 10
[SwitchA–Vlan-interface10] vrrp vrid 1 virtual-ip 9.9.1.1
# Set the priority of VLAN-interface 10 in VRRP group 1 to 200.
[SwitchA–Vlan-interface10] vrrp vrid 1 priority 200
# On VLAN-interface 10, configure the interface to be tracked as VLAN-interface 20 and reduce
the priority of VLAN-interface 10 in VRRP group 1 by 150 when the interface state of
VLAN-interface 20 becomes Down or Removed.
[SwitchA–Vlan-interface10] vrrp vrid 1 track interface vlan-interface20 reduced 150
[SwitchA–Vlan-interface10] quit
# Create VRRP group 2, and configure the virtual IP address of the VRRP group 2 as 192.168.0.1.
[SwitchA] interface vlan-interface 20
[SwitchA–Vlan-interface20] vrrp vrid 2 virtual-ip 192.168.0.1
# Set the priority of VLAN-interface 20 in VRRP group 2 to 200.
[SwitchA–Vlan-interface20] vrrp vrid 2 priority 200
# On VLAN-interface 20, configure the interface to be tracked as VLAN-interface 10 and reduce
the priority of VLAN-interface 20 in VRRP group 2 by 150 when the interface state of
VLAN-interface 10 becomes Down or Removed.
[SwitchA–Vlan-interface20] vrrp vrid 2 track interface vlan-interface10 reduced 150
[SwitchA–Vlan-interface20] quit
2.
Configure a RADIUS scheme:
# Create RADIUS scheme rs1 and enter its view.
[SwitchA] radius scheme rs1
168
# Configure the server type for the RADIUS scheme. When using the IMC server, configure the
RADIUS server type as extended.
[SwitchA-radius-rs1] server-type extended
# Specify the primary authentication server and primary accounting server, and configure the keys
for communication with the servers.
[SwitchA-radius-rs1] primary authentication 192.168.0.111
[SwitchA-radius-rs1] primary accounting 192.168.0.111
[SwitchA-radius-rs1] key authentication simple expert
[SwitchA-radius-rs1] key accounting simple expert
# Configure the access device to not carry the ISP domain name in the username sent to the
RADIUS server. (Optional, configure the username format as needed.)
[SwitchA-radius-rs1] user-name-format without-domain
[SwitchA-radius-rs1] quit
3.
Configure an authentication domain:
# Create ISP domain dm1 and enter its view.
[SwitchA] domain dm1
# Configure AAA methods for the ISP domain.
[SwitchA-isp-dm1] authentication portal radius-scheme rs1
[SwitchA-isp-dm1] authorization portal radius-scheme rs1
[SwitchA-isp-dm1] accounting portal radius-scheme rs1
[SwitchA-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 and accounting methods of the default
domain are used for the user.
[SwitchA] domain default enable dm1
4.
Enable portal authentication on the interface connecting the host:
# Configure a portal server on the switch, making sure the IP address, port number and URL match
those of the actual portal server.
[SwitchA] 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.
[SwitchA] interface vlan-interface 10
[SwitchA–Vlan-interface10] portal server newpt method layer3
# Specify the source IP address of outgoing portal packets as 9.9.1.1, the virtual IP address of
VRRP group 1.
[SwitchA–Vlan-interface10] portal nas-ip 9.9.1.1
5.
Configure portal stateful failover:
# Assign interface VLAN-interface 10 to portal group 1.
[SwitchA–Vlan-interface10] portal backup-group 1
[SwitchA–Vlan-interface10] quit
# Set the device ID for Switch A in stateful failover mode to 1.
[SwitchA] nas device-id 1
# Specify the source IP address of outgoing RADIUS packets as 192.168.0.1, the virtual IP
address of VRRP group 2.
[SwitchA] radius nas-ip 192.168.0.1
Make sure you have added the access device with IP address 192.168.0.1 on the RADIUS server.
169
6.
Configure the stateful failover function:
# Configure the VLAN for stateful failover as VLAN 8.
[SwitchA] dhbk vlan 8
# Enable stateful failover and configure it to support the symmetric path.
[SwitchA] dhbk enable backup-type symmetric-path
Configuring Switch B
1.
Configure VRRP:
# Create VRRP group 1, and configure the virtual IP address of the VRRP group 1 as 9.9.1.1.
<SwitchB> system-view
[SwitchB] interface vlan-interface 10
[SwitchB–Vlan-interface10] vrrp vrid 1 virtual-ip 9.9.1.1
# Set the priority of VLAN-interface 10 in VRRP group 1 to 150.
[SwitchB–Vlan-interface10] vrrp vrid 1 priority 150
[SwitchB–Vlan-interface10] quit
# Create VRRP group 2, and configure the virtual IP address of the VRRP group 2 as 192.168.0.1.
[SwitchB] interface vlan-interface 20
[SwitchB–Vlan-interface20] vrrp vrid 2 virtual-ip 192.168.0.1
# Set the priority of VLAN-interface 20 in VRRP group 2 to 150.
[SwitchB–Vlan-interface20] vrrp vrid 2 priority 150
[SwitchB–Vlan-interface20] quit
2.
Configure a RADIUS scheme:
# Create RADIUS scheme rs1 and enter its view.
[SwitchB] radius scheme rs1
# Configure the server type for the RADIUS scheme. When using the IMC server, configure the
RADIUS server type as extended.
[SwitchB-radius-rs1] server-type extended
# Specify the primary authentication server and primary accounting server, and configure the keys
for communication with the servers.
[SwitchB-radius-rs1] primary authentication 192.168.0.111
[SwitchB-radius-rs1] primary accounting 192.168.0.111
[SwitchB-radius-rs1] key authentication simple expert
[SwitchB-radius-rs1] key accounting simple expert
# Configure the access device to not carry the ISP domain name in the username sent to the
RADIUS server. (Optional, configure the username format as needed.)
[SwitchB-radius-rs1] user-name-format without-domain
[SwitchB-radius-rs1] quit
3.
Configure an authentication domain:
# Create ISP domain dm1 and enter its view.
[SwitchB] domain dm1
# Configure AAA methods for the ISP domain.
[SwitchB-isp-dm1] authentication portal radius-scheme rs1
[SwitchB-isp-dm1] authorization portal radius-scheme rs1
[SwitchB-isp-dm1] accounting portal radius-scheme rs1
[SwitchB-isp-dm1] quit
170
# 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 and accounting methods of the default
domain are used for the user.
[SwitchB] domain default enable dm1
4.
Enable portal authentication on the interface connecting the host:
# Configure the portal server as needed.
[SwitchB] 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.
[SwitchB] interface vlan-interface 10
[SwitchB–Vlan-interface10] portal server newpt method layer3
# Specify the source IP address of outgoing portal packets as 9.9.1.1, the virtual IP address of
VRRP group 1.
[SwitchA–Vlan-interface10] portal nas-ip 9.9.1.1
5.
Configure portal stateful failover:
# Assign interface VLAN-interface 10 to portal group 1.
[SwitchB–Vlan-interface10] portal backup-group 1
[SwitchB–Vlan-interface10] quit
# Set the ID of the device in the stateful failover mode to 2.
[SwitchB] nas device-id 2
# Specify the source IP address of outgoing RADIUS packets as 192.168.0.1, the virtual IP
address of VRRP group 2.
[SwitchB] radius nas-backup-ip 192.168.0.1
Make sure you have added the access device with IP address 192.168.0.1 on the RADIUS server.
6.
Configure stateful failure:
# Configure the VLAN for stateful failover as VLAN 8.
[SwitchB] dhbk vlan 8
# Enable stateful failover and configure it to support the symmetric path.
[SwitchB] dhbk enable backup-type symmetric-path
Verifying the configuration
# After user Host logs in through Switch A, display the user authentication information by using the
display portal user command on Switch A and Switch B.
[SwitchA] display portal user all
Index:3
State:ONLINE
SubState:NONE
ACL:NONE
Work-mode: primary
VPN instance:NONE
MAC
IP
Vlan
Interface
--------------------------------------------------------------------000d-88f8-0eac
9.9.1.2
10
Total 1 user(s) matched, 1 listed.
[SwitchB] display portal user all
Index:2
171
Vlan-interface10
State:ONLINE
SubState:NONE
ACL:NONE
Work-mode: secondary
VPN instance:NONE
MAC
IP
Vlan
Interface
--------------------------------------------------------------------000d-88f8-0eac
9.9.1.2
10
Vlan-interface10
Total 1 user(s) matched, 1 listed.
The output shows that the information of user Host is saved on both Switch A and Switch B. The user's
working mode on Switch A is primary, and that on Switch B is secondary, which indicate that the user
logged in through Switch A and the user information on Switch B was synchronized from Switch A.
Configuring portal server detection and portal user information
synchronization
Network requirements
As shown in Figure 62, a host is directly connected to a switch (the access device) and must pass portal
authentication before it can access the Internet. A RADIUS server serves as the
authentication/accounting 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 (Switch) can detect whether the portal server is reachable and send trap
messages upon state changes. When the portal server is unreachable due to a connection failure,
network device failure, or portal server failure, for example, 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 62 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 accounting.
172
3.
Configure direct portal authentication on interface VLAN-interface 100, which is connected with
the user 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.
Configure IP addresses for the host, switch, and servers as shown in Figure 62 and make sure that they
can reach each other.
Configure the RADIUS server properly to provide authentication and accounting functions for users.
Configuring the portal server (IMC PLAT 5.0)
This example assumes that the portal server runs IMC PLAT 5.0(E0101) and IMC UAM 5.0(E0101).
# Configure the portal server.
Log in to IMC and select the Service tab. Then, select User Access Manager > Portal Service
Management > Server from the navigation tree to enter the portal server configuration page, as shown
in Figure 63.
•
Configure the portal server heartbeat interval and user heartbeat interval.
•
Use the default value for other parameters.
Figure 63 Portal server configuration
# Configure the IP address group.
Select User Access Manager > Portal Service Management > IP Group from the navigation tree to enter
the portal IP address group configuration page. Then, click Add to enter the page shown in Figure 47.
•
Enter the IP group name.
173
•
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.
•
Select a service group. By default, the group Ungrouped is used.
•
Select the IP group type Normal.
Figure 64 Adding an IP address group
# Add a portal device.
Select User Access Manager > Portal Service Management > Device from the navigation tree to enter the
portal device configuration page. Then, click Add to enter the page shown in Figure 48.
•
Enter the device name NAS.
•
Enter the IP address of the switch's interface connected to the user.
•
Enter the key, which must be the same as that configured on the switch.
•
Set whether to enable IP address reallocation. This example uses direct portal authentication, and
therefore select No from the Reallocate IP list.
•
Set whether to support the portal server heartbeat and user heartbeat functions. In this example,
select Yes for both Support Server Heartbeat and Support User Heartbeat.
Figure 65 Adding a portal device
174
# Associate the portal device with the IP address group.
As shown in Figure 49, click the icon in the Port Group Information Management column of device NAS
to enter the port group configuration page.
Figure 66 Device list
On the port group configuration page, click Add to enter the page shown in Figure 50. Perform the
following configurations:
•
Enter the port group name.
•
Select the configured IP address group. The IP address used by the user to access the network must
be within this IP address group.
•
Use the default settings for other parameters.
Figure 67 Adding a port group
# Select User Access Manager > Service Parameters > Validate System Configuration from the
navigation tree to validate the configurations.
Configure the switch
1.
Configure a RADIUS scheme:
# Create RADIUS scheme rs1 and enter its view.
<Switch> system-view
[Switch] radius scheme rs1
# Configure the server type for the RADIUS scheme. When using the IMC server, configure the
RADIUS server type as extended.
[Switch-radius-rs1] server-type extended
175
# Specify the primary authentication server and primary accounting server, and configure the keys
for communication with the servers.
[Switch-radius-rs1] primary authentication 192.168.0.112
[Switch-radius-rs1] primary accounting 192.168.0.112
[Switch-radius-rs1] key authentication simple radius
[Switch-radius-rs1] key accounting simple radius
# Configure the access device to not carry the ISP domain name in the username sent to the
RADIUS server.
[Switch-radius-rs1] user-name-format without-domain
[Switch-radius-rs1] quit
2.
Configure an authentication domain:
# Create ISP domain dm1 and enter its view.
[Switch] domain dm1
# Configure AAA methods for the ISP domain.
[Switch-isp-dm1] authentication portal radius-scheme rs1
[Switch-isp-dm1] authorization portal radius-scheme rs1
[Switch-isp-dm1] accounting portal radius-scheme rs1
[Switch-isp-dm1] quit
# Configure domain dm1 as the default ISP domain for all users. Then, if a user enters a username
without the ISP domain at logon, the authentication and accounting methods of the default domain
are used for the user.
[Switch] domain default enable dm1
3.
Configure portal authentication:
# Configure a portal server on the switch, making sure that the IP address, port number and URL
match those of the actual portal server.
[Switch] 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.
[Switch] interface vlan-interface 100
[Switch–Vlan-interface100] portal server newpt method direct
[Switch–Vlan-interface100] 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.
[Switch] 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 HP recommends configuring the interval as a value greater than the portal server
heartbeat interval configured on the portal server.
5.
Configure portal user 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 in two
consecutive probe intervals.
176
[Switch] 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 HP recommends configuring the interval as a value 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:
<Switch> 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
Cross-subnet portal authentication across VPNs
Network requirements
As shown in Figure 68, Switch A, as the PE device connecting the user side, needs to provide cross-subnet
portal authentication for hosts in VPN 1 through communication with the RADIUS server and portal
server in VPN 3.
Figure 68 Network diagram
Configuration procedure
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/accounting functions for users.
Configure Switch A:
1.
Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<SwitchA> system-view
[SwitchA] radius scheme rs1
# Configure the VPN instance to which the RADIUS scheme belongs as vpn3.
[SwitchA-radius-rs1] vpn-instance vpn3
177
# Set the server type for the RADIUS scheme. When using the IMC server, set the server type to
extended.
[SwitchA-radius-rs1] server-type extended
# Specify the primary authentication server and primary accounting server, and configure the keys
for communication with the servers.
[SwitchA-radius-rs1] primary authentication 192.168.0.111
[SwitchA-radius-rs1] primary accounting 192.168.0.111
[SwitchA-radius-rs1] key accounting simple radius
[SwitchA-radius-rs1] key authentication simple radius
# Configure the device to not carry the ISP domain name in the username sent to the RADIUS
server.
[SwitchA-radius-rs1] user-name-format without-domain
# Specify the source IP address for RADIUS packets to be sent as 3.3.0.3.
[SwitchA-radius-rs1] nas-ip 3.3.0.3
[SwitchA-radius-rs1] quit
Use the nas-ip command to specify the source IP address for RADIUS packets to be sent, and make
sure that the source IP address is consistent with the IP address of the access device specified on
the server to avoid authentication failures.
2.
Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[SwitchA] domain dm1
# Configure AAA methods for the ISP domain.
[SwitchA-isp-dm1] authentication portal radius-scheme rs1
[SwitchA-isp-dm1] authorization portal radius-scheme rs1
[SwitchA-isp-dm1] accounting portal radius-scheme rs1
[SwitchA-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 and accounting methods of the default
domain will be used for the user.
[SwitchA] 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
[SwitchA] 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.
[SwitchA] interface vlan-interface 3
[SwitchA–Vlan-interface3] portal server newpt method layer3
[SwitchA–Vlan-interface3] quit
178
Verifying the configuration
Execute the display portal interface 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 Switch A.
[SwitchA] 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
3
Vlan-interface3
Total 1 user(s) matched, 1 listed.
Configuring Layer 2 portal authentication
Network requirements
As shown in Figure 69, a host is directly connected to a switch. The switch performs Layer 2 portal
authentication on users connected to port GigabitEthernet 1/0/1. More specifically,
•
Use the remote RADIUS server for authentication, authorization and accounting.
•
Use the remote DHCP server to assign IP addresses to users.
•
The listening IP address of the local portal server is 4.4.4.4. The local portal server pushes the
user-defined authentication pages to users and uses HTTPS to transmit authentication data.
•
Add users passing authentication to VLAN 3.
•
Add users failing authentication to VLAN 2, to allow the users to access resources on the update
server.
•
The host obtains an IP address through DHCP. Before authentication, the DHCP server assigns an IP
address in segment 192.168.1.0/24 to the host. When the host passes the authentication, the DHCP
server assigns an IP address in segment 3.3.3.0/24 to the host. When the host fails authentication,
the DHCP server assigns an IP address in segment 2.2.2.0/24 to the host.
179
Figure 69 Network diagram
DHCP server
RADIUS server
1.1.1.3/24
1.1.1.2/24
Vlan-int1
1.1.1.1
Vlan-int8
192.168.1.1/24
GE1/0/1
Switch (DHCP relay)
Vlan-int2
2.2.2.1/24
Host
Vlan-int3
3.3.3.1
IP network
Update server
2.2.2.2/24
Configuration procedures
Follow these guidelines to configure Layer 2 portal authentication:
•
Make sure that the host, switch, and servers can reach each other before portal authentication is
enabled.
•
Configure the RADIUS server properly to provide normal authentication/authorization/accounting
functions for users. In this example, you must create a portal user account with the account name
userpt on the RADIUS server, and configure an authorized VLAN for the account.
•
On the DHCP server, you must specify the IP address ranges (192.168.1.0/24, 3.3.3.0/24,
2.2.2.0/24), specify the default gateway addresses (192.168.1.1, 3.3.3.1, 2.2.2.1), exclude the
update server's address 2.2.2.2 from the address ranges for address allocation, specify the leases
for the assigned IP addresses and make sure there is a route to the host. To shorten the IP address
update time in case of an authentication state change, set a short lease for each address.
•
Because the DHCP server and the DHCP client are not in the same subnet, you need to configure
a DHCP relay agent on the subnet of the client. For more information about DHCP relay agent, see
Layer 3—IP Services Configuration Guide.
Perform the following configuration on the switch to implement Layer 2 portal authentication:
1.
Configure portal authentication:
# Add Ethernet ports to related VLANs and configure IP addresses for the VLAN interfaces. (Details
not shown.)
# Configure PKI domain pkidm, and apply for a local certificate and CA certificate. For more
configuration information, see "Configuring PKI."
# Edit the user-defined authentication pages file, compress it into a zip file named defaultfile, and
save the file in the root directory of the access device.
# Configure SSL server policy sslsvr, and specify to use PKI domain pkidm.
<Switch> system-view
[Switch] ssl server-policy sslsvr
[Switch-ssl-server-policy-sslsvr] pki pkidm
[Switch-ssl-server-policy-sslsvr] quit
180
# Configure the local portal server to support HTTPS and reference SSL server policy sslsvr.
[Switch] portal local-server https server-policy sslsvr
# Configure the IP address of loopback interface 12 as 4.4.4.4.
[Switch] interface loopback 12
[Switch-LoopBack12] ip address 4.4.4.4 32
[Switch-LoopBack12] quit
# Specify IP address 4.4.4.4 as the listening IP address of the local portal server for Layer 2 portal
authentication.
[Switch] portal local-server ip 4.4.4.4
# Enable portal authentication on port GigabitEthernet 1/0/1, and specify the Auth-Fail VLAN of
the port as VLAN 2.
[Switch] interface gigabitethernet 1/0/1
[Switch–GigabitEthernet1/0/1] port link-type hybrid
[Switch–GigabitEthernet1/0/1] mac-vlan enable
[Switch–GigabitEthernet1/0/1] portal local-server enable
[Switch–GigabitEthernet1/0/1] portal auth-fail vlan 2
[Switch–GigabitEthernet1/0/1] quit
2.
Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<Switch> system-view
[Switch] radius scheme rs1
# Set the server type for the RADIUS scheme. When using the IMC server, set the server type to
extended.
[Switch-radius-rs1] server-type extended
# Specify the primary authentication server and primary accounting server, and configure the keys
for communication with the servers.
[Switch-radius-rs1] primary authentication 1.1.1.2
[Switch-radius-rs1] primary accounting 1.1.1.2
[Switch-radius-rs1] key accounting simple radius
[Switch-radius-rs1] key authentication simple radius
[Switch-radius-rs1] quit
3.
Configure an authentication domain:
# Create and enter ISP domain triple.
[Switch] domain triple
# Configure AAA methods for the ISP domain.
[Switch-isp-triple] authentication portal radius-scheme rs1
[Switch-isp-triple] authorization portal radius-scheme rs1
[Switch-isp-triple] accounting portal radius-scheme rs1
[Switch-isp-triple] quit
# Configure domain triple as the default ISP domain for all users. Then, if a user enters a username
without any ISP domain at logon, the authentication and accounting methods of the default
domain are used for the user.
[Switch] domain default enable triple
4.
Configure the DHCP relay agent:
# Enable DHCP.
[Switch] dhcp enable
181
# Create DHCP server group 1 and add DHCP server 1.1.1.3 into the group.
[Switch] dhcp relay server-group 1 ip 1.1.1.3
# Enable the DHCP relay agent on VLAN-interface 8.
[Switch] interface vlan-interface 8
[Switch-Vlan-interface8] dhcp select relay
# Correlate DHCP server group 1 with VLAN-interface 8.
[Switch-Vlan-interface8] dhcp relay server-select 1
[Switch-Vlan-interface8] quit
# Enable the DHCP relay agent on VLAN-interface 2.
[Switch] interface vlan-interface 2
[Switch-Vlan-interface2] dhcp select relay
# Correlate DHCP server group 1 with VLAN-interface 2.
[Switch-Vlan-interface2] dhcp relay server-select 1
[Switch-Vlan-interface2] quit
# Enable the DHCP relay agent on VLAN-interface 3.
[Switch] interface vlan-interface 3
[Switch-Vlan-interface3] dhcp select relay
# Correlate DHCP server group 1 with VLAN-interface 3.
[Switch-Vlan-interface3] dhcp relay server-select 1
[Switch-Vlan-interface3] quit
Verifying the configuration
Before user userpt accesses a Web page, the user is in VLAN 8 (the initial VLAN), and is assigned with
an IP address on subnet 192.168.1.0/24. When the user accesses a Web page on the external network,
the Web request will be redirected to authentication page https://4.4.4.4/portal/logon.htm. After
entering the correct username and password, the user can pass the authentication. Then, the device will
move the user from VLAN 8 to VLAN 3, the authorized VLAN. You can use the display connection
ucibindex command to view the online user information
<Switch> display connection ucibindex 30
Slot:
1
Index=30
, Username=userpt@triple
MAC=0015-e9a6-7cfe
IP=192.168.1.2
IPv6=N/A
Access=PORTAL
,AuthMethod=PAP
Port Type=Ethernet,Port Name=GigabitEthernet1/0/1
Initial VLAN=8, Authorization VLAN=3
ACL Group=Disable
User Profile=N/A
CAR=Disable
Priority=Disable
Start=2009-11-26 17:40:02 ,Current=2009-11-26 17:48:21 ,Online=00h08m19s
Total 1 connection matched.
Use the display mac-vlan all command to view the generated MAC-VLAN entries, which record the MAC
addresses passing authentication and the corresponding VLANs.
[Switch] display mac-vlan all
The following MAC VLAN addresses exist:
182
S:Static
D:Dynamic
MAC ADDR
MASK
VLAN ID
PRIO
STATE
-------------------------------------------------------0015-e9a6-7cfe
ffff-ffff-ffff
3
0
D
Total MAC VLAN address count:1
If a client fails authentication, it is added to VLAN 2. Use the previously mentioned commands to view the
assigned IP address and the generated MAC-VLAN entry for the client.
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 Web page, rather
than the portal authentication page or an error message.
Analysis
The keys configured on the access device and the portal server are inconsistent, 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.
183
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.
184
Configuring triple authentication
Overview
Triple authentication enables a Layer 2 access port to perform portal, MAC, and 802.1X authentication.
A terminal can access the network if it passes one type of authentication.
Triple authentication is suitable for a LAN that comprises terminals that require different authentication
services. For example, the triple authentication-enabled access port in Figure 70 can perform MAC
authentication for the printer, 802.1X authentication for a PC installed with the 802.1X client, and port
authentication for the other PC.
Figure 70 Triple authentication network diagram
For more information about portal authentication, MAC authentication and 802.1X authentication, see
"Configuring portal authentication," "Configuring MAC authentication," and "Configuring 802.1X."
Triple authentication mechanism
The three types of authentication are triggered by different packets:
•
The access port performs MAC authentication for a terminal when it receives an ARP or DHCP
broadcast packet from the terminal for the first time. If the terminal passes MAC authentication, the
terminal can access the network. If the MAC authentication fails, the access port performs 802.1X
or portal authentication.
•
The access port performs 802.1X authentication when it receives an EAP packet from an 802.1X
client. If the unicast trigger function of 802.1X is enabled on the access port, any packet from an
802.1X client can trigger an 802.1X authentication.
•
The access port performs portal authentication when it receives an HTTP packet from a terminal.
If a terminal triggers different types of authentication, the authentications are processed at the same time.
The failure of one type of authentication does not affect the others. When a terminal passes one type of
authentication, the other types of authentication being performed are terminated. Then, whether the
other types of authentication can be triggered varies:
185
•
If a terminal passes 802.1X or portal authentication, no other types of authentication will be
triggered for the terminal.
•
If the terminal passes MAC authentication, no portal authentication can be triggered for the
terminal, but 802.1X authentication can be triggered. When the terminal passes 802.1X
authentication, the 802.1X authentication information will overwrite the MAC authentication
information for the terminal.
Using triple authentication with other features
A triple authentication enabled access port supports working with the following features.
VLAN assignment
After a terminal passes authentication, the authentication server assigns an authorized VLAN to the
access port for the access terminal. The terminal can then access the network resources in the authorized
VLAN.
Auth-Fail VLAN or MAC authentication guest VLAN
After a terminal fails authentication, the access port:
•
Adds the terminal to an Auth-Fail VLAN, if it uses 802.1X or portal authentication service.
•
Adds the terminal to a MAC authentication guest VLAN, if it uses MAC authentication service.
A terminal may undergo all three types of authentication. If it fails to pass all types of authentication, the
access port adds the terminal to the 802.1X Auth-Fail VLAN.
ACL assignment
You can specify an authorization ACL for an authenticated 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 onto the access port to filter traffic for the user.
You must configure the ACLs on the access device, whether the authentication server is the access device
or a remote AAA server.
Detection of online terminals
•
You can enable an online detection timer, which is configurable, to detect online portal clients.
•
You can enable the online handshake or periodic re-authentication function to detect online 802.1X
clients at a configurable interval.
•
You can enable an offline detection timer to detect online MAC authentication terminals at a
configurable interval.
For more information about the extended functions, see "Configuring 802.1X," "Configuring MAC
authentication," and "Configuring portal authentication."
Configuring triple authentication
Step
Command
Remarks
Configure at least one type of
authentication.
1.
Configure 802.1X
authentication.
See "Configuring 802.1X"
2.
Configure MAC authentication.
See "Configuring MAC
authentication"
186
802.1X authentication must use
Step
Command
Remarks
MAC-based access control.
3.
Configure Layer-2 portal
authentication.
See "Configuring portal
authentication"
HP does not recommend you
configure 802.1X guest VLANs
for triple authentication.
Triple authentication configuration examples
Triple authentication basic function configuration example
Network requirements
As shown in Figure 71, the terminals are connected to a switch to access the IP network. Configure triple
authentication on the Layer-2 interface of the switch that connects to the terminals so that a terminal
passing one of the three authentication methods, 802.1X authentication, portal authentication, and MAC
authentication, can access the IP network.
•
Configure static IP addresses in network 192.168.1.0/24 for the terminals.
•
Use the remote RADIUS server to perform authentication, authorization, and accounting and
configure the switch to send usernames carrying no ISP domain names to the RADIUS server.
•
The local portal authentication server on the switch uses listening IP address 4.4.4.4. The switch
sends a default authentication page to the web user and forwards authentication data using HTTP.
Figure 71 Network diagram
Configuration procedure
Make sure that the terminals, the server, and the switch can reach each other.
The host of the web user must have a route to the listening IP address of the local portal server.
1.
Configure the RADIUS server, and make sure the authentication, authorization, and accounting
functions work normally. In this example, configure on the RADIUS server an 802.1X user (with
username userdot), a portal user (with username userpt), and a MAC authentication user (with a
username and password both being the MAC address of the printer 001588f80dd7).
2.
Configure portal authentication:
# Configure VLANs and IP addresses for the VLAN interfaces, and add ports to specific VLANs.
(Details not shown.)
187
# Configure the local portal server to support HTTP.
<Switch> system-view
[Switch] portal local-server http
# Configure the IP address of interface loopback 0 as 4.4.4.4.
[Switch] interface loopback 0
[Switch-LoopBack0] ip address 4.4.4.4 32
[Switch-LoopBack0] quit
# Specify the listening IP address of the local portal server for Layer-2 portal authentication as
4.4.4.4.
[Switch] portal local-server ip 4.4.4.4
# Enable Layer-2 portal authentication on GigabitEthernet 1/0/1.
[Switch] interface gigabitethernet 1/0/1
[Switch–GigabitEthernet1/0/1] portal local-server enable
[Switch–GigabitEthernet1/0/1] quit
3.
Configure 802.1X authentication:
# Enable 802.1X authentication globally.
[Switch] dot1x
# Enable 802.1X authentication (MAC-based access control required) on GigabitEthernet 1/0/1.
[Switch] interface gigabitethernet 1/0/1
[Switch–GigabitEthernet1/0/1] dot1x port-method macbased
[Switch–GigabitEthernet1/0/1] dot1x
[Switch–GigabitEthernet1/0/1] quit
4.
Configure MAC authentication:
# Enable MAC authentication globally.
[Switch] mac-authentication
# Enable MAC authentication on GigabitEthernet 1/0/1.
[Switch] interface gigabitethernet 1/0/1
[Switch–GigabitEthernet1/0/1] mac-authentication
[Switch–GigabitEthernet1/0/1] quit
5.
Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1.
[Switch] radius scheme rs1
# Specify the server type for the RADIUS scheme, which must be extended when the IMC server is
used.
[Switch-radius-rs1] server-type extended
# Specify the primary authentication and accounting servers and keys.
[Switch-radius-rs1] primary authentication 1.1.1.2
[Switch-radius-rs1] primary accounting 1.1.1.2
[Switch-radius-rs1] key authentication radius
[Switch-radius-rs1] key accounting radius
# Specify usernames sent to the RADIUS server to carry no domain names.
[Switch-radius-rs1] user-name-format without-domain
[Switch-radius-rs1] quit
6.
Configure an ISP domain:
# Create an ISP domain named triple.
188
[Switch] domain triple
# Configure the default AAA methods for all types of users in the domain.
[Switch-isp-triple] authentication default radius-scheme rs1
[Switch-isp-triple] authorization default radius-scheme rs1
[Switch-isp-triple] accounting default radius-scheme rs1
[Switch-isp-triple] quit
# Configure domain triple as the default domain. If a username input by a user includes no ISP
domain name, the authentication scheme of the default domain is used.
[Switch] domain default enable triple
Verifying the configuration
User userdot uses the 802.1X client to initiate authentication. After inputting the correct username and
password, the user can pass 802.1X authentication. Web user userpt uses a web browser to access an
external
network.
The
web
request
is
redirected
to
the
authentication page
http://4.4.4.4/portal/logon.htm. After inputting the correct username and password, the web user can
pass portal authentication. The printer can pass MAC authentication after being connected to the
network.
Use the display connection command to view online users.
[Switch] display connection
Slot:
1
Index=30
, Username=userpt@triple
IP=192.168.1.2
IPv6=N/A
MAC=0015-e9a6-7cfe
Index=31
, Username=userdot@triple
IP=192.168.1.3
IPv6=N/A
MAC=0002-0002-0001
Index=32
, Username=001588f80dd7@triple
IP=192.168.1.4
IPv6=N/A
MAC=0015-88f8-0dd7
Total 3 connection(s) matched on slot 1.
Total 3 connection(s) matched.
Triple authentication supporting VLAN assignment and
Auth-Fail VLAN configuration example
Network requirement
As shown in Figure 72, the terminals are connected to a switch to access the IP network. Configure triple
authentication on the Layer-2 interface of the switch which connects to the terminals so that a terminal
passing one of the three authentication methods, 802.1X authentication, portal authentication, and MAC
authentication, can access the IP network.
•
Portal terminals use DHCP to get IP addresses in 192.168.1.0/24 before authentication and in
3.3.3.0/24 after passing authentication.
189
•
802.1X terminals use IP addresses in 192.168.1.0/24 before authentication, and request IP
addresses in 3.3.3.0/24 through DHCP after passing authentication. If the terminal fails
authentication, it uses an IP address in 2.2.2.0/24.
•
After passing authentication, the printer obtains the IP address 3.3.3.111/24 that is bound with its
MAC address through DHCP.
•
Use the remote RADIUS server to perform authentication, authorization, and accounting and
configure the switch to remove the ISP domain names from usernames sent to the RADIUS server.
•
The local portal authentication server on the switch uses listening IP address 4.4.4.4. The switch
sends a default authentication page to the web user and forwards authentication data by using
HTTPS.
•
Configure VLAN 3 as the authorized VLAN on the RADIUS server. Users passing authentication are
added to this VLAN.
•
Configure VLAN 2 as the Auth-Fail VLAN on the access device. Users failing authentication are
added to this VLAN, and are allowed to access only the Update server.
Figure 72 Network diagram
Configuration procedure
Make sure that the terminals, the servers, and the switch can reach each other.
When using an external DHCP server, make sure that the terminals can get IP addresses from the server
before and after authentication.
1.
Configure the RADIUS server, and make sure the authentication, authorization, and accounting
functions work normally. In this example, configure on the RADIUS server an 802.1X user (with
username userdot), a portal user (with username userpt), a MAC authentication user (with a
username and password both being the MAC address of the printer 001588f80dd7), and an
authorized VLAN (VLAN 3).
2.
Configure PKI domain pkidm and acquire the local and CA certificates. For more information, see
"Configuring PKI."
3.
Complete the editing of a self-defined default authentication page file, compress the file to a zip
file named defaultfile and save the zip file at the root directory.
4.
Configure DHCP:
190
# Configure VLANs and IP addresses for the VLAN interfaces, and add ports to specific VLANs.
(Details not shown.)
# Enable DHCP.
<Switch> system-view
[Switch] dhcp enable
# Exclude the IP address of the update server from assignment.
[Switch] dhcp server forbidden-ip 2.2.2.2
# Configure IP address pool 1, including the address range, lease and gateway address. A short
lease is recommended to shorten the time terminals use to re-acquire IP addresses after the
terminals passing or failing authentication.
[Switch] dhcp server ip-pool 1
[Switch-dhcp-pool-1] network 192.168.1.0 mask 255.255.255.0
[Switch-dhcp-pool-1] expired day 0 hour 0 minute 1
[Switch-dhcp-pool-1] gateway-list 192.168.1.1
[Switch-dhcp-pool-1] quit
A short lease is recommended to shorten the time that terminals use to re-acquire IP addresses after
passing or failing authentication. However, in some applications, a terminal can require a new IP
address before the lease duration expires. For example, the iNode 802.1X client automatically
renews its IP address after disconnecting from the server.
# Configure IP address pool 2, including the address range, lease and gateway address. A short
lease is recommended to shorten the time terminals use to re-acquire IP addresses after the
terminals pass authentication.
[Switch] dhcp server ip-pool 2
[Switch-dhcp-pool-2] network 2.2.2.0 mask 255.255.255.0
[Switch-dhcp-pool-2] expired day 0 hour 0 minute 1
[Switch-dhcp-pool-2] gateway-list 2.2.2.1
[Switch-dhcp-pool-2] quit
# Configure IP address pool 3, including the address range, lease and gateway address. A short
lease is recommended to shorten the time terminals use to re-acquire IP addresses after the
terminals are offline.
[Switch] dhcp server ip-pool 3
[Switch-dhcp-pool-3] network 3.3.3.0 mask 255.255.255.0
[Switch-dhcp-pool-3] expired day 0 hour 0 minute 1
[Switch-dhcp-pool-3] gateway-list 3.3.3.1
[Switch-dhcp-pool-3] quit
# Configure IP address pool 4, and bind the printer MAC address 0015-e9a6-7cfe to the IP
address 3.3.3.111/24 in this address pool.
[Switch] dhcp server ip-pool 4
[Switch-dhcp-pool-4] static-bind ip-address 3.3.3.111 mask 255.255.255.0
[Switch-dhcp-pool-4] static-bind mac-address 0015-e9a6-7cfe
[Switch-dhcp-pool-4] quit
5.
Configure portal authentication:
# Create SSL server policy sslsvr and specify it to use PKI domain pkidm.
[Switch] ssl server-policy sslsvr
[Switch-ssl-server-policy-sslsvr] pki pkidm
[Switch-ssl-server-policy-sslsvr] quit
# Configure the local portal server to support HTTPS and use SSL server policy sslsvr.
191
[Switch] portal local-server https server-policy sslsvr
# Configure IP address 4.4.4.4 for interface loopback 12.
[Switch] interface loopback 12
[Switch-LoopBack12] ip address 4.4.4.4 32
[Switch-LoopBack12] quit
# Specify the listening IP address of the local portal server as 4.4.4.4.
[Switch] portal local-server ip 4.4.4.4
# Enable Layer-2 portal authentication on GigabitEthernet 1/0/1 and specify VLAN 2 as the
Auth-Fail VLAN, to which terminals failing authentication are added.
[Switch] interface gigabitethernet 1/0/1
[Switch–GigabitEthernet1/0/1] port link-type hybrid
[Switch–GigabitEthernet1/0/1] mac-vlan enable
[Switch–GigabitEthernet1/0/1] portal local-server enable
[Switch–GigabitEthernet1/0/1] portal auth-fail vlan 2
[Switch–GigabitEthernet1/0/1] quit
6.
Configure 802.1X authentication:
# Enable 802.1X authentication globally.
[Switch] dot1x
# Enable 802.1X authentication (MAC-based access control required) on GigabitEthernet 1/0/1,
and specify VLAN 2 as the Auth-Fail VLAN.
[Switch] interface gigabitethernet 1/0/1
[Switch–GigabitEthernet1/0/1] dot1x port-method macbased
[Switch–GigabitEthernet1/0/1] dot1x
[Switch–GigabitEthernet1/0/1] dot1x auth-fail vlan 2
[Switch–GigabitEthernet1/0/1] quit
7.
Configure MAC authentication:
# Enable MAC authentication globally.
[Switch] mac-authentication
# Enable MAC authentication on GigabitEthernet 1/0/1, and specify VLAN 2 as the Auth-Fail
VLAN
[Switch] interface gigabitethernet 1/0/1
[Switch–GigabitEthernet1/0/1] mac-authentication
[Switch–GigabitEthernet1/0/1] mac-authentication guest-vlan 2
[Switch–GigabitEthernet1/0/1] quit
8.
Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1.
[Switch] radius scheme rs1
# Specify the server type for the RADIUS scheme, which must be extended when the IMC server is
used.
[Switch-radius-rs1] server-type extended
# Specify the primary authentication and accounting servers and keys.
[Switch-radius-rs1] primary authentication 1.1.1.2
[Switch-radius-rs1] primary accounting 1.1.1.2
[Switch-radius-rs1] key authentication radius
[Switch-radius-rs1] key accounting radius
# Specify usernames sent to the RADIUS server to carry no domain names.
192
[Switch-radius-rs1] user-name-format without-domain
[Switch-radius-rs1] quit
9.
Configure an ISP domain:
# Create an ISP domain named triple.
[Switch] domain triple
# Configure the default AAA methods for all types of users in the domain.
[Switch-isp-triple] authentication default radius-scheme rs1
[Switch-isp-triple] authorization default radius-scheme rs1
[Switch-isp-triple] accounting default radius-scheme rs1
[Switch-isp-triple] quit
# Configure domain triple as the default domain. If a username input by a user includes no ISP
domain name, the authentication scheme of the default domain is used.
[Switch] domain default enable triple
Verifying the configuration
User userdot uses the 802.1X client to initiate authentication. After inputting the correct username and
password, the user can pass 802.1X authentication. Web user userpt uses a web browser to access an
external
network.
The
web
request
is
redirected
to
the
authentication page
http://4.4.4.4/portal/logon.htm. After inputting the correct username and password, the web user can
pass portal authentication. The printer can pass MAC authentication after being connected to the
network.
Use the display connection command to view connection information about online users.
[Switch] display connection
Slot:
1
Index=30
, Username=userpt@triple
IP=192.168.1.2
IPv6=N/A
MAC=0015-e9a6-7cfe
Index=31
, Username=userdot@triple
IP=3.3.3.2
IPv6=N/A
MAC=0002-0002-0001
Index=32
, Username=001588f80dd7@triple
IP=N/A
IPv6=N/A
MAC=0015-88f8-0dd7
Total 3 connection(s) matched on slot 1.
Total 3 connection(s) matched.
Use the display mac-vlan all command to view the MAC-VLAN entries of online users. VLAN 3 is the
authorized VLAN.
[Switch] display mac-vlan all
The following MAC VLAN addresses exist:
S:Static
D:Dynamic
MAC ADDR
MASK
VLAN ID
PRIO
STATE
-------------------------------------------------------0015-e9a6-7cfe
ffff-ffff-ffff
3
0
193
D
0002-0002-0001
ffff-ffff-ffff
3
0
D
0015-88f8-0dd7
ffff-ffff-ffff
3
0
D
Total MAC VLAN address count:3
Use the display dhcp server ip-in-use command to view the IP addresses assigned to online users.
[Switch] display dhcp server ip-in-use all
Pool utilization: 0.59%
IP address
Client-identifier/
Lease expiration
Type
Hardware address
3.3.3.111
0015-88f8-0dd7
Dec 15 2009 17:40:52
Auto:COMMITTED
3.3.3.2
0002-0002-0001
Dec 15 2009 17:41:02
Auto:COMMITTED
3.3.3.3
0015-e9a6-7cfe
Unlimited
Manual
--- total 3 entry ---
When a terminal fails authentication, it is added to VLAN 2. You can also use the display commands to
view the MAC-VLAN entry and IP address of the terminal.
194
Configuring port security
Overview
Port security combines and extends 802.1X and MAC authentication to provide MAC-based network
access control. It applies to a network that requires different authentication methods for different users on
a port.
Port security prevents unauthorized access to the 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 that the port
learns only trusted MAC addresses.
A frame is illegal, if its source MAC address cannot be learned in a port security mode or it is from a
client that has failed 802.1X or MAC authentication.
The port security feature can automatically take a pre-defined action on illegal frames. This automatic
mechanism enhances network security and reduces human intervention.
NOTE:
For scenarios that require only 802.1X authentication or MAC authentication, HP recommends you
configure 802.1X authentication or MAC authentication rather than port security. For more information
about 802.1X and MAC authentication, see "Configuring 802.1X" and "Configuring MAC
authentication."
Port security features
NTK
The need to know (NTK) feature prevents traffic interception by checking the destination MAC address in
the outbound frames. The feature guarantees 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 three
minutes (not user configurable).
Port security traps
You can configure the port security module to send traps for port security events such as login, logoff, and
MAC authentication. These traps help you monitor user behaviors.
Port security modes
Port security supports the following categories of security modes:
195
•
MAC learning control—Includes two modes, autoLearn and secure. MAC address learning is
permitted on a port in autoLearn mode and disabled in secure mode.
•
Authentication—Security modes in this category implement MAC authentication, 802.1X
authentication, or a combination of these two authentication methods.
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 13 describes the port security modes and the security features.
Table 13 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
Performing a combination of
MAC authentication and
802.1X authentication
macAddressWithRadius
Or
Else
NTK/intrusion
protection
macAddressOrUserLoginSecure
macAddressOrUserLoginSecureExt
macAddressElseUserLoginSecure
NTK/intrusion
protection
macAddressElseUserLoginSecureExt
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.
196
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 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. If one 802.1X user passes authentication, all the other
802.1X users of the port can access the network 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 organizationally unique
identifier (OUI).
For wired users, 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.
For wired users, the port performs MAC authentication upon receiving non-802.1X frames and
performs 802.1X authentication upon receiving 802.1X frames.
•
macAddressOrUserLoginSecureExt
197
This mode is similar to the macAddressOrUserLoginSecure mode except that a port in 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.
For wired users, the port performs MAC authentication upon receiving non-802.1X frames and
performs MAC authentication and then, if the authentication fails, 802.1X authentication upon
receiving 802.1X frames.
•
macAddressElseUserLoginSecureExt
This mode is similar to the macAddressElseUserLoginSecure mode except that a port in 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 or a MAC authentication guest VLAN is the VLAN that a user is in after failing authentication.
Support for the guest VLAN and Auth-Fail VLAN features varies with security modes.
•
You can use the 802.1X guest VLAN and 802.1X Auth-Fail VLAN features together with port security
modes that support 802.1X authentication. For more information about the 802.1X guest VLAN and
Auth-Fail VLAN on a port that performs MAC-based access control, see "Configuring 802.1X."
•
You can use the MAC authentication VLAN feature together with security modes that support MAC
authentication. For more information about the MAC authentication guest VLAN, see "Configuring
MAC authentication."
•
If you configure both an 802.1X Auth-Fail VLAN and a MAC authentication guest VLAN on a port
that performs MAC-based access control, the 802.1X Auth-Fail VLAN has a higher priority.
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:
Optional.
• Configuring NTK
• Configuring intrusion protection
• Enabling port security traps
Configure one or more features
as required.
Configuring secure MAC addresses
Optional.
Ignoring authorization information
Optional.
198
Enabling port security
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.
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.
You cannot disable port security when online users are present.
Before enabling 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, the port security is disabled.
For more information about 802.1X configuration, 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 Layer 2 Ethernet
interface view.
interface interface-type
interface-number
N/A
3.
Set the limit of port security on
the number of MAC
addresses.
port-security max-mac-count
count-value
Not limited by default.
199
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.
•
Verify that the port does not belong to any aggregation group or service loopback group.
•
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:
Step
1.
2.
3.
4.
Enter system view.
Command
Remarks
system-view
N/A
Required for the userlogin-withoui
mode.
Set an OUI value for
user authentication.
port-security oui oui-value index
index-value
Enter Layer 2 Ethernet
interface view.
interface interface-type
interface-number
N/A
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.
200
Not configured by default.
To set multiple OUI values, repeat this
step.
Configuring port security features
Configuring NTK
The NTK feature checks the destination MAC addresses in outbound frames to make sure that 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 13.
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 Layer 2 Ethernet
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.
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 three 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 for the same frame fail.
To configure the intrusion protection feature:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
201
Step
Command
Remarks
2.
Enter Layer 2 Ethernet
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
1.
2.
Command
Remarks
Enter system view.
system-view
N/A
Enable port security traps.
port-security trap { addresslearned
| dot1xlogfailure | dot1xlogoff |
dot1xlogon | intrusion |
ralmlogfailure | ralmlogoff |
ralmlogon }
By default, port security traps are
disabled.
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 addresses fall into static, sticky and dynamic secure MAC addresses.
202
Table 14 A comparison of static, sticky, and dynamic secure MAC addresses
Type
Address sources
Can be saved and
survive a device
reboot?
Aging mechanism
Not available.
Static
Sticky
Dynamic
Manually added
Manually added or
automatically learned
when the dynamic
secure MAC function
(port-security
mac-address
dynamic) is disabled.
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.
Yes.
Yes.
The secure MAC aging
timer restarts at a
reboot.
• 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.
No.
All dynamic secure
MAC addresses are
lost at reboot.
Same as sticky MAC addresses.
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:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
Optional.
2.
Set the secure MAC aging
timer.
port-security timer autolearn aging
time-value
203
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.
Step
Command
Remarks
• In system view:
port-security mac-address
security [ sticky] mac-address
interface interface-type
interface-number vlan vlan-id
3.
Configure a secure MAC
address.
• In interface view:
a. interface interface-type
interface-number
Use either method.
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
int